为何引入Code diff？
2011年1月26日
13:52
?
? 2510年。考古队挖出一块硬盘，记录这2010年R公司的代码。他们从redgate公司的档案柜内找到 reflector反向出来了这些源代码，发现古人已经在编码方面注意标准化并且使用工具自动化这个过程。大家惊呼，哇咦，古人已经很聪明了。
?
我们的重构流程推行了两年。经过一段时间对重构流程的梳理、慢慢的建立和抛弃一系列的思想，然后不断的简化、淬炼、抽象，逐步的形成到具体的实践方法。本文就是我的简要的思考过程。我希望以此帮助大家了解我们在高质量编码方面的价值观，从而更好的实践新的流程。
?
重构是有效果的。我从这个过程中得到几点看法：
<!--[if !supportLists]-->4.??????<!--[endif]-->尽可能采用自动化
?
流程就是这样，通过流程让大家更加开放的进行高质量编码。这是一个基础，一个管理服务。但是仅仅有了流程还是不够的。大家唯有理解了我们的价值观，才能让大家得到更多的益处；否则必然是简单的亦步亦趋、有样学样。这是我不想看到的。
?
克服一个拖后腿的“轻浮”想法。有人认为：“指出代码的问题是很容易的事情，人人都可以做到看到别人代码的问题”。这样的观点在我看来是非常轻浮的。重构仅仅在《重构》一书内就有上百的方法，大的原则是消除重复和容易，职责分离等等，小的步骤就非常的多了，遇到一个具体问题，运用这么多的方法，首要是投入和学习、实践，其次是灵活组合多种方法，小步的、安全的达到重构的效果。这些年来，国外的敏捷咨询机构进入中国的越来越多，比如Thoughtworks，Odd-e，也有越来越多的公司采用了敏捷，比如ActiveNetwork，华为。而敏捷的一个核心实践就是重构，是咨询公司的主要收入源。而从我接触的一家咨询公司的评价上看，他们的很多客户做的并不好。可见，把重构视为比较简单的事情是过于轻浮的看法。感觉到是一回事，瓜分豆析的执行是另一回事。以前就常常有人说，“你看这个代码真的太…”,然而让他找出方法，他总是说，“这简直不可能，要考虑稳定，考虑进度...”。切。千人诺诺，不如一士谔谔。拿出妥善的、成套路的方法，并且一以贯之，才是这个王道。
?
观察高效程序员的做法，逐步厌弃低质量代码。我发现越是编码质量高的程序员，越是自然的排斥不良的编码。和他们的交流代码，常常发现他们会很愤恨的嘟嘟囔囔：“你看嘛，干嘛啰嗦，换个方法多简洁；这里的写法根本没有必要；还有这里，命名和大小写都成问题”。因为厌弃，才会逼着自己写出优秀的代码来，逐步养成新的习惯，“下笔如有神”，自然的写出漂亮的编码来。而整个团队的所有人都应该向这个信仰高质量代码的程序员一样，信仰高质量代码的对产品和团队的价值，相信自己在今天的投入会在未来得到回报。回报可能包括产品的稳定性、可维护性，个人水平的提升，产品的竞争力提升，balabala。
?
程序员的心理过程需要关注。很多程序员在遇到其他人编写的编码时，也会有“做好我自己就行“的鸵鸟思想。看到不好的代码，常常不好意思直接的指出来——怕伤了面子，也怕被拒绝。理解我们的价值观，就是为了释放程序员的能力，让大家可以自由的、不怕争论的提出自己的做法、精炼自己的实践。
?
从源头狙击。以往的做法都是编码后检查，然后提出修改。存在更好的工具来帮助code reviewer从程序员一开始编码就强制规范。如TFS可以在提交代码前自动检查Naming规范，复杂度。再比如TeamCity可以查找重复代码。Reviewer可以不必花费太多时间查验基本代码规范，做更有价值的架构分析和重构。程序员可以清晰的看到规范的存在，如同编译错误一样很容易定位这一类问题。
?
代码像水一样，但是你无法保证你就是下游或者上游——他们是相关的，任何人不能保证今天某人写的代码，不会明天流到你这里来，而你也不能保证你的代码某天不会流到某人那里。所以，建立一个开放坦诚的环境是必须的。建立一个高质量的价值观，并通过CodeDiff 分解到每一天是必要的。
?
?
详细的做法，请看? Code Diff. ，我们做了。
?
广告：最后，推荐大家上新浪微博@1000copy，这是我的微博。
暗号是：让Code 能够Diff，让Tech也可以Diff。让大家技术成长也分解到每一天的闲言碎语上：）。
