Review & Inspection

这周进展相当不顺利。让我上火的两件事：
1. Web service接口代码不可用，测试发现走不通，在公司根本没有测试过。一开始发布不出去，折腾一天终于可以发布出去，用模拟的客户端一调用发现代码代码根本走不下去，于是逐行单步调试修改，几乎每两三行就有错误，居然有的逻辑表都查错了，需求没有处理的地方也很多。费了一天的功夫调通了一个case，把实现的方法作为例子，发回北京修改，直到今天他们还在修改测试，通过这两天的交流，发现他们已经清楚问题所在并且解决了，下周一拿到这测一下应该没有大问题了。

2. 第三方开发Web portal页面逻辑性不够，对用户不够友好。逻辑层有些代码更是不堪入目。定购部分代码if...else...层层嵌套，没有140的智商休想快速读懂，这样的代码当然漏洞百出。今天把他们的人叫过来，花了半天时间进行页面检查、重构代码。当场演示如何重构代码，把那些垃圾代码逐步重构成可读代码，在重构过程中修改了逻辑上的很多bug。再次证实了：复杂的代码不是必须的、通常是有问题的。复杂的处理过程不代表一定要有复杂的代码实现，只有简单的代码结构才能正确地实现复杂的处理过程。在重构的过程中，结构一简化就能发现很多隐藏的bug，在复杂的结构下面，理解每行代码都很困难，不要说一眼就看见bug了。
有那些绝佳的反面代码，加上对这段关键代码的重视，相信放在课堂上这是一个精彩的重构讲解课，但不知他们能领悟多少，下次提交的代码是否能更接近可用代码一点？！

这两个问题几乎同时发现，倍感压力，一个是内部问题，另一个是合作方问题。对于合作方的问题原因这里先不说了，这里的“妖”事太多。对于内部的问题，细想下来，还是我的错误，一时疏漏，工作没有到位，导致大乱。

没有到位的工作现在看来是 review & inspection.

项目前期的review & inspection做的还是挺好的，后期由于各种压力太大，没有能够很好地坚持下去，导致失误。

由于采取的是整个team一起review，到最后代码越来越多，review占用的时间越来越长，逐渐负担不起，于是有的马虎，追求速度。另外，项目中由于人员有限，没有人专门写test case，代码过后的UT几乎没有做，直接feature test，test case就由代码的开发者进行写出，写出后我看了几个人的，都太简单，没有真正意义上的test case，于是发email发comments给全组，没有大家一起review，只是让大家重写。事后又由于其他事太忙，没有好好重新全部重新review，相信大家都能认真对待自己的工作。这样最后一关也丢失了。于是出现一点问题也就不算奇怪了。

学费就这样付了，总得学点东西，总结如下：

1. Review & Inspection 很重要。

2. 开发过程中需要Review 和 Inspection的有：requirement、HLD&LLD、Code、Test case、Schedule & Plan

3. 每种Review都要有开发流程的上下家，以保证没有遗漏需求、任务等。

4. Review 有三个目的：
     1）相互学习
     2）找问题
     3）加强交流，沟通
           team成员不仅要了解自己手中的一亩三分地，也要对项目有通盘理解，以便做到整体系统的可能，同时降低项目由于某些人离去或其他情况带来的risk.

5. Review人员尽量多元化，保证各种人关注各个方面，没有盲点。

6. 对于一个新项目组而言，代码的风格，组员的习惯各不相同，需要统一，可以利用Code Inspection。

     需要在code的第一周就进行code inspection，无论大家是否完成了多少完整功能的代码，只要有足够的代码进行共同学习即可。因此需要全体参加，当作讨论学习课，确定以后的统一风格标准。第二周需要继续进行，以检验代码是否按照上周inspection结构进行修改，巩固风格标准。由于全体参加，review全体代码，会花费相当多时间，造成效率低下，形成时间压力。

     如果两轮过后目标基本达到，则可进行部分人员参加的inspection，inspection的间隔也不一定是一周，每个人可以选择合适的时间进行，最好完成一定的完整功能代码后进行inspection。

7. 保证所有需要review的内容都进行review，而不能由于时间等压力就在review上省时间。

8. Review 可以先做homework，在meeting上讨论review的结果。如果时间比较紧张，也可以不homework，大家直接在代码的讲解过程中进行review & discussion。这种review需要参加者精力高度集中，作者要按照scenario进行walkthrough。

9. Review结果一定要指定人验证是否按照结构进行修改。

10. 要让参加者积极参与、贡献自己的智慧，可以分为普通reviewer，critical reviewer，critical reviewer必须给出review结果。