代码走查

代码走查 (code walkthrough)是一个开发人员与架构师集中与讨论代码的过程。代码走查的目的是交换有关代码是如何书写的思路，并建立一个对代码的标准集体阐述。 在代码走查的过程中，开发人员都应该有机会向其他人来阐述他们的代码。 通常地，即便是简单的代码阐述也会帮助开发人员识别出错误并预想出对以前麻烦问题的新的解决办法。

当团队成员对代码进行讨论的时候，他们的讨论应该集中到一些重要的话题上，比如算法，基于对象的编程，类设计。 然而，许多代码走查不会做这些事，通常代码走查是枯燥的，烦人的，机械的。 这就是为什么许多开发人员讨厌这些。要使得代码走查变得很有效，那么这个过程就必须是有趣的，有创造性的。 很经常地，代码走查退化成了仅是关注于强制代码标准－－一个可以被自动执行的实践。当这种情形出现后，团队通常会觉得代码走查没有价值，然后将代码走查从他们开发过程中去除掉。这样便失去了他们可以从正确地执行代码走查的过程获益的机会。

--来自：天空之城

2为何要做代码走查编辑

代码可读性这个话题一直以来都是备受关注，但是可读性高与不高却没有统一的标准。毕竟各个公司，甚至于各个项目的规范都是不一样的。我们不能说一个抽象性极好，灵活度极高却让人十天半个月都难以搞清楚的代码的可读性高，也不能说一个长达几千行却从头至尾逻辑性比较好的代码的可读性差。那么怎样的代码才算是合理的，才算是可读性高的呢？我想不同之中必有共性，那就是经过走查的、能够被项目组其他成员接受并能尽快看懂的代码就是可读性好的。

为什么要做代码走查呢？

要对代码可读性做走查，这需要人力、物力、以及项目宝贵的时间。对于一个项目来说，成本是一个重要的考虑因素，然而走查无疑会增加项目的成本，那么为什么还要做走查呢？其实任何一个项目经理都清楚一个成功的项目都是难以一蹴而就的，开发过程必然会遇到各种各样的问题和阻力，这也验证了那句老话：“软件开发中唯一不会变的就是，需求永远会变化”。我们也清楚问题越早的被发现那么损失就会越小，补救花费的时间就会越少，自然成本就越低。但是我们有多大的机会可以尽早的发现问题呢？这不是我们说早发现问题，问题就会跟我们招手说：“看你态度不错，就让你早发现吧！”这么简单的。迭代开发为什么会出现，瀑布式开发为什么难以应对大型的商业、行业项目？思考一下我们不难发现，客户难以一次性的、整体的、详尽的把自己想要的东西表达清楚，只有当客户看见实实在在的东西之后，他才更明确自己想要什么。好比我们去买裤子，你告诉一个人说：“我要一条简约的牛仔裤”；然后那个人去帮你买，但是具体的颜色你确定么，是黑色还是蓝色？衣服的口袋你确定么，是有扣子的还是没扣子的？只有当你真真切切的到专卖店里面，看到了试过了你才能确定：我要的就是那条180的蓝色的口袋上没扣子的XXX牌的裤子。也就是说我们很少能够尽早的从客户口中获得问题，除非我们指着我们做出来的东西说：看看，这是不是你想要的。既然如此，要控制的不是尽早的去发现问题，而是如何在问题出现之后尽早的找出问题所在，并解决问题，进而降低项目的成本。

其实软件开发的主要时间是花费在调试上，然而调试中花费的大部分时间又在于读代码。倘若之前开发该模块的人员已远在天边，面对几千行混乱无序的代码任谁都难以承受。因而花费成本在代码走查上是值得的，而且是必须的。可惜的是，现在很少有人去关注代码的规范性、可读性，甚至在大公司都是如此。项目管理者过于注重项目的进度，只要开发者把自己的任务做完了，很少有人去关注他写的代码，甚至开发者自己都不会再去看。

代码走查有何好处呢？

首先代码走查可以提高软件的质量，以及可维护性。这样就可以减少查找错误的时间，提高解决bug的效率，提高开发效率的同时降低后期的维护成本。

其次，经过走查的代码是能够迅速被项目组其他成员看懂的，这样有利于项目其他成员更全面的了解业务，对于成员之间交流也有很好的促进作用，当其中负责某个模块的开发人员离职之后其他人员能够迅速的接手相关的开发，并能够尽快的培养新人弥补空缺。

最后，代码走查的过程是总结提高的过程，也是交流的过程，可以有效的提高开发人员的技术水平以及业务素养，增强公司的竞争力，通过总结交流甚至可以从不同项目中提取共性，做出相关产品，从而形成公司自己的核心竞争力，做到行业领先。

如何去做代码走查？

从参加人员来说，应该是项目的整体参与者，如果项目太大，整体参加的成本很高，那么可以以模块为组进行走查。因为他们之间负责的业务是紧密相关的，使用的技术是接近程度比较大的，因而开发的规范应该是统一的。

从走查内容来说，应该是代码的命名规范，以及组织结构。每个项目都有自己的规范，但是如果项目内部使用不同的规范必然会增加发现问题、解决问题的难度，同时增加后期的维护成本。

从走查时间来说，应该在每个模块开发完成之后进行，便于开发人员之间交流问题以及体会，并且每个人的讲解时间不要超过30分钟，因为模块的业务复杂度不会那么复杂，30分钟都讲不清的业务逻辑如何保证代码是清晰的。

从走查的结果来说，经过走查的代码应该是参加成员大部分能认同的，并且参加者每个人都能读懂的逻辑清晰的代码，并且通过交流提高项目成员的凝聚力，提高其业务认知度，最好能形成项目之间可以共同使用的产品。

---来自：51testing网站

3代码走查与代码审查编辑

代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法,

代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。

最近对项目组进行代码评审，发觉需要对代码评审中找到的问题进行一下分类，大概可以分成以下几类问题：

1. Comment

注释没写，或者格式不对，或者毫无意义

2. Coding Standard

没遵守代码规范

3. Existing Wheel

重复现成的代码，或者是开源项目，或者公司已有代码

4. Better practice

Java或者开源项目，有更好的写法

5. Performance bottle and Improvement

性能瓶颈和提高

6. Code Logic Error

代码逻辑错误

7. Business Logic Error

业务逻辑错误

代码审查列出问题的类型，并有解决情况报告