线上无小事，出现线上事故轻则影响用户体验，重则造成资损，这都是我们不愿意看到的现象。但又有一个著名的墨菲定律：可能出错的事，就一定会出错。那么我们应该如何减少错误、降低影响呢？

一、意识建设

1.1 质量重视

• 明确需求：需求或UE评审阶段悬而未决的事情，及时找产品确认解决，保证不会有需求理解的偏差。避免开发联调时临时改逻辑，影响代码质量
• 降低影响：公司重视线上 bug 是为了降低对线上用户的影响，提供更好的服务，因此遇到线上 bug，应该第一时间修复以及降低影响，遇到问题，寻求协助，大家都有义务协助其他同学解决线上 bug
• 专项治理：定期排查 bug 集中的领域、子域、人员，进行专项治理
• 经验学习：其他团队分享沉淀、质量文化助手

1.2 开发容错

• 字段处理：对字段的处理要谨慎，做好特殊字段值的处理。对于数组、对象类型的字段尽量不要相信后端的接口定义，最好做对空值和 undefined 的处理
• 编码习惯
  • 文件大小：限制单文件、单方法的代码行数
  • 代码注释：复杂逻辑多写一些注释或者记录在技术文档中，提升代码可读性便于问题排查和后续迭代
  • 规范命名：命名是代码的自描述，优秀的命名将减少注释量，甚至不需要注释
  • TS 约束：完善的 TS 类型约束
• 迭代兼容
  • 对于迭代的需求，需考虑全面，比如老数据的兼容问题
  • 公共组件：兼容之前用法，改动后对于影响到的场景要全量回归，每种类型回归一种即可
  • 接口改动：新需求复用已有接口，需服务端提供接口出入参，并对当前所在环境做好自测

1.3 自测把关

• 排期规划：理清需求点并与合作方确认疑问点，评估改动量和影响面，预留出回归测试时间。回归测试按照正常开发标准，showcase 时尽量多确认到一些交互细节
• 自测 Check List：QA 测试 Case 留档，技术文档中列出本次开发所有的逻辑分支和特殊 Case（如精度等开发过程中觉得有风险的地方），自测完一条就中划线划掉，保证所有的逻辑都已自测
• 共用逻辑改动（组件/util）：梳理所有的调用方并与原开发同学确认影响面，统计不一样的调用类型，将每种类型自测，再同步到 QA 同学，避免漏测
• 历史用例：对于修改已有功能，回归历史用例；领域负责人，要把之前的测试用例积累下来，形成文档，并整理对应测试场景的账号、流程整理等

二、流程建设

2.1 领域分工

• 分工：明确领域第一负责人、第二负责人，尽量由熟悉领域的人修改代码，如果是不熟悉的人修改了代码，一定找负责人做代码质量把关
• 积累：各领域的技术文档整理归档

2.2 方案评审

• 对于复杂的需求，或者可能有质量隐患的需求，需要做方案评审，包含如何降低质量风险，暂时没有强制规定，个人主动发起评审

2.3 Code Review

• CR 时机：
  • 提测前：保证修改后的代码进入 QA 环节
  • 上线前：修改代码一定重走涉及测试用例
• 强制 CR 机制：
  • 主要负责人：业务模块负责人、公共函数/组件负责人、高危场景负责人
  • 核心、高危改动：公共函数/组件、高危场景

2.4 周会分析

• 线下 bug 纳入统计，明确问题现状、趋势、分布等
• 每周线上线下 Bug 统计分析

2.5 问题复盘

• 线上 bug 彻底复盘，分析问题发生底层原因，形成可落地的改进机制，防止此类问题再次发生
• 典型的线下 bug，个人主动分享，形成最佳实践，在组内推广

三、技术建设

3.1 架构改造

• 微前端：子应用隔离，减小问题影响面和回归难度
• 领域沉淀：完善领域模型与分层架构，降低代码耦合度，降低维护难度

3.2 监控报警

• 接口返回值报警，比如 401、403、502
• JS 错误报警，比如 SyntaxError、TypeError
• 关键节点加埋点，比如文件下载后缀类型

3.3 自动化测试

• 单元测试：公共组件和函数尽量覆盖，可以配合演示 demo，用例参考：https://github.com/umijs/umi-request/blob/master/test/util.test.js
• UI 测试：尝试覆盖主流程，减轻回归成本
• 主动放火：自动走查所有页面

3.4 主动反馈

• 用户问题主动反馈，工单跟进
• 主动反馈与 DOM 录屏、控制台信息相结合，便于复原现场信息