本文转载自： FPGA的现今未微信公众号
注：本文由作者授权转发，如需转载请联系作者本人
无论是FPGA还是ASIC的开发者，都或多或少地做过代码检视（code review）。对于代码检视这项开发活动，不同的人，不同的公司都有不同的态度或者方法。有人觉得这个是提高代码质量的关键活动，有人觉得代码检视是浪费时间。作者的态度是支持前者：代码检视是一项非常重要的活动。作者就曾经使用的代码检视方法做一个总结，希望能让大家对这项活动有一个新的认识。
为什么要做代码检视
这个道理其实很简单，通过代码检视，提前发现问题，解决问题，提升版本质量，为项目成功保驾护航。另外，代码检视相互交流的过程，对个人而言也是一种能力提升的过程。
代码检视是一个团队活动，不是个人活动，也是团队开发水平的提升和开发实力展现的一种方式。
什么时候做代码检视
对于Verilog（VHDL）代码而言，什么时候做代码检视也是一个很重要的问题。个人认为有3个阶段可以做代码检视，各个团队根据项目实际情况选择。
1、RTL代码刚刚编写完成，这个时期的检视主要是检视方案是否有重大问题，代码和原始的方案是否能对应；
2、UT完成，项目在ST阶段，这个时期的检视主要是代码的全量检视，既对代码做一个通读的检视，主要是代码设计的逻辑是否合理。
3、上板测试阶段，这个时期的检视主要是针对某些专题做代码检视，比如FIFO的读写是否有溢出的可能等。
这3个阶段的代码检视重点各不相同，相互补充，肯定也会有重复的地方。具体做哪几个阶段的代码检视，需要根据团队的人力，项目进度，版本质量等因素综合考虑。
什么人参与代码检视
前面说过，代码检视是一个团队活动，而不是个人活动，所以代码检视的主体是项目组成员。代码的作者是代码检视活动主导者，项目组成员是参与者。除了本项目组成员，有条件的团队可以邀请其他团队有经验的专家一起参与。总之这是一个利用团队的力量解决问题的活动。
如何做代码检视
做代码检视是有讲究的，具体如何做，这里提供几条操作方法：
1、检视前，制定检视计划，即确认参与人、检视时间、检视内容等，尤其要明确本次检视的主要内容和目的，让参与者有目标感。
2、一次代码检视的时间，尽量不要超过半个小时，时间太长了，参与者很容易疲劳，检视效果不好。
3、在上述第一和第二轮检视（方案检视和全量检视）时，先在白板上画好被检视模块的方案图，给参与者讲解本模块的方案。检视代码的时候，对着方案图进行检视，模块作者要引导参与者将代码和方案图一一对应，让代码检视更加聚焦。
4、在上述第三轮检视（专题检视）时，一定要先有标准，比如对FIFO的检视，主要检视FIFO是否会空读满写情况，FIFO的空满状态是否可读等。
5、模块作者对参与者提出的疑问或者问题都要记录，检视后要认真答复，这是一个消除疑问和解决问题的过程。
6、模块作者对本模块没有信心的部分，要仔细重点讲解，让检视者充分理解方案，吸引检视者的注意力，充分利用团队的经验来提前发现问题。
7、对于检视发现的重大问题，或者有价值的问题，团队要给予即时激励，充分调动大家检视的积极性和参与度。
8、在版本后期稳定后，每次解决bug后提交代码时，尽量做一下所提交代码的代码检视，保证解决问题的质量。
以上几条操作方法，只是作者过去经验的总结，不一定适用每个团队。团队可以根据上述经验以及本团队的实际情况，制定适合本团队的可行的检视方法。
代码检视做的何种程度
从理论上讲，代码检视可以无止境的做下去，和仿真一样，只要你花时间，总能发现问题，但是性价比会越来越低。代码检视也不可能发现所有的问题，所以代码检视一定要有个度。
首先提前做好代码检视计划，比如按照上述说的计划三轮代码检视，检视完成后需要根据版本质量来确定是否需要继续。如果版本质量较好，则没有必要继续进行代码检视，如果版本问题比较集中，那就对集中的问题做专项检视。比如计数器控制总是出现翻转，那建议对代码中所有的控制计数器单独再做一次代码检视。
总之，代码检视是一种团队活动，要充分利用团队的力量来提前发现问题和解决问题，同时也是相互交流学习的过程。关于代码检视，如果你有兴趣，欢迎留言交流。
