代码审查――为可读性努力的巨大能量

代码可读性这个话题一直以来都是备受关注但是可读性高与不高却没有统一的标准。毕竟各个公司甚至于各个项目的规范都是不一样的。我们不能说一个抽象性极好灵活度极高却让人十天半个月都难以搞清楚的代码的可读性高也不能说一个长达几千行却从头至尾逻辑性比较好的代码的可读性差。那么怎样的代码才算是合理的才算是可读性高的呢我想不同之中必有共性那就是经过审查的、能够被项目组其他成员接受并能尽快看懂的代码就是可读性好的。为什么要做代码审查呢要对代码可读性做审查这需要人力、物力、以及项目宝贵的时间。对于一个项目来说成本是一个重要的考虑因素然而审查无疑会增加项目的成本那么为什么还要做审查呢其实任何一个项目经理都清楚一个成功的项目都是难以一蹴而就的开发过程必然会遇到各种各样的问题和阻力这也验证了那句老话“软件开发中唯一不会变的就是需求永远会变化”。我们也清楚问题越早的被发现那么损失就会越小补救花费的时间就会越少自然成本就越低。但是我们有多大的机会可以尽早的发现问题呢这不是我们说早发现问题问题就会跟我们招手说“看你态度不错就让你早发现吧”这么简单的。迭代开发为什么会出现瀑布式开发为什么难以应对大型的商业、行业项目思考一下我们不难会发现客户难以一次性的、整体的、详尽的把自己想要的东西表达清楚只有当客户看见实实在在的东西之后他才更明确自己想要什么。好比我们去买裤子你告诉一个人说“我要一条简约的牛仔裤”然后那个人去帮你买但是具体的颜色你确定么是黑色还是蓝色衣服的口袋你确定么是有扣子的还是没扣子的只有当你真真切切的到专卖店里面看到了试过了你才能确定我要的就是那条的蓝色的口袋上没扣子的牌的裤子。也就是说我们很少能够尽早的从客户口中获得问题除非我们指着我们做出来的东西说看看这是不是你想要的。既然如此要控制的不是尽早的去发现问题而是如何在问题出现之后尽早的找出问题所在并解决问题进而降低项目的成本。其实软件开发的主要时间是花费在调试上然而调试中花费的大部分时间又在于读代码。倘若之前开发该模块的人员已远在天边面对几千行混乱无序的代码任谁都难以承受。因而花费成本在代码审查上是值得的而且是必须的。可惜的是现在很少有人去关注代码的规范性、可读性甚至在大公司都是如此。项目管理者过于注重项目的进度只要开发者把自己的任务做完了很少有人去关注他写的代码甚至开发者自己都不会再去看。代码审查有何好处呢首先代码审查可以提高软件的质量以及可维护性。这样就可以减少查找错误的时间提高解决的效率提高开发效率的同时降低后期的维护成本。其次经过审查的代码是能够迅速被项目组其他成员看懂的这样有利于项目其他成员更全面的了解业务对于成员之间交流也有很好的促进作用当其中负责某个模块的开发人员离职之后其他人员能够迅速的接手相关的开发并能够尽快的培养新人弥补空缺。最后代码审查的过程是总结提高的过程也是交流的过程可以有效的提高开发人员的技术水平以及业务素养增强公司的竞争力通过总结交流甚至可以从不同项目中提取共性做出相关产品从而形成公司自己的核心竞争力做到行业领先。如何去做代码审查从参加人员来说应该是项目的整体参与者如果项目太大整体参加的成本很高那么可以以模块为组进行审查。因为他们之间负责的业务是紧密相关的使用的技术是接近程度比较大的因而开发的规范应该是统一的。从审查内容来说应该是代码的命名规范以及组织结构。每个项目都有自己的规范但是如果项目内部使用不同的规范必然会增加发现问题、解决问题的难度同时增加后期的维护成本。从审查时间来说应该在每个模块开发完成之后进行便于开发人员之间交流问题以及体会并且每个人的讲解时间不要超过分钟因为模块的业务复杂度不会那么复杂分钟都讲不清的业务逻辑如何保证代码是清晰的。从审查的结果来说经过审查的代码应该是参加成员大部分能认同的并且参加者每个人都能读懂的逻辑清晰的代码并且通过交流提高项目成员的凝聚力提高其业务认知度最好能形成项目之间可以共同使用的产品。