破窗理论 防微杜渐

    代码质量可以反映出创建代码的过程与开发团队的修养。如果没有正确的态度和各方面的支持——包括技术、管理、社会——代码库可能就会慢慢衰退。延迟这种衰退的办法首先是要不断地处理各种小问题，以避免引发更大的问题。如果大问题是从中等问题中产生，而中等问题又是由小问题产生，那么我们可以从源代码上就杜绝问题的出现。这种保证代码质量的方法在《编程实战丛书》（Pragmatic Programmers）中被大力推广，并被称为“不要忍耐破窗户”（一幢建筑中如果开始有破窗户，就代表将有越来越多破窗户的倾向，即意指防微杜渐）。

    根据破窗理论进行的重构是一种有着战略意义的技术。重构并不只是对“改编代码”换了一种说法，虽然确实有些开发人员降低了它的价值并以这种含义来使用它。Martin Fowler为重构提供了以下更准确的、字典式的定义：

    重构（名词）：在不改变软件的可见行为方式的情况下，为使软件结构更容易理解、更方便修改而对软件的内部结构做的改动。

    重构（动词）：在不改变软件的可见行为方式的情况下，通过对软件进行一系列的重构来改变软件结构。

    为使这个定义不致过于广泛，需要说明其中提到的“可见行为”指的是功能方面，而不是操作方面。功能行为包含代码运行时的交互与最后产生的结果，而操作行为是指代码运行的特性，如性能、内存使用等。一次重构可能会影响到操作行为，但不能影响到功能行为。
 
修补破窗 关注代码质量

    与破窗理论形成对照的则是那句常被误用的老生常谈：“亡羊补牢，未为晚也”。理论上这句俗语听起来好像很正确，但实际上却是自欺欺人的借口。在这里，“破”到底指的是什么呢？“补”又涉及到哪些或者不涉及哪些呢？

    在破窗户的比喻中，“破”是指环境质量方面的问题。但是，在说“亡羊补牢”时，“破”就局限为一种功能行为了。换句话说，如果羊圈没有破洞，就不需要修补啦？如果代码没有错误，也不需要修改啦？很可能羊圈早就已经松动，轻轻一碰即可出现问题。而“修补”又包含哪些内容呢？如果已知代码有问题并且是许多缺陷的共同根源，那么通过一个接一个地修补代码错误根本不能解决本质问题，因为这已不是技术问题，而是组织问题了。非要等到问题彻底暴露才进行修补的这种狭隘态度，带来的是大量不协调的局部修补，这不仅不能解决问题，甚至还会使问题恶化。

    那么对于代码的其它改动呢？那些杂乱的代码，包括大量的重复代码、大量多余的注释掉的代码、冗长的编写逻辑、数不清的特殊用例等，都是在改动的时候占用时间、资源的无底洞。如果这种代码正在运行，虽然可以认为其实现了所需的功能，也极可能是正处于一种脆弱的状态，一种不稳定的平衡，一个不起眼的改动可能就将其彻底破坏。从某种意义上说，这种代码已经坏掉，改动只是起到将其破损之处暴露出来的作用而已。
 
    如果我们采用谨慎行事的保守主义做法，认为“事不关已，高高挂起”，那么很有可能造成“亡羊补牢，为时晚矣”。这样不做出任何改动的维持，也意味着要放弃新功能。

    没有任何的重构选项可以通过简单地点击来修正大量拙劣代码的质量问题，以把它们从最差代码转化成优质文化遗产。要跳出这个坑来，首先要停止继续往下挖坑。

    如果你希望能够随时做出非常好的决定，避免遇到需要解决这些难题的情况，那么很明显结论只有一个，那就是从一开始就关注代码质量，避免出现问题。这也是本文最后的教训。当然，你可以直到遇到交通堵塞的时候再考虑另一条路，但这时候就太晚了——你所有的精力都已经放到如何逃离这片堵车区上面。因此，你最好从一开始就一边小心驾驶，一边注意收听关于前方路线状况的报道。