线上无小事，出现线上事故轻则影响用户体验，重则造成资损，这都是我们不愿意看到的现象。但又有一个著名的墨菲定律：可能出错的事，就一定会出错。那么我们应该如何减少错误、降低影响呢？
一、意识建设
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 录屏、控制台信息相结合，便于复原现场信息