代码评审Checklist
代码评审是我个人一直比较推崇的开发阶段实现质量保障的核心实践。但在现实项目中，不同的团队在实施代码评审活动时的差异非常大，差异点主要在开展频度和评审内容上。
对于开展频度：
- 有的团队采取每日评审的方式（即每天固定时间进行集体代码评审）
- 有的团队在移测前就将要移交的用户故事进行代码评审
- 有的团队在迭代中对所有将要上线的用户故事进行代码评审
- 当然还有一些团队很少进行代码评审，理由大概是：没时间、评审没价值等。
上述代码评审活动的开展基本取决于团队或个人的，与整个交付流水线的关联与结合不是特别紧密。因此如果团队采用特性分支开发，我会比较推崇在“合并请求”时开展，因为这一步是代码管理系统的必须的一个环节，让它进一步融入交付流水线中吧。
解决了评审的时机问题，接下来需要的就是如何高效且规范的开展代码评审。下面将列出在代码审查时，作为评审员一般需要关注的内容：
1.满足功能需求
首先且最重要的是代码是否满足其应满足的所有要求，并指出是否有遗漏之处。
2.对现有代码的副作用
该变更是否有副作用：有时，系统中的一个变更可能会导致其他上游和下游系统出现错误。 这通常与项目经验直接相关，对系统及其部署运行环境的越了解越能发现此类副作用。
3.并发
代码是否是线程安全的？ 如果使用共享资源，是否已正确同步？ 是否存在任何死锁或活锁的可能性？ 并发错误很难发现，并且经常在生产中才会出现。 通过仔细了解设计及其实现，可以在代码审查时发现这一点。
4.可读性和可维护性
代码可读性好吗？ 对于他人是否容易理解？ 始终重视可读性，其他人甚至你本人今后都会感谢你此时在可读性方面的付出。
另一个重要方面是可维护性，因为大多数软件在维护上花费90％的时间，而在开发上仅花费10％的时间，请确保代码是可维护且灵活的。
还可以验证代码是否可配置，检查是否存在任何硬编码，找出在不久的将来要更改的内容等。
5.一致性
这是第4点的一部分，但由于它很重要，因此将其另作一个单独的检查点。 通过一致性来确保代码风格的一致，以及编写和理解的一致。
由于项目一般会有多人开发，并且他们都有自己的编码风格，因此制定统一的编码规范并在开发中加以贯彻十分必要。
例如，某人使用函数initialize（）而其他人使用init（）进行相同的操作就违反了一致性。
6.性能
如果要为高频交易编写高容量，低延迟（微秒级）的交易平台，性能则是另一个重要检查点。仔细审视哪些代码将在启动时执行，哪些代码将会被循环执行或多次执行，以对频繁执行的代码进一步优化。
当然对于一般需求场景来说，也能通过代码评审来消除不必要的性能代价。
7.错误和异常处理
代码是否处理错误的输入和异常？应该以预定义和标准的方式提供，并且必须以书面形式进行定义和指导。在进行评审时，需要重点关注，因为错误和异常处理的失败会导致程序崩溃，并且无法从其他系统或同一程序的其他部分的故障中恢复。
8.简单性
请务必看看是否有更简单且优雅的替代方案，并进行尝试。很多时候想到的第一个解决方案并不是最好的解决方案，因此多想一想是值得的。
9.重用现有代码
看看是否可以通过使用现有代码来实现功能，这样做的好处是所使用的代码是经过实践检验的，能够减少质量检测时间，并且使你更有信心。引入新库会引入新的依赖关系，在绝对非必要前不要轻易尝试。
10.单元测试
检查是否已经编写了足够的XUnit测试用例，并涵盖了足够百分比的新代码。切勿在没有单元测试的情况下让代码通过评审，因为开发人员常常会以时间不够为借口，但请相信单元测试是开发质量内建的关键一环。
最后，你完全可以根据人员、技术或者组织的现实情况，对上述检查点进行个性化调整。并且在正式采用之前，对团队进行正式宣贯并达成一致的理解，并在实际使用中不断进行完善和改进，来不断提升检查表的价值、提升代码评审的效率并满足团队不同的阶段需要。
- 版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处！
