4. 流程设计原则与规范：RPA设计模式、异常处理策略、日志规范、命名规范
好，咱们进入第四章。这一章，说白了就是讲「规矩」。
很多新手写RPA，上来就拖组件，能跑就行。我见过太多这样的项目了——跑的时候没问题，一换环境、一换人维护，立马崩给你看。为什么会这样？因为没按规范来。
我个人习惯，在项目启动的第一天，就把设计原则和规范文档发给团队。这不是为了装样子，而是为了后面少加班。你想想看，一个流程跑半年，中间换三个人维护，如果没有统一的命名和日志，那简直就是灾难。
4.1 RPA设计模式：别把流程写成「面条代码」
RPA设计模式，说白了就是一套「套路」。用好了，流程清晰、好维护、不容易崩。
4.1.1 模块化设计
把一个大流程拆成若干个小模块。每个模块只干一件事。
- 登录模块：只负责打开系统、输入账号密码、处理验证码。
- 数据抓取模块：只负责从页面拿数据。
- 数据写入模块：只负责往Excel或数据库里写数据。
- 异常处理模块：只负责兜底和重试。
我在项目中遇到过，有人把登录、抓取、写入全写在一个序列里，结果登录失败后，整个流程直接卡死。拆开之后，每个模块独立处理异常，清爽多了。
4.1.2 状态机模式
对于流程状态多、分支复杂的情况，我强烈建议用状态机。比如一个审批流程，有「待提交」、「审批中」、「已通过」、「已驳回」等状态。用状态机来管理，代码逻辑清晰，不会出现「跳状态」的bug。
嗯，这里要注意：状态机不是万能的。如果流程是线性的，从头到尾一条路走到底，那用状态机反而多余。别为了用模式而用模式。
4.1.3 配置驱动模式
把流程中会变的东西，比如URL、账号、超时时间、文件路径，全部放到配置文件里。不要硬编码在代码中。
我曾经接手过一个项目，里面十几个地方都写了同一个数据库IP。后来IP换了，改代码改到怀疑人生。从那以后，我所有项目都强制用配置文件。
4.2 异常处理策略：别让机器人「死得不明不白」
RPA最怕什么？怕跑着跑着突然停了，还没留下任何线索。异常处理，就是给机器人装个「黑匣子」。
4.2.1 分层异常处理
我习惯把异常分成三层：
- 流程级异常：整个流程崩了，比如系统崩溃、网络断开。这时候应该发邮件或钉钉通知管理员。
- 步骤级异常：某个步骤失败了，比如点击按钮没反应。这时候应该重试2-3次，如果还不行，记录日志并跳过。
- 元素级异常：某个元素没找到。这时候应该截图保存，然后尝试备用定位方式。
4.2.2 重试机制
不是所有异常都需要立刻停止。很多异常是暂时的，比如页面加载慢、网络抖动。我一般会设置重试策略：
- 重试次数：3次
- 重试间隔：第一次等5秒，第二次等10秒，第三次等20秒（指数退避）
- 重试条件：只对特定异常类型重试，比如「元素未找到」、「超时」
4.2.3 优雅退出
当流程必须停止时，不要直接kill进程。应该：
- 记录当前处理到的位置（比如处理到第几行数据）
- 关闭所有打开的应用程序（浏览器、Excel等）
- 发送失败通知
- 保存现场截图和日志
这样下次重启时，可以从断点继续，而不是从头再来。
4.3 日志规范：让问题「有迹可循」
日志是RPA的「眼睛」。没有日志，出了问题你只能靠猜。
4.3.1 日志级别
我一般用四个级别：
| 级别 | 用途 | 示例 |
|---|---|---|
| INFO | 记录正常流程的关键节点 | 「开始处理第100行数据」 |
| WARN | 记录非致命但需要注意的情况 | 「页面加载超过10秒，继续等待」 |
| ERROR | 记录导致步骤失败的异常 | 「点击【提交】按钮失败，重试第1次」 |
| DEBUG | 记录详细的调试信息 | 「当前页面URL: https://...」 |
4.3.2 日志内容规范
每条日志应该包含：
- 时间戳：精确到毫秒
- 流程名称：哪个流程在跑
- 步骤名称：当前执行到哪一步
- 日志级别：INFO/WARN/ERROR/DEBUG
- 消息内容：具体发生了什么
- 上下文数据：比如当前处理的数据ID、页面标题等
// 日志格式示例
[2025-01-15 14:30:22.456] [采购流程] [登录步骤] [INFO] 开始登录系统，用户名: admin
[2025-01-15 14:30:25.789] [采购流程] [登录步骤] [ERROR] 登录失败，错误码: 401，页面标题: 登录页
[2025-01-15 14:30:26.001] [采购流程] [登录步骤] [WARN] 重试第1次，等待5秒后重试4.3.3 日志存储
日志不要只存在内存里。我建议：
- 每天生成一个日志文件，文件名包含日期
- 日志文件保留30天，自动清理旧的
- 关键日志同时写入数据库，方便查询
- 异常日志自动发送到监控平台
4.4 命名规范：名字起得好，维护没烦恼
命名这件事，看似小事，实则大事。我见过一个项目，变量名叫a1、a2、a3... 三个月后，原作者自己都看不懂了。
4.4.1 变量命名
| 类型 | 规范 | 示例 |
|---|---|---|
| 字符串 | str_ + 含义 | str_userName, str_filePath |
| 数字 | int_ / dbl_ + 含义 | int_retryCount, dbl_totalAmount |
| 布尔 | is_ / has_ + 含义 | is_loginSuccess, has_dataLoaded |
| 数组/列表 | arr_ / list_ + 含义 | arr_orderIds, list_customerInfo |
| DataTable | dt_ + 含义 | dt_purchaseOrders, dt_employeeList |
4.4.2 流程/序列命名
- 主流程：Main_ + 业务名称，如 Main_采购订单处理
- 子流程：Sub_ + 功能名称，如 Sub_登录系统、Sub_数据校验
- 异常处理流程：Err_ + 异常类型，如 Err_网络超时处理、Err_数据异常处理
4.4.3 文件命名
- 项目文件夹：RPA_ + 项目名称，如 RPA_采购自动化
- 流程文件：业务名称_版本号，如 采购订单处理_v1.0.xaml
- 配置文件：Config_ + 环境名称，如 Config_生产环境.json
- 日志文件：Log_ + 流程名称 + 日期，如 Log_采购流程_20250115.txt
4.4.4 注释规范
代码写注释，不是为了给机器看，而是为了给人看。我要求团队：
- 每个流程/序列开头，写清楚「这个模块是干什么的」
- 每个关键步骤，写一句注释说明「为什么这么做」
- 复杂的逻辑判断，写清楚「判断条件是什么」
- 不要写废话注释，比如「这里加1」——傻子都看得懂加1，你要写的是「为什么加1」
// 好的注释
' 这里加1是因为Excel表头占了一行，实际数据从第2行开始
int_rowIndex = int_rowIndex + 1
// 坏的注释
' 加1
int_rowIndex = int_rowIndex + 1好了，这一章的内容就这些。设计原则和规范，听起来枯燥，但真的能救命。你想想看，一个流程跑半年，中间换三个人维护，如果没有这些规范，那简直就是一场噩梦。
下一章，咱们聊聊具体的开发工具和调试技巧。到时候见。