iOS - CodeReview 代码评审

1、CodeReview

• Code Review 中文应该译作 “代码审查” 或是 “代码评审”，这是一个流程，当开发人员写好代码后，需要让别人来 review 一下他的代码，这是一种有效查找系统缺陷的方法。由此，我们可以审查代码的风格、逻辑、思路 。。。。。。，找出问题，以及改进代码，保证软件总体质量和提升开发者自身水平。因为这是代码刚刚出炉的时候，所以，这也是代码重构，代码调整，代码修改的最佳时候。所以，Code Review 是编码实现中最最重要的一个环节。

• 代码评审通常有两种类型：正式代码评审（formal code review），轻量级代码评审（light code review）。

1.1 为什么要进行代码评审

• a、可以通过大家的建议增进代码的质量。

• b、是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。

• c、鼓励程序员们相互学习对方的长处和优点，提高团队整体水平。

• d、可以被用来确认自己的设计和实现是一个清楚和简单的。对开发人员来说也是一次开发思想重新重构的过程，可以更好的理解系统。

1.2 代码评审的方式和时间

• a、由作者启动评审，展示评审文档（over-the shoulder）。它的优点是开发团队内部可以快速进行评审交流，对于项目架构，后期可扩展性，可维护性等可以启用这样的评审，通过启动这样的评审，一方面评审者可以学习作者的架构思想，另一方面也可以团队内部讨论架构上的不足加以改进。

• b、组织评审会议（review meeting），由团队成员轮流选出自己的评审作品共其它评审者学习。可以在项目结束后进行，通过这种敦促的方式共享好的东西让整体团队一起进步。

• c、利用评审工具（tool assited code review）。

1.3 代码评审的层级

• a、实现正确性：主要包括是否实现预期功能，是否存在 bug，是否存在性能问题等。

• b、设计合理性：主要包括实现方法，数据接口，设计模式，扩展性等，是否存在大量重复代码和其它组件是否有重复代码，包括结构设计是否合理，是否存在性能问题等。

• c、代码可读性：主要包括代码风格，美观性。

• 实现正确性和设计合理性是必须要进行的 code review。对于代码可读性，由于每个人的编码风格不一样，建议做最低级别的 review，比如注释。

1.4 使用代码评审的注意点

• a、Code reviews 不应该承担发现代码错误的职责。Code Review 主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。代码中的 bug 和错误应该由单元测试，功能测试，性能测试，回归测试来保证的（其中主要是单元测试，因为那是最接近 Bug，也是 Bug 没有扩散的地方）。

• b、Code reviews 不应该成为保证代码风格和编码标准的手段。编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队 Review 的时候，代码就应该是符合规范的，这是默认值，属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。个人认为 “meeting” 是奢侈的，因为那需要大家在同一时刻都挤出时间，所以应该用在最需要的地方。代码规范比起程序的逻辑和对需求设计的实现来说，太不值得让大家都来了。

• 10 年前，上面这两件事会是理所当然的（10 年前的中国的软件开发还没有 Code Reivew 呢），今天，在中国的很多公司上面这两件事依然被认为是 Code Reivew 最重要的事，所以，能够看到很多开发 Team 抱怨 Code Review 就是一个形式，费时费力不说，发现的问题还不如测试，而评审者们起初在代码风格上有些见术，别的也就没什么用了，长而久之，大家都会开始厌烦这个事了。

• 所以，在今天，请不要把上面的那两件事分散了 Code Review 的注意力，取而代之的是，对于 Bug，程序的作者要在 Review 前提交自己的单元测试报告（如：XUnit 的测试结果），对于代码规范，这是程序作者自己需要保证的，而且，有一些工具是可以帮你来检查代码规范的。

• 当然，上述这些言论并不是说，你不能在 Code Review 中报告一个程序的 bug 或是一个代码规范的问题。只是说，那并不是 Code Review 的意图。

1.5 使用代码评审的小提示

• 1、经常进行 Code Review

  • 以前经历过几个相当痛苦的Code Review，那几次Code Review都是在程序完成的时候进行的，当你面对那近万行的代码，以前 N 我掺和在一起的功能，你会发现，整个 Code Review 变得非常地艰难，用不了一会儿，你就会发现大家都在拼命地打着哈欠，但还是要坚持，有时候，这样的 Review 会持续 3 个小时以上，相当的夸张。而且，会议上会出现相当多的问题和争论，因为，这就好像，人家都把整个房子盖好了，大家 Review 时这挑一点那挑一点，有时候触动地基或是承重墙体，需要大动手术，让人返工，这当然会让盖房的人一下就跳起来极力地维护自己的代码，最后还伤了团队成员的感情。

  • 所以，千万不要等大厦都盖好了再去 Reivew，而且当有了地基，有了框架，有了房顶，有了门窗，有了装修的各个时候循序渐进地进行 Review，这样反而会更有效率，也更有帮助。

  • 下面是一些观点，千万要铭记：

    • 要 Review 的代码越多，那么要重构，重写的代码就会越多。而越不被程序作者接受的建议也会越多，唾沫口水战也会越多。

    • 程序员代码写得时候越长，程序员就会在代码中加入越来越多的个人的东西。 程序员最大的问题就是 “自负”，无论什么时候，什么情况下，有太多的机会会让这种 “自负” 澎涨开来，并开始影响团队影响整个项目，以至于听不见别人的建议，从而让 Code Review 变成了口水战。

    • 越接近软件发布的最终期限，代码也就不能改得太多。

  • 个人的习惯，也是对团队成员的要求是：先 Review 设计实现思路，然后 Review 设计模式，接着 Review 成形的骨干代码，最后 Review 完成的代码，如果程序复杂的话，需要拆成几个单元或模块分别 Review。当然，最佳的实践是，每次 Review 的代码应该在 1000 行以内，时间不能超过一部电影的时间
    1.5 小时。

  • 当然，在敏捷开发中，他们不需要 Code Reivew，其实，敏捷开发中使用更为极端的 “结对编程”（Pair-Programming）的方法：一种时时刻刻都在进行 Code Review 的方法，个人感觉在实际过程中，这种方法有点过了。另外，大家可以看看《结对编程的利与弊》来了解一下这种方法的问题。

• 2、Code Review 不要太正式，而且要短

  • 忘了那个代码评审的 Checklist 吧，走