在一篇有关设计和代码复查的文章中， Kirk Knoernschild 提到，这种复查的承诺是改进软件质量、确保与标准的一致性，并且可以作为一种有价值的工具为开发人员服务，但是它们的执行方式却影响到了自身的价值。在某些组织中，它们可能真的见效；而在另一些地方，可能也不过是官僚作风的一种体现而已。
他认为下面这些就属于最糟糕的复查实践：迫害式复查——编写代码的开发人员有被攻击的感觉，甚感恐惧。
花括号复查——只强调排版结构和缩进之类的琐碎细节，而置更为严重的问题于不顾。
盲查——复查人在参与复查之前从来没有看过一眼代码，并在未经准备的情况下参加复查会议。
排它性复查——只拿出代码中的某一段样本来进行复查，把其他重要的部分都弃而不顾。
樵夫式复查——一直等到代码库变成庞然大物再进行复查，而这时要进行完整的复查已经变成了难如登天且事倍功半的任务。
令箭式复查——将复查活动形式化，只因为是管理层打算这样做。
世界性复查——在为数众多且大部分都与项目无关的人士之前进行复查，并因此令开发者惶恐不安。
Kirk 认为，为了进行有效的复查，团队必须力求将复查过程做到自动化，同时收集一些度量标准。团队还应该把反馈机制纳入他们现有的开发环境中，这样开发人员在准备提交代码前就会收到自动警示提示。
他提到有些工具可以将复查过程变得更加客观、关注点更为集中：
Kirk 还提到了一种用来进行复查的有趣方式，名为 20% 复查：
20% 复查的想法是很简单的：一旦开发完成了 20%，那么就应该进行一次复查。对有些团队来说，在每一次迭代中都进行 20% 复查会收到显著成效。它的效果 确实不错，不过如果开发团队可以成功地使用度量标准进行持续复查，那么针对每一个主要的系统功能进行 20% 复查就足够了。20% 复查应当关注初始设计和代码的整洁。在代码库大小相对易于管理时，上面提到的度量标准可以深入洞察代码的演化和发展状况。
他在文末又强调了要通过使用度量标准来将复查过程变得更具客观性、关注点更集中的重要性，以此作为全文的收束。自动化程度越高，就越容易达到这些标准，然后就可以进行有效的复查。复查应该尽早进行，这样开发者才能够把早期的收获用到开发过程中，复查的有效度不会受到损害。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论