我从事了近6年的Java开发，经历过几个人的团队，也参与过几百人的大项目。对于代码检视活动，我有幸地参与了很多很多次，也尝试过多种不同的检视形式。但得出一个事实，很少有团队很重视代码检视活动，能够从始至终地坚持做。
从新员工进公司或者部门开始，代码检视的重要性被反复强调和宣传，以至于很多新兵蛋子都可以说上几个代码检视的好处，比如，提前发现bug节约成本、团队内知识分享、提升项目的代码水平等等。但是，在具体实践时，代码检视活动却总是不尽如人意。如检视人员参与不够，检视出的问题价值不高，代码检视活动被其他事情中断，检视结果一直未闭环等。
为什么代码检视活动常常被忽视？我觉得可以总结为以下几种情况。
1. 代码检视没有标准，无所适从。对于检视什么内容没有统一的认识，检视的重点往往由参与人的水平决定，不少人只是拿着公司、部门的代码规范做Check。我经历过很多次飞检活动，一伙人总徘徊在注释、变量、方法命名等风格类问题上（我并不是说代码风格不重要，很多工具可以保证风格大致的一致）。这种检视的结果是，开发人员对你的检视意见不认可，而你却觉得检视很重要。我听到过太多开发人员对此的抱怨。
2. 对于个人而言，未明显提升编码水平。检视意见不能真正提升代码的质量（如架构、可维护性、可靠性、安全性等）。参与的人对具体的业务不熟，仅凭感觉和经验做一些检视，往往仅检视出一些鸡毛蒜皮的问题。而对开发人员来说，他们对代码检视有更多的期望，他们期望能够发现代码架构、代码的组织结构、业务的一致性等类别的关键问题，他们期望学会识别代码坏味道的技能，他们期望提升优化坏味道代码的能力。如果你们只是在Check规范，收益比实在是太低。
3. 对于团队来说，短期收益有限。对于团队而言，在有限的资源内最大化当前利益是最实在的选择，而对长期的收益，往往会被忽视。不可否认的是，在我参加的所有团队中几乎都是一样的。我所在的公司体量很大，每个版本都有很多KPI指标，如圈复杂度、方法的最大行数、代码重复度、静态检查、白盒等等指标。这些量化的指标是团队绩效考核的一部分，当然成为工作的一部分。对于团队来说，好的KPI远比代码检视收益来的直接。当然，实际结果往往是，由于代码质量问题，项目组一直都在解决问题或者解决问题的路上。但谁也不去承认和代码检视的关系究竟又大，同时，随着组织的变化、架构变更，半年一年后会怎么样有谁会顾虑呢。眼前的利益才是最实在的。
4.检视是一种压力，而不是技术人员的互动。代码检视活动本应该是开发人员主动提升代码的一种方式，开发人员拿代码作为载体互相交流，享受其中的碰撞火花。但有些大佬喜欢将检视结果作为员工绩效考核的一部分，参与检视只是作为工作的一项任务，甚至产生开发人员间的不信任情绪。
5.团队存在一种病——做得好了并不能得到认同。有个同事跟我讲过一个真实的例子，他们团队在刚接手业务时，当时发现了一个偶现的bug，然而他们也忘记修改了。在一年后的某一天，有个局点出现了该bug，他快速响应并解决了该问题。最后，一线先感谢了他一番，接着，项目组的领导、领导的领导将他树立为标杆。他说，假如他在一年前解决了该问题，也许他什么也不是。
不可否认，我们往往都存活于功利性团队中。功利性团队无可厚非，如果我们把原因归结于功利性团队的文化上，那我们什么也做不了。我们要探讨的是在已有环境下，如何让代码检视回归到合适的位置，从而在团队中发挥一些作用。
1. 让开发人员得到成长。一方面，让真正懂业务、能力强的人参与代码检视中，另一方面，检视过程更关注业务的一致性、代码架构、代码的组织结构等问题，并形成统一的原则。对于发现的问题，检视人员给出代码怀味道的理由，共同讨论形成更合理的方案。在我们现在的代码检视活动中，我们常发现实现与需求要求不一致、方法职责不单一等问题，也检视出不少违反安全、可靠性、可维护性、性能等问题。我们针对这些问题，与开发人员一起分析讨论、总结出设计原则与方案。
2. 将代码质量提升形成可量化的数据。不少技术人员认为KPI无法反映出检视结果，亦或是认为KPI纯粹是为了迎合大佬，没有产生额外的收益。但是，技术方案的落地往往需要大佬们决策，没有量化的指标对于决策是困难的（你懂的）。我们团队将检视意见分为代码实现偏差、代码bug、安全漏洞、代码坏味道几类，分类统计后呈现给大佬们，并跟踪问题闭环。此外，我们将典型问题做成案例，定期在团队内外分享。最终让检视工作有序的落地。当然，对于某些大佬喜欢拿结果diss人的，统计结果要有一定的灰度。尽量让结果和案例对事不对人。
3. 以开放的心态检视代码，将代码检视当做是一种交流。面对面的提问我认为是最好的检视方式，远比直接评论更有效。每个人都可以提出自己的问题，而每个熟悉代码的人也都可以回答问题。我们常常的提问有：代码实现了什么功能，修改了哪些内容来支持这些功能；哪块代码是你自己认为写得不满意的，为什么觉得不满意；这个类/方法的功能是什么。在不断的问答中找出代码不合理的地方，最终形成一致性认识。无论在讨论中谁说服谁，大家都进行了思考、交流与碰撞，有碰撞就有提升。我认为这个非常关键。
基于上面的思考我们团队进行了具体的实践，并取得了不错的效果。具体实践敬请关注后面的文章《代码检视实践——如何进行高效的代码检视？》。
