17、软件开发中的持续集成与代码审查

软件开发中的持续集成与代码审查

1. 代码审查引发的讨论

在一次代码审查会议中，团队成员围绕代码质量和“完成定义”展开了激烈讨论。会议开始，Alex 介绍了审查规则，即每次代码提交都需同行审查，此次因新增应用，要进行更正式的检查。

Ryan 展示了新应用，该应用用于展示印尼和中国工厂的工人状况，数据高度敏感，需重视安全问题。他介绍了业务逻辑、数据模型以及 UI 层和认证授权的实现。然而，Harry 对 Ryan 的代码提出了严厉批评，指出其命名规范混乱、缺乏文档，不符合整体代码库风格。

Ryan 认为团队没有明确的“完成定义”，不应因未达到未明确的标准而受指责。Harry 也认同需要正式的“完成定义”，以避免每周处理代码风格问题。Ben 表示团队已确定了质量目标，如单元测试覆盖率、缺陷数量和发布成功率，但如何实现这些目标由团队决定，建议制定的规则要简单、易执行且符合团队使命和价值观。

Alex 召集团队进一步讨论，Harry 强调需要在风格和命名规范上加强纪律，Padma 认为当前的审查方式高效，George 则觉得 Harry 的批评过于严重。最终，团队决定制定审查清单，重点关注测试，要求每次变更都有单元测试，演示需在类生产环境中进行，并在几周后检查是否需要增加静态代码分析要求。

2. 持续集成的重要性及挑战

2.1 持续集成的必要性

团队在发布软件方面虽有进步，但在使代码达到可发布状态上仍花费过多时间。持续集成已成为必要实践，但在实施方式上存在争议。

代码冻结和长时间的稳定阶段是有害的，持续集成是解决之道。在一些项目中，长时间的集成/稳定期会导致大量时间和机会成本的损失