第1章架构思维入门

一、架构思维入门：什么是RPA架构思维、为什么需要架构思维、架构思维的核心要素

各位开发者朋友，咱们今天聊点实在的。

很多人写RPA脚本，上来就拖控件、录流程。跑起来没问题，但过两个月自己都看不懂了。我见过太多这样的项目——老板催得急，先跑通再说。结果呢？维护成本比开发成本还高。

这就是典型的「没有架构思维」。说白了，你只是在写脚本，不是在搭系统。

1.1 什么是RPA架构思维？

先问个问题：你盖房子会先画图纸吗？肯定会。但为什么写RPA就不画了？

架构思维，就是让你在动手写代码之前，先想清楚三件事：

这个流程到底要拆成几块？——抽象
每块之间怎么配合？——分层
哪些东西可以复用？——模块化

我个人习惯把RPA项目比作乐高。你手里有标准积木块，但怎么搭出城堡，得先有设计图。架构思维就是这个设计图。

核心定义：RPA架构思维，就是用工程化的视角去设计自动化流程。不是「能跑就行」，而是「跑得稳、改得快、拆得开」。

举个例子。我去年接手一个财务对账项目。之前的同事写了800行代码，全在一个脚本里。改一个银行接口，要翻半天代码。我重构时只做了三件事：把数据读取、对账逻辑、结果输出拆成三个独立模块。后来业务方说「再加两个银行」，我只改了数据读取模块，半小时搞定。

这就是架构思维的价值。

1.2 为什么需要架构思维？

你可能会想：「小项目不需要吧？」

嗯，这话我听过太多次了。但实际情况是——没有哪个项目一开始就是大项目。我见过最惨的案例：一个HR入职流程，最初就3个步骤。半年后扩展到23个步骤，原开发者离职了，新来的人看了三天代码，最后决定重写。

为什么？因为代码里全是硬编码、全局变量、循环嵌套循环。改一个地方，崩三个地方。

架构思维能帮你解决三个核心痛点：

痛点	没有架构思维	有架构思维
维护成本	改一处，测全部	改模块，不影响其他
扩展性	加功能像打补丁	加功能像插积木
团队协作	一个人写，别人看不懂	分工明确，接口清晰

避坑指南：我曾经接手过一个「看起来很简单」的Excel处理脚本。打开一看，里面用了7个全局变量，函数之间互相调用，循环里套着异常处理，异常处理里又套着循环。改一个变量名，整个脚本就炸了。所以，别信「先跑通再说」——跑通只是及格线，能维护才是真本事。

1.3 架构思维的核心要素

好了，咱们聊点干货。架构思维不是玄学，它有三个实实在在的抓手：抽象、分层、模块化。

1.3.1 抽象——把复杂问题变简单

抽象是什么？说白了就是「找共性」。

你想想看，一个RPA流程里，是不是经常有重复的操作？比如登录系统、读取数据、写入Excel。这些操作背后的逻辑是一样的，只是参数不同。

抽象就是把这些共性提炼出来，做成一个通用的「模板」。

// 不好的做法：每个流程都写一遍登录
function loginToSystemA() {
    // 打开浏览器
    // 输入账号密码
    // 点击登录
}

function loginToSystemB() {
    // 打开浏览器
    // 输入账号密码
    // 点击登录
}

// 好的做法：抽象出一个通用登录函数
function loginToSystem(systemUrl, username, password) {
    // 打开浏览器 -> systemUrl
    // 输入账号密码 -> username, password
    // 点击登录
}

我在项目中遇到过最典型的例子：一个客户有5个不同的业务系统，每个登录方式都差不多。我写了一个通用的登录模块，配置化处理。后来新增第6个系统，只改了一行配置文件。

小技巧：抽象的时候别过度。我见过有人把「点击按钮」都抽象成一个函数，结果代码里全是「clickButton(buttonName)」，反而更难读了。抽象到什么程度？一个原则：如果一段代码在三个以上地方出现，就该考虑抽象了。

1.3.2 分层——让代码有层次感

分层，就是给代码分「楼层」。每一层只做自己的事，不越界。

我常用的分层方式是三层架构：

表现层：负责和用户交互，比如弹窗、日志、界面操作
业务层：负责核心逻辑，比如对账规则、审批流程
数据层：负责数据读写，比如Excel、数据库、API

为什么要分层？因为每一层的变更原因不同。业务规则变了，你只需要改业务层。数据库换了，你只需要改数据层。互不影响。

// 分层示例
// 数据层：只负责读数据
function readDataFromExcel(filePath) {
    // 打开Excel
    // 读取数据
    // 返回数据
}

// 业务层：只负责处理逻辑
function processData(rawData) {
    // 对账逻辑
    // 返回处理结果
}

// 表现层：只负责展示
function showResult(result) {
    // 弹窗或写日志
}

嗯，这里要注意：分层不是越多越好。我见过有人分了7层，结果改一个功能要改5个文件。一般来说，3到4层就够用了。

1.3.3 模块化——搭积木式开发

模块化是抽象和分层的最终产物。每个模块就是一个独立的「积木块」，有明确的输入和输出。

模块化的好处很明显：

可复用：写一次，到处用
可测试：单独测一个模块，不用跑整个流程
可替换：模块坏了，换个新的就行

我举个例子。一个典型的RPA项目可以拆成这些模块：

模块名称	功能描述	输入	输出
登录模块	统一处理系统登录	URL、账号、密码	登录状态
数据抓取模块	从页面提取数据	页面元素定位	结构化数据
数据校验模块	检查数据完整性	原始数据	校验结果
报表生成模块	生成Excel/PDF	处理后的数据	文件

关键原则：模块之间通过「接口」通信，不要直接调用内部变量。接口就是函数的参数和返回值。你想想看，如果模块A直接修改了模块B的全局变量，那这两个模块就「耦合」在一起了。改一个，另一个也得改。

最后说一句。架构思维不是一天练成的。我刚开始做RPA时，也写过「面条代码」。但每次踩坑后，我都会问自己三个问题：

这段代码如果三个月后看，还能看懂吗？
如果业务变了，改起来方便吗？
如果别人接手，他能快速上手吗？

这三个问题，就是架构思维的起点。

📚 课程目录

一、架构思维入门：什么是RPA架构思维、为什么需要架构思维、架构思维的核心要素

1.1 什么是RPA架构思维？

1.2 为什么需要架构思维？

1.3 架构思维的核心要素

1.3.1 抽象——把复杂问题变简单

1.3.2 分层——让代码有层次感

1.3.3 模块化——搭积木式开发