Posts Tagged ‘code review’
code review 的目的和意义 codereview是不解决程序的编译问题的，它主要的职责是保证代码的质量。 Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码，测试过程和注释进行检查。 code review的三个前提： 1）.代码可以顺利运行； 2）.项目测试人员已经做过单元测试； 3）.其次最重要的是开发人员对代码已经基本了解 code review所做的工作： 1）.完整性检查（Completeness）； 2）.一致性检查（Consistency）； 代码的逻辑是否符合设计文档； 代码中使用的格式、符号、结构等风格是否保持一致； 3）.正确性检查（Correctness） 代码是否符合制定的标准 所有的变量都被正确定义和使用 所有的注释都是准确的 所有的程序调用都使用了正确的参数个数 4）.可修改性检查（Modifiability） 代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等) 代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的 代码是否只有一个出口和一个入口（严重的异常处理除外） 5）.可预测性检查（Predictability） 代码所用的开发语言是否具有定义良好的语法和语义 是否代码避免了依赖于开发语言缺省提供的功能 代码是否无意中陷入了死循环 代码是否是否避免了无穷递归 6）.健壮性检查（Robustness） 代码是否采取措施避免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等） 7）.结构性检查（Structuredness） 程序的每个功能是否都作为一个可辩识的代码块存在 循环是否只有一个入口 8）.可追溯性检查（Traceability） 代码是否对每个程序进行了唯一标识 是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应 代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录 是否所有的安全功能都有标识 9）.可理解性检查（Understandability） 注释是否足够清晰的描述每个子程序 是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释 使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度 是否在定义命名规则时采用了便于记忆，反映类型等方法 每个变量都定义了合法的取值范围 代码中的算法是否符合开发文档中描述的数学模型 10）.可验证性检查(Verifiability) 代码中的实现技术是否便于测试 Code Review经验检查项 以下是在实践中建立的检查列表（checklist），通过分类和有针对性的检查项，保证了Code Review可以有的放矢。 1 [...]
首先，我们先来看看Code Reivew的用处： Code reviews 中，可以通过大家的建议增进代码的质量。 Code reviews 是一个传递知识的手段，可以让其他并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。 Code reviews 也鼓励程序员们相互学习对方的长处和优点。 Code reviews 也可以被用来确认自己的设计和实现是一个清楚和简单的。 你也许注意到了在上面的Code Reivew中的诸多用处中，我们没有提到可以帮助找到程序的bug和保证代码风格和编码标准。这是因为我们认为： Code reviews 不应该承担发现代码错误的职责。Code Review主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该由单元测试，功能测试，性能测 试，回归测试来保证的（其中主要是单元测试，因为那是最接近Bug，也是Bug没有扩散的地方）。 Code reviews 不应该成为保证代码风格和编码标准的手段。编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队Review的时候，代码就应该是符合规 范的，这是默认值，属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。我个人认为“meeting”是奢侈的，因为那需要 大家在同一时刻都挤出时间，所以应该用在最需要的地方。代码规范比起程序的逻辑和对需求设计的实现来说，太不值得让大家都来了。 10年前，上面这两件事会是理所当然的（10年前的中国的软件开发还没有Code Reivew呢）。今天，在中国的很多公司上面这两件事依然被认为是Code Reivew最重要的事。所以，我能够看到很多开发Team抱怨Code Review就是一个形式，费时费力不说，发现的问题还不如测试，而评审者们除了在代码风格上有些见术，别的也就没什么用了，长而久之，大家都会开始厌烦 这个事了。 所以，在今天，请不要把上面的那两件事分散了Code Review的注意力，取而代之的是，对于Bug，程序的作者要在Review前提交自己的单元测试报告（如：XUnit的测试结果），对于代码规范，这 是程序作者自己需要保证的，而且，有一些工具是可以帮你来检查代码规范的。 当然，上述这些言论并不是说，你不能在Code Review中报告一个程序的bug或是一个代码规范的问题。我只是说，那并不是Code Review的意图。 下面是我们认为的几个小提示可以让你更好进行Code Review这项最有价值的活动。 1. 经常进行Code Review 以前经历过几个相当痛苦的Code Review，那几次Code Review都是在程序完成的时候进行的，当你面对那近万行的代码，以前N多掺和在一起的功能，你会发现，整个Code Review变得非常地艰难，用不了一会儿，你就会发现大家都在拼命地打着哈欠，但还是要坚持，有时候，这样的Review会持续3个小时以上，相当的夸 张。而且，会议上会出现相当多的问题和争论，因为，这就好像，人家都把整个房子盖好了，大家Review时这挑一点那挑一点，有时候触动地基或是承重墙 体，需要大动手术，让人返工，这当然会让盖房的人一下就跳起来极力地维护自己的代码，最后还伤了团队成员的感情。 所以，千万不要等大厦都盖好了再去Reivew，而且当有了地基，有了框架，有了房顶，有了门窗，有了装修，在各个时候循序渐进地进行 Review，这样反而会更有效率，也更有帮助。 下面是一些观点，千万要铭记： 要Review的代码越多，那么要重构，重写的代码就会越多。而越不被程序作者接受的建议也会越多，唾沫口水战也会越多。 程序员代码写得时间越长，程序员就会在代码中加入越来越多的个人的东西。 程序员最大的问题就是“自负”，无论什么时候，什么情况下，有太多的机会会让这种“自负”澎涨开来，并开始影响团队影响整个项目，以至于听不见别人的建 议，从而让Code [...]
