我们所不知道的Code Review
也许是待得太久，就像被一桶草莓酱从头浇到脚，尝哪里都是甜味一样，当初次看到Code Review成为一个如此重型并且低效的活动的时候，我才知道，草莓酱的外面，是空气，裹着大地的气息，大部分无味，又或者是烟草味，或者汽车的尾气。
先看一看我们看到的一个代码审查过程：
- 开发人员领到任务。
- 一周之后，代码写完了。他觉得没底，需要找业务专家技术专家来评审一下。这个时候他代码还没有提交。于是他把本地所有没有提交的、修改过后的文件，放到一起，压缩成rar包。找到他认为的技术高手业务高手（们），定会议室，发邮件通知。2小时过去了。
- 技术专家业务专家收到了邮件，由于缺乏上下文理解，以及长达数千行的源代码，这类邮件一般不看——因为看了也是白看。
- 终于到了Code Review的那一天。七七八八的来了几个人。一般来不全。因为高手之所以是高手，表现之一就是超级忙。
- 于是代码的作者开始，一行一行的将代码讲下去。前几十分钟高手们也没办法理解——毕竟是一个星期的工作沉淀，哪有那么快理解的。大约30分钟之后，专家开始提出建议意见。这些意见一般涵盖了语法、编码规范、可能的业务错误、模块间关系等。专家们毕竟是专家。2个小时之后，专家们离去。
- 开发人员虚心的把这些意见、建议写到小本子上。
- 开发人员可能根据专家的建议进行相应的代码修改并且提交，也可能不；可能改对了，也可能不。评审过后，后续的实施成为黑洞……
没了。
先思考一下，这个过程中的问题。
======== 思考的分割线 ========
首先必须承认Code Review的价值。经验丰富的专家们在做代码审查的时候，能够根据以往经验，规避重大缺陷的发生，对开发人员给予有价值的指导。然而，这个过程，太冗长，太低效。
- Code Review必须基于事实。这里的事实，就是，源代码库。SVN Repository, 或者HG/Git Repository. 在多人协作环境中，对于一份不在源代码库代码是基本不可信的 —— 你无法预知，他是否将会成为最终可工作软件的一部分。
- 积攒下来众多的代码修改，使得产生重型、低效的沟通方式成为必然。这类众型的沟通方式往往成本惊人 – 需要占用最好的人很长时间。
- 过分夸大专家的作用。根据以往经验，许多最终发现问题，回溯上来，其实是一些简单的逻辑问题。这些问题如果分散在平时结对或者更频繁的过程中，则更容易发现。很多情况下，是开发人员对常见的bad smell了解和修炼不足，而这些bad smell常常是导致问题的地方。例如在一个已经有3重循环的方法中加入了新的判断而没有测试；修改了函数的返回值而没有任何说明；if 判断中包含了多达4-5个变量的比较判断而没有抽象为一个更具业务含义的方法，等等。
- Review手段的原始落后。Review必须基于变化。会看报表的人都知道，看报表只需要看两个东西：趋势和拐点。Code Review也一样，只需要看变化。SVN/Hg/Git这类现代化的工具给我们提供了丰富的，基于changeset的compare工具。查看一天，整个团队的check in情况，顶多只需要10分钟-15分钟。
在敏捷过程中，Code Review几乎是一个被忽视的环节——不是不做，而是时时在做。结对时，我们会对结对伙伴的编码习惯、新写的类、变量表示质疑；提交之后，有代码静态检查工具、单元测试工具、覆盖率工具帮助我们检查有没有犯简单愚蠢的错误、有没有破坏既有功能；持续集成服务器则中立、不知疲倦的在每次我们提交之后运行所有的过程。
Code Review不是一个审查环节。不是一个考核环节。它是交流和反馈环节。
闲话：关于敏捷
(10:09:50 PM) Stephen H. Wang: 好像很久没看到你上网了。:)
(10:10:52 PM) Michael: 最近白天都不用电脑
(10:10:58 PM) Michael: 工作原因
(10:11:06 PM) Stephen H. Wang: 哦，不用电脑？太神气了。
(10:11:11 PM) Stephen H. Wang: 神奇
(10:11:22 PM) Stephen H. Wang: IT业居然不用电脑*-)
(10:11:45 PM) Michael: 做咨询了…主要靠说话
(10:11:59 PM) Stephen H. Wang: 我们领导明天准备给我们安排一个讲座：Refactoring – Martin Fowler的书。
(10:12:04 PM) Michael: 哦
(10:12:08 PM) Stephen H. Wang: 哦~~~~原来如此，好工作！
(10:12:12 PM) Michael: 谁来讲
(10:12:17 PM) Stephen H. Wang: 内部安排的。
(10:12:28 PM) [...]
文化的风化与侵蚀
常常听说，一个团队的文化就是团队负责人的文化; 一个公司的文化就是公司领导人的文化。究其原因，就是因为领导人的喜好和评判标准极大的影响着团队成员的荣誉感与价值观。这些观念和标准是在长期的工作和合作工程中不断碰撞不断沉淀下来最终得到的一个利益博弈的结果，表现出来的形式就是形式各异的企业文化，或者公司文化。
企业文化具备强大的同化能力。它是超越规章制度之外的一个做事方式、价值观的基本指导。许多公司的新员工培训采取的各种各样的方式，无不是想尽快让新员工适应这个公司这个大团体，与其他成员一起，向同一个方向使力。在《额尔古纳河右岸》中，年迈老人采用眩晕、饥饿、清洗肠胃等方法来训练原本桀骜不驯的老鹰称为帮手的过程，与这种文化上的趋同手段并无本质不同。
当在一个环境中已经具备一些文化认同的人，到了另外一个环境，有哪些行为会使得原本坚信的东西觉得恍惚？哪些事情会导致原本坚定的信仰开始动摇？哪些则会干脆彻底的重建原有的行事方式？
首先是寂寞。在东西方的神话中这类的例子屡试不爽。比如西游记里面各式各样的妖怪，大多是寂寞的发疯，逐渐忘记了规矩，成精之后下凡找点乐子。甚至是魔兽世界中众神的代表，泰坦萨格拉斯，在长达数万年的孤身与恶魔斗争中的，逐渐丧失了对正义的信仰，结果导向了恶魔的一方，称为整个世界的敌人。电影《无间道》中的卧底，长时间在正义与邪恶之间游走，最终也恍惚的分不清正义与邪恶。将一个人或者一个团队扔到孤立的地步是使其受到侵蚀的最简单的方式。有些人意志坚定，能撑较长的时间，有些人意志薄弱或者干脆正处于文化成型期，此时的寂寞很有可能直接导致文化上的风化、孤立与重塑。
随之而来的是诱惑。西方的哲学体系里面，人是有原罪的——例如贪婪、背叛。当有足够多的诱惑来临的时候，诱惑带来的好处、守护带来的艰辛，使得人的原罪发挥作用，原本坚信的东西开始逐渐动摇。
在实际的工作中，这些首先能看到的好处就是荣耀的来源。例如，在公司里面，人人崇尚敏捷，尊重事实，注重实效。做到这些能够得到同事、领导的赞赏。而当进行长期咨询工作的时候，发现客户对面面俱到的计划、华丽的图表等表面的东西更加赞赏。长期下去，工作的中心出现偏移，获得认可与赞赏的诱惑使得行事方式发生变化，长期下去，当这些行事方式成为思维习惯，带来的文化的变迁使得返回到原来的工作岗位时觉得陌生。
与荣耀相对的是惩罚。我们都是在正确与错误的事情中不断获得反馈和成长。一旦得到某些惩罚，很有可能对心灵造成很长时间的创伤，并且在长时间内处于敏感戒备状态，无论是新的环境还是旧的环境，都处于不信任状态。例如，派一个来公司不久的人，接受了公司文化培训，去处理客户现场问题，结果被客户大骂一顿。这位新员工可能在很长时间内萎靡不振，并且对公司和客户处于非常不信任的心理状态。
趋同心理则是最后一个效果最缓慢的因素，它的表现最快但是影响最慢。每当我们到一个新环境我们总想表现的跟当地的人一样，以获得最大程度的认同——起码从外表上——那些妖精都知道变成人形呢——如果客户西装领带，我们也不好短袖T恤；如果客户习惯在每个周五举办酒会，我们也乐于参与，等等。这些都是外观上的，但长时间的趋同很容易让人从外观上和内心上逐渐妥协并转换——就像中药，虽然见效慢，但终究是见效的，而且有可能是最能根治的。
< 请谨慎理解这篇文章——我没有在这片文章中给出任何防御性或者建设性的建议，甚至你都有可能无法看出我的立场。文化的变迁很大程度上是主观的，根据原因不同，我所经历过的文化沙漠的形成大多数组织领导在既得利益与文化建设之间的平衡不足造成。>