今天我们谈谈代码检视如何做，在代码检视的活动中，最少是两个人的交叉检视，亦或者是集体review（代码编写者讲解代码基本逻辑，集体评审他的代码）。
（一） 开发者
在Peer pressure的环境下，开发者在编写代码的时候要
- 小心编写，代码逻辑在脑子里多过几次（预演）
- 为了在交给别人检视的时候省点力，多注释和多次提交
- 遵照团队的编码规范/约定来编码
- 单步调试，尽可能减少被他人检测出缺陷
- 自我逐行审查
这里的代码逻辑预演非常重要，很多异常处理，资源使用等都可以在这个环节考虑清楚，从而避免后面代码大改。在我刚毕业最开始写代码的时候，发现我的编码效率和旁边的老大不是一个档次，经常是他用1个小时搞定的事情，我花了一整天，后来老大给我辅导了一下，这里当然有对业务的熟悉因素，但是当老大观察了我的编码调试习惯之后就一针见血的诊断出了我的毛病，每次我都是直接写代码，写完代码直接编译，然后就是编译不过，接着看着编译错误修改，改完一个编译一下，循环进行，老大就说了，你写完代码后先自己读一下代码，然后在脑子里面过电影一样过一遍，想想有没有异常点没考虑，资源使用又如何，是否有低级错误，编译错误等等。我按照这个方法，逐步改变了我的习惯，之后效率也是追平老大了 :-)
敏捷软件开发中有关于源代码就是设计的论述，在我看来，源代码是能够传递这些信息的，不过，如何表达出设计信息，除了代码本身之外，还需要一定的注释，通过注释描述API的用途，参数表达意图，模块与模块之间的关系，消息的传送机制，业务的交互流程，这些都是可以纯文本形式的，不信你看个RFC（https://www.rfc-editor.org/rfc/rfc2543.txt）
除了体现设计之外，代码注释还应该体现代码编写者的信息，代码评审者的信息，这样你在后续出问题后就可以回溯到是谁编写和评审的，之后可以让代码编写者和评审人一起反思，给出改进和启发点，这样个人能力就能极大的提升，也形成了团队的代码编写和评审经验。
计算机底层有物理层，链路层，中间是网络层和传输层，上层就是应用层，中间和上层都有大量协议，特别是上层有着大量的协议，为什么要有协议，就是为了大家尊重相同的规则，可以有效率的沟通，而人与人之间的沟通也是一样，要想高效率的沟通就得有一些协议，而在代码编写的世界里，同一个团队也应该有代码编写的”协议“，大家共同的约定和编码规范和规则，这样互相代码检视的时候就会快速，高效，尽可能少的误解，同样，在编码六个月后，你回头看自己当时写的代码就会更加流畅和亲切（在心理层面算是某种安全感吧：））
还记得电影《低俗小说》中的“问题解决者”吗，在处理突发事件时能够快速熟练的确定处理步骤和备选方案，并且精确到分钟，冷静和全面考虑问题。这些在问题解决者手上已经是经过大量的平时训练了。而我们在单步调试和代码逻辑预演中也一样，需要平时足够的积累，形成习惯，成为真正的“问题解决者”。代码逻辑预演是在脑子里面过电影，而单步调试就是在实际操作层面来练习了。
在H公司有一个C语言代码审查九字真言
- 看见了If，就想Else。
- 看见malloc，就去找Free。
- 函数调用要小心，需要看看返回值。
- 看到for循环，就找边界值。
- 看见return要注意，要去前面找资源。
- 看见数组把神提，问题往往在下标。
- 不要小看字符串，长度是个大问题。
- 得到函数不要急，看看变量初始化，各种路径要小心。
- 赋值函数最危险，变量没有初始化。
九句真言不孤立，相互结合显神威。
初次见到这个的时候，我感觉我得到了一本武功秘籍，就像得到“先练神功，必先自宫”的辟邪剑谱，嗯，貌似不太恰当的比喻：），仔细看看， 这个就是平时的编码跳过的“坑”的总结啊， 除了这个，我能想起来和这个辟邪剑谱匹配的就是C代码界的九阴真经----微软出的《C陷阱与缺陷》，全是走过的坑和解决方法。我认为开发人员应该建立自己的“辟邪剑谱“，这需要对我们每次挖过的坑形成总结，模式，进而在每次自我逐行审查的时候，随时在脑子里面可以调用。
（二） 检视者
如果辟邪剑谱真的神（管用），那么就可以广为传播了，形成团队的九阳神功了，前面我们讲过代码检视的必要性，实际上交叉检视或者集体review能够给我们带来大量的好处
- 分享我们的工作成果，辟邪剑谱到九阳神功的进化
- 提供反馈，促进团队成员间的沟通交流
- 让我们对核心交付件--代码负起责任来
- 代码对于新人的示范作用
这里讲到的辟邪剑谱需要怎么形成呢，可以分为几个步骤
- 分析收集/反馈的缺陷，是不是可以代码检视有办法发现这个缺陷
- 如果有（不考虑无的情况，因为那得在写篇文章），举一反三，是不是有类似的问题
- 如果有（无就跳过此步），总结模式，形成正则表达式规则，在代码查看软件（比如source insight或者ATOM等）中利用规则搜索出所有类似模式的代码列表。
- 逐个排查是否有缺陷。
- 把正则表达式规则纳入辟邪剑谱的招式中。
举个例子
有如下的代码
while (c = ' ' || c == '\t' || c == '\n')
c = getc (f);
这里的第一个判断，开发者（也许他写代码的时候不开心）把 == 写成了= ，while的条件变成了赋值，无论变量c是什么值，while条件的结果都是1，死循环缺陷。
在发现了这个缺陷之后，就可以总结了，形成我们的正则表达式规则
^ (while) (\w+\s+=
注： 在sublime text测试OK
然后在代码浏览软件中全局搜索，得出while循环中有=号的列表。
接着逐个排查是否有类似的缺陷，最后把规则纳入辟邪剑谱，对全人类，哦，不是，对团队全员发布，全民使用。
有了武功秘籍之后，那么发现缺陷之后，如何向开发者反馈呢，很多人检视完后觉得找出了别人的毛病，然后直接给开发者指出错误，像个老师一样，指出问题后，不忘补一句，这么低级的问题你也犯（代码开发者在心里恨死你，嘿嘿），殊不知，别人要是这么说你，你自己什么感受。在指出别人缺陷的时候，应该有着同理心，务必再心里假设他们都比你聪明，另外在交流过程中杜绝使用你，你们，全部改为我们，咱们，最最重要的一点是建设性的提出问题，然后共同讨论如何解决和避免。一个小技巧，反馈缺陷的时候尽量保持微笑和耐心。
一旦形成了反馈，交流，改进，进入良性循环，开发者和检视者就会形成对代码负责人的态度，前面提到的代码注释中加入代码编写者和评审者，就是一个辅助手段，曾见过一个高手，写出了9千多行代码（时钟程序）在通信网络运行10几年，从没有出过一个缺陷，看他的代码，注释里面赫然写着他的大名，经过时间的洗礼，实际上这个代码就是他之所以为高手的极好证明。开发者和检视者都应该对自己负责的代码负起责任来。
最后，代码交叉检视和集体review对于新手来说，是个极好的学习机会，技能学习到高手的代码风格和设计思想，同时应用辟邪剑谱的招式，运用熟练，必然成为下一个高手。
（三）总结
总之，不做代码检视你会很吃亏，哈哈
我的微信公众号：瓦力工坊
我的微信：jhhuawei
