第八章_敏捷协作_44 做代码复查

44 做代码复查

1. 问题是什么？

代码完成开发之后，要不要复查？

2. 恶魔的方案

用户是最好的测试人员。别担心——如果哪里出错了，他们会告诉我们的。

3. 天使的方案

复查所有的代码。

劣势

• 管理层担心进行代码复查所耗费的时间
• 开发人员对代码复查感到担心，允许别人看他们的代码，会让他们有受威胁的感觉。这影响了他们的自尊心。他们担心在情感上受到打击

代码复查或许是找到并解决问题的最佳方式。

优势

通过严格的代码复查过程，他们可以提交质量极高而且稳定的代码

时机

当开发人员完成某项任务的编码和测试后，在签入源代码控制系统之前，会有另一个开发人员对代码做彻底的复查。

面向人员：

代码复查不止针对初级开发者编写的代码——团队中每个开发人员的代码都应该进行复查，无论其经验丰富与否。

对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式，复查可以产生非常使用而高效的成果。要让不同的开发人员在每个任务完成后复查代码。

• 如何进行代码复查

  • 通宵复查，不推荐， 无效
  • 捡拾游戏

  代码编写完成，通过编译，完成测试，准备签入时，其他开发人员就可以获取代码开始复查。复查人员可以更换

  • 结对编程

  一个人在键盘旁边（担任司机的角色），另一个人坐在后面担任导航员

• 复查代码，复查什么？

  • 代码可读性
  • 有无任何明显的错误
  • 是否会对其他的应用产生不良影响
  • 是否存在重复的代码
  • 是否存在可以改进或重构的部分？

使用静态工具更好。

4. 切身感受

代码复查随着开发活动持续进行，而且每次针对的代码量相对较少。感觉复查活动就像项目正在进行的一部分，而不是令人畏惧的事情。

5. 平衡的艺术

• 不进行思考，类似于橡皮图章一样的代码复查没有任何价值
• 代码复查需要积极评估代码的设计和清晰程度，而不只是考量变量名和代码格式是否符合组织的标准
• 同样的功能，不同的开发人员的代码实现可能不同。差异并不意味着不好。除非你可以让某段代码明确变得更好，否则不要随意批评别人的代码
• 及时追踪代码复查中发现的问题
• 确保代码复查人员得到每次复查活动的反馈。作为结果，要让每个人知道复查完成后所采取的行动。

6. 总结

代码复查，要检查其设计清晰程度，不要仅仅关注在代码风格和变量命名上面。

代码复查，单元测试，静态测试是对保证代码质量的最重要的工具。