代码评审带给我的收获与思考

 

在数字烟草部进行代码评审已有些日子了，对于我来说，帮助是很大的，相信对于其他的同事肯定也有不少收获。现在我把我的收获和大家分享一下：

首先， 代码是可以写好看的，只要自己往这方面努力 。经过代码评审中大家的交流，以及通过制定一份编码规范来统一大家的编码风格，我现在写的代码与几个月前写的代码拿来作比较，连我自己都觉得过去写的代码怎么看，怎么不顺眼。原来是过去写代码的时候，自己就是一个“差不多”先生，只要能实现功能，代码看着差不多就行了，脑子里就缺少了这样一根筋，没有考虑如何才能使代码更好看些。后来开始了代码评审，一是有了一份编码的“法律”需要遵守，其次是在评审的时候要把自己的代码拿出来给他人看，所以自己在编程的过程中就下意识地提醒自己，尽量使自己的代码在外观上漂亮一些，如果自己都看不过去，还好意思拿给大家看吗？所以现在编写的代码比过去相对好了很多。

其次， 代码外观好看了，内在也要美 。 代码的外观指的是代码的风格、排版与布局等等，而这里的内在，我指的是隐含在代码中的设计思想。记得有一次代码评审，在评审之前我充分地调整了我要提交代码的风格布局，使一切都遵照规范行事，心里暗自想这下该没有什么问题了吧，然后信心十足地把代码提交了上去。在代码评审的时候，轮到评审我的代码，我虽以为没多少问题，不过俗话说当局者迷，我还是认真竖起两只耳朵听大家的高见。结果大家你一言我一语地一下又找出了一大堆问题，说得我都有点冒冷汗。其中有一点现在我仍记忆犹新，就是晓春指出我检查权限的方法的问题，本来很简单清晰的逻辑，被我的 if 嵌套弄得乱麻麻的。是啊，简单就是美，为什么简单的东西不写得简单一点呢，就算是复杂的东西也要尽量做到简洁，也就是所谓的深入浅出。

最后， 他山之石，可以攻玉 。俗话说三个臭皮匠，抵个诸葛亮，群众的眼睛是雪亮的。大家凑在一起交流，也是好几个小诸葛了，不仅可以把错误挖掘得彻彻底底，把错误扼杀在萌芽状态，更重要的是我们还可以收获编码之外的很多东西。正好代码评审提供了这样一个平台，让大家一起分享各自的经验，特别是对像我这种刚刚踏上编程之路的小虾米来说，能得到各位有经验的前辈的指点，听听前辈们的经验，是非常有益的。平时大家的工作都很忙，在一起交流的机会是不多的，交流技术的机会就更少了，而交流的重要性不需要我来多说，古人云他山之石，可以攻玉就是这个道理，闭门造车是造不出奔驰、宝马来的。而且就是他山无石，也是可以攻玉的。相信诸位有这样的体验，你走到另一个程序员身旁说：“我遇到个问题，你有时间帮我看看吗？我想了好久了”。然后你就开始描述你遇到的麻烦：“它不可能是这个地方引起的，因为这里我已经做过控制，也不可能是那里造成的，因为那边我也做了处理；并且它不可能由。。。。。。，哦，一定是这个地方引起的，因为。。。。。。，谢谢”。你请的帮手还没有机会发言，你就已经自己搞定了。这个他山的效果，真是有些不可思议，代码评审让我们能够观览众山，领略无限的风光；代码评审让我们能够站在巨人的肩上，看得更远。

 

代码评审的好处多多，大家是有目共睹，但毕竟代码评审也消耗了一定的资源，占用了大家一定的空间和时间，那是不是我们获得目前的好处就满足了呢，然后就天天津津乐道，碰到别人就说，“我们已经进行代码评审了，看这些就是我们取得的成绩”。显然不能，我们在这个评审的过程中是在往前走，比如刚开始的评审更关注代码的风格，后来的评审还关注代码的思想；刚开始的评审通过网络会议的形式进行讨论，后来的评审采用圆桌会议的方式来进行讨论；刚开始的评审中代码的作者只是把其代码搬出来就行了，后来的评审中代码的作者需要讲解其代码的背景及流程。。。。。。但我们也不得不看看在这个代码评审的过程中有何欠妥的地方。代码评审是为了提高我们项目的质量，降低开发、维护项目的代价，前面提到代码评审本身也是有代价的，我们能不能通过对评审本身进行一个评审改进呢？至少我认为是有必要的。下面我就提提我认为还需要改进的地方。

首先，在评审的代码的量上应该把握一个度。我认为在我们从开始进行代码评审一直到现在，评审的代码都有点偏多。代码一多，我就感觉在我的脑海里就很难留下深刻的印象，时间一久也就忘了。说到代码的量，其实跟代码的难易程度有关系。相信让大家看一万行的“ a=1 ” , 两分钟就够了，当然这有点夸张（哪有这么好读的代码），但有研究建议对于高级语言编写的应用程序代码，评审人员可以每小时检查 500 行代码。对于高级语言编写的系统级代码，评审人员可以每小时检查 125 行代码。高效的评审可能与这个速度相比有一个较大的变化，比如我们两个小时的评审，可以评审好几千行代码，而我们真的很高效吗？

其次，应该有一个评审的核对表。我们在评审中主持人也兼记录员对整个评审的结果和情况也做了一个大致的记录。但并没有一个列表对从第一次评审到现在的评审的过程中所出现的问题进行完备的记录。这次评审出现的问题，记录在这一次的评审总结中，那一次的评审出现的问题，记录在那一次的评审总结中，各是各的。如果我们准备了一份纸质的完备的核对表，那将对我们的评审是很有帮助的。评审的人员可以将注意力集中于曾经发生过的问题上，这将提高评审人员的评审效率。其次，如果再次发现核对表中已经记录的问题，这就应该引起作者的重视了，因为这就意味着重复地犯同一个地方错误，当然我们不应该进行指责，如果让评审影响了我们快乐工作的心情，那是有害无益的。其实勇哥已经提供过表格的模版以及其他一些模版，只是我们还未用起来。

最后，评审会议应该在参与人员充分准备的情况下召开。最近有好几次的代码评审都是在快开会之前才把代码提交上去的，评审人员根本就来不及提前阅读一下所有提交的代码。要想在两个时左右的时间高效地评审完所有提交的代码是有难度的，而在没有预读过所提交代码的情况下，想高效地评审几乎跟飞机失事一样不容易。还有我们如果是提前一个随机的时间提交代码也不好，因为让我们时刻关注代码提交了没有是一件无聊又很累的事情，最好是定在会议召开之前某个确定的时间提交代码。这样大家习惯成自然，也不用说没有通知到自己这样的理由。

好了，对代码评审的拙见暂且就这么多，请大家多多评审指点，希望大家把代码评审进行到底。