代码重构的真正意义

         代码重构，什么时候开始呢？当我们被自己写的Code逼上梁山的时候。

        美国心理学家曾提出过一个”破窗理论“。认为：如果有人打坏了一幢建筑物的窗户玻璃，而这扇窗户又得不到及时的维修，别人就可能受到某些示范性的纵容去打烂更多的窗户。久而久之，这些破窗户就给人造成一种无序的感觉，结果在这种公众麻木不仁的氛围中，犯罪就会滋生、猖獗。 敲代码，何尝不是如此，正如一扇破窗，一句乱代码让我们付出的代价是去写更多的乱代码来维持其正常运行。直到，我们被淹没在无穷无尽的代码黑洞中，找不到出口，更找不到入口。最终，到了千钧一发、大厦将倾的时候，我们终于意识到是时候重构代码了。

       重构代码，无异于重写一套程序。个人认为，重构后的代码应该至少具备这三个特征，最易于维护、更大程度扩展、最少限度冗余。

       首先，什么是"更易于维护"呢?  真实开场景中，我们会不断接到客户需求，导致我们不得由于这种或那种原因去修改某段代码（可能并不产于自己），可怕的事情是，当我们发现这段代码竟然在多处有同样副本时，我们则需要同时维护这些Copy Code，这样的代码会极大的增加维护成本。真正的良码，应该最大程度引用、最小限度依赖。总体看来，代码主体其实分两块，业务无关代码和业务相关代码，对于业务无关代码，我们最好做到全部公用（包括公共组件、工具类等等），而对于业务相关代码，则力求做到最大限度公用，同时减少不必要的依赖（不能为了省代码而省代码）。这样，重构后的代码，是比较易于维护的。

    再者，如何实现”更大程度扩展“呢？ 个人认为，代码需要具备多大的扩展性，主要取决于业务场景的多样性，无需作无意义的扩展。怎样增强扩展性呢，应该从代码结构着手，这就如同建筑工地上的脚手架，正常情况只会有100人的承重，我们就不能仅以100人的承重量来设计脚手架，否则稍加两人，脚手架就轰然崩塌了。所以，尽量避免”Dead Code(无法修改或者修改代价极大的代码）“，是我们理所当然应该具备的素质。重构的时候，时刻注意预留分支、预留接口，就显得尤为必要了。

    最后，怎样达到”最少限度冗余“呢？ 这就要求我们有一定的代码洁癖，同一份代码在程序中出现了三次以上，就该检讨了。 人生有两只眼睛很正常，长三只眼睛就显得太冗余了（除非另一只眼长在后脑勺）。 当然，不必为了冗余而冗余，抽取代码时，尽量考虑逻辑相关性，最好符合上下文语境。重构代码的最终目的，不只是让代码更少的冗余，更多的是减少逻辑和语义上的重复。

  （以上只是一家之言，只是介绍重构的基本思路，并未写代码示例，更多代码重构思路，推荐大家学习Robert C.Martin的《代码整洁之道》。）