代码检视

    经历越多家公司，越让我明确代码检视的重要。很有幸进现在这家公司吧，在进公司的时候，让我学到很多以前没接触和没掌握的技术。像动态模块加载、服务框架和数据配置等比较有意思和实用的技术，当时的感觉可以用如梦方醒来形容，如果不够的话，那像刘姥姥进大观园的感觉更贴切一点。随着负责的模块越来越多，一个声音声音在呼唤：这什么啊，这也叫代码？是，这能叫代码吗？简直是一团糟，代码不规范就算了，可是重复代码，无用代码一大堆，这导致在学习防火墙模块的时候，看到很多隐藏问题。最让我受不了的，既然有人在定义变量的时候，很多用上自己的名字来做标识，什么意思嘛！
    每个人的能力不一样，所以写出来的代码的质量不一样，这正是高手和一般程序员的差别，这正是他们拿不同工资的体现。可是编码这跟技术无关，这是一种心态问题，只要你正视这个问题，心里存着代码规范，在编码的时候，随时养成重构的习惯，可以写出很漂亮的代码。如果要强制把代码规范实施到项目中，我觉得华为时的一种做法很不错，那就是代码检视。不过我不赞同他们的检视方法：谁的代码要被检视，他就把代码发给几个检视专家（说是专家，实际上也是几个当时有时间的程序员），检视专家阅读这些代码，再提检视意见，然后大家碰个头看这些意见是否可行，最后再改进代码中。
    我为什么说这种方法不好呢？首先，检视都是几个星期一次，那时被检视对象都已经写了N多代码了，检视专家要来检视这些代码，都要花大半天一天的时间，要看懂他的代码都很难了，这时来提意见，有建设性的就很少了，而且细微处根本检视不到。其次，由于代码太多，有的实在太烂了，提都不想去提意见。再次，专家的能力不一，有的去做检视，不如说去学习。所以效果并不明显。
那么怎么样做检视效果最佳呢？我觉得检视专家最好是两个，一个技术能力强，一个结构能力强。为什么只要两个，而不集思广益呢？（一般一个位置坐不下多个人啦）因为我更赞同结队编程，两个检视专家和被检视员坐在一起，由被检视员从头开始讲解他的代码，这有两个好处，首先加深他对代码的理解，如果不理解就讲不下去；其次，培养他讲话的能力，程序员一般都是讲话能力不强。检视专家在听的时候，可以随时提出疑问和指出不足。现在发现为什么说要两个专注不同的专家了吧，技术强的可以随时指出代码中的技术问题，结构强的更专注代码的结构是否合理，可能啰里八嗦的一大堆，重构成一个模式更合适一点。
最重要的一点是什么呢？他们三个一起对代码进行检视，可以随时对某一点进行深入讨论，每个人的能力不同，所以讨论的时候，会把各自的知识在讨论中表现出来，这有利于知识在团队中传播。而一个团队要成长，每个成员的能力的提高是必不可少的。
    综上种种，我觉得代码检视在项目中的重要性不可忽视，而采用正确的方法将事半功倍。