也谈Code Review

自从极限编程诞生起，我就一直在听说结对编程是个好东西。所有的敏捷传教士们都在告诉我们：结对编程能提高代码质量，有助知识共享，甚至激发开发效率，同时，还能深度拉近程序员之间的感情关系（参看拥抱编程）。

　　那些拒绝结对编程的人都被认为是独行客，懒蛋，或社交恐惧症患者。然而，我不属于任何一种（至少我自己是这么想的），可我仍然讨厌结对编程。为什么我会这样？下面是理由。

　　我们这个社会已经不再崇尚沉默是金，外向性格受青睐。所有的事情都要用合作的方式完成，每个人都要时刻准备好为他人服务，个人空间已不再存在，工作成绩不再归功于某个人。基本上，大家都认为三个臭皮匠胜过一个诸葛亮。

　　然而，很显然，我们可以看到，有些事情并不是这样的。即使在编程界，很多伟大的创新和杰出的软件都不是由一个团队或某个组合创造的，而是来自一个人的努力。Ant，给Java社区带来巨大飞跃的软件，就是由一个人在从欧洲飞往美国的飞机上开发出来的。还有，一些更近些的例子，Notch 开发 Minecraft，Marco Arment 开发 Instapaper，GabrielWeinberg 开发 DuckDuckGo，全是单枪匹马的成就。事实上，地球上最有影响力的一个编程大师，Steve Wozniak，有一句著名的教导：

“单干，拒绝团队，拒绝委员会。”

　　视线放的更远些，很多科学界和艺术界伟大的思想家都是喜欢埋头工作的类型（内向性）——达尔文，爱因斯坦，牛顿，就连漫画家Seuss博士也是这样。甚至诺贝尔文学奖的得主、《愤怒的葡萄》的作者 JohnSteinbeck 也要在这事情上插嘴说：

两个人一起什么都干不成。合作永远是不成功的——无论是在音乐创作，艺术创作，诗歌创作，数学研究，还是哲学理论研究。只有在奇迹诞生之后，团体才去开发/扩展它们，但团体永远发明不了什么。伟大的思想往往生长于孤独的心里。

　　结对编程，作为“everything-together”文化的延续，渗入到人们的思想中，以至于很多人认为一个人独自工作不仅低效率的，而且很无趣。而对于我来说，这正好相反。我的最佳工作状态就是与世隔绝，大脑流状态是我作为程序员最享受的事。并不是我喜欢做独行客，或我是圣人不会犯错。我十分倡导严格的代码审查，我每天都从别人的观点/指教中受益。我只是认为结对编程不能让我成为一个更好（更高兴）的程序员。

　　

扯了这么多别人的极限编程、高效开发，跑偏了。。。。。。我们还是来说点正事吧：code review。为完成一个软件项目需要多个成员的参与，因此存在编码风格和质量上的差异。尽管在一个项目开始之初，团队内部就对编码进行了格式化上的规范，但是在实际过程中，还是搀杂了许多个人的因素，比如习惯，思维方式等等。在整体的角度上讲，差异存在越多对项目代码的可读性及维护性影响也越大。又由于一些人可能限于水平，在编码过程当中引入了较低级且显而易见的错误，比如，资源没有释放，造成泄漏。这些隐患如果不是通过Code Review来发现和纠正，通过测试是很难发现的。随着时间的推移，积累的问题会逐渐增 多，到一定程度的话就很难再去着手处理。 Code Review可以“防患于未然”，确保质量，也能提高整个开发团队的开发水平。

         不过我们确实要制定一些基本原则：

1、 以提高代码质量为基本目的；

2、 以促进团队内部知识共享为基本目的；

3、 以提高团队整体水平为基本目的；

4、 以鼓励工程师相互学习为基本目的；

 

那我们需要review些什么呢：

1结构问题

代码最大的问题，不是一两个地方有技术缺陷，也不是业务逻辑错误，而是整个软件设计的不好。前两者更容易通过测试或使用来发现和更正，但后者就不同了。如果回想一下自己见过的各种烂摊子，是不是有同感？具体哪里有问题怎么改说不上来，就是整个软件看上去混乱无章，无从下手。

具体结构问题包括：重复拷贝代码（不封装函数，不用Template/泛型……），函数过长（超过一屏幕就叫过长），错误封装（不恰当的public/不用Interface/不内聚/强耦合/在类中封装了无关方法……），内容错误（多个无关类置于一个文件/不恰当的命名……）等等。

改正结构问题，是从编写可靠软件向编写精美软件迈进的重要方法。

2业务逻辑问题

就是软件是否与需求的要求符合的问题。审核者和被审核者经常对业务需求的理解有差异，借此机会同步一下，必要时引入PO（产品经理/产品负责人）。

有人会说业务逻辑问题不是一测试就知道了吗？可是测试一般发生在很久以后，有些逻辑测试还需要一定的触发条件，而且测试只会发现失效（failure,与预期不符）而不能发现缺陷（defect,具体哪里出了错），等积累长了，谁也找不到原因了。

3编程素养问题

很多问题属于那种“这样也行那样也行”的状态，比如命名/初始值/缩进/断行……但是高手的做法总是比新手好一些。

比如bool result= true;这句话就有问题，刚初始化就先宣布成功，必有隐患。这是一个真实案例，而下面也的确有一个分支错误地返回了这个true（实际案例是个HRESULT）。而发现这个问题，不是测试而是代码检查。实际上测试几乎发现不了这些问题，比如上面那段代码会在某文件打不开的时候错误地返回这个true，而在测试中几乎不会故事破坏那个文件来测试其结果。

4 可执行性

我们要去做一件事情，必须是可以执行的，如果执行难度很大，导致action无法得到实施，那就是得不偿失浪费时间精力。由此可见形成基本的review规则必不可少。

 

CodeReview的方法还有很多，比如结对编程也是一种很好的形式，特别适合敏捷XP团队。最后希望我写的对大家能有一点点的帮助。