dklogs

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

为什么要做代码审查呢？

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

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

代码审查有何好处呢？

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

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

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

如何去做代码审查？

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

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

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

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

转载请注明原文出处《代码审查――为可读性努力的巨大能量》 如无特别声明，所有文章均遵守创作共用 署名－非商业－禁止演绎 3.0协议。