作为优秀开发者，重构应当成为一种习惯，自然而然地运用重构的开发模式，自然而然地在优化和调整我们的代码。它首先要求我们掌握重构的开发模式。就是“小步快跑”的开发模式。运用“两顶帽子”的设计顺序，去开发我们的程序。

但作为重构刚開始学习的人来说，这并不easy，即使你已经从业非常多年。

所谓改变一种习惯，就好像习惯了左手吃饭的人，突然被要求改成右手，你必定会感到很多的不适。首先的不适是一种心理上的障碍，即怎样能迈出重构代码的第一步，这须要一种决心。初次尝试重构的开发者总是要经历一段非常长时间的纠结，纠结对既有的代码是隐忍还是重构。是的，走出重构的第一步并不easy，它对于你来说是一小步，但对于这个项目甚至这个机构来说却是一大步。

还有一种不适则是来源于一种思维的定式，是小设计还是大布局。来看看我以前经历过的一个故事吧：

一个已经维护了非常多年的大型软件项目，典型的遗留系统。

经过多年的维护。代码已经凌乱不堪，开发者已经换了非常多茬，维护工作变得越来越困难。这时，甲乙两方经过细致的沟通达成了一致。就是要对其进行一次大规模的改造。

毫无疑问。改造工作总是从会议開始的。

经过很多轮会议，起初是跟客户谈。然后是闭门会议。项目经理、资深开发者、系统架构师坐在一起。探讨的就一个事儿，系统改造的行动方案。这时。一位颇有经验的系统架构师说话了：“系统改造嘛我曾经做过。我们首先应当对现有系统进行梳理，梳理它的业务功能。维护了那么多年，业务需求文档肯定不齐全。

功能业务都没有梳理清楚。怎么改造呀？”说得还挺中肯。

“功能梳理清楚了，就開始梳理系统架构：怎么分层，怎么制定接口。这是一个很仔细的工作，分层一定要合理，要重复论证。

然后，全部的接口都是梳理之后设计出来的，要形成设计文档。

”

“制定这个设计文档很重要，没有设计文档怎么开发呀？设计错了谁来负责呀？岂不是会乱成一锅粥了。所以设计文档也应当论证，重复论证。最后才開始开发、測试、交付。整个项目搞下来怎么也得好几个月吧。”

听了系统架构师的发言。大家一致认为可行。再一想到他之前做过，有经验，项目经理就这样拍板了。随后就是持续数月的分析、整理、开发、測试，几十号人干得不亦乐乎。最后到了该结尾的时候了，和谐社会嘛应当是一个相当和谐的结局，系统改造成功。新系统顺利上线，甲乙两方十分惬意。但很遗憾的是，这个故事却没有得到那个和谐的结局。原系统经过多年的维护。发现并攻克了很多问题，这些问题都体如今程序代码中很细节的设计，但却为之后的分析设计师们所忽略。因此在新系统上线试执行时问题此起彼伏，新系统仿佛就是数年前那个旧系统的翻版。很多在旧系统以前发现并早已修复的问题都在新系统中再次出现。

当终于系统试执行结束时，我们花费了数月的辛苦劳动打了水漂，客户再也不提这个改造后的新系统了。

听了这个故事你作何感想呢？你有过类似的经历吗？正是有了那么多系统改造慘痛的教训，才使得那么多项目经理对系统重构讳莫如深。

人总是喜欢学会遗忘，遗忘那些以前刺痛过我们心灵的经历。忘了吧，不要再去触碰那根脆弱的神经。

是的，你能够选择遗忘。但遗忘永远不可能让我们进步。勇敢者总是选择面对问题。正视问题。去分析，去总结，让错误永远不会再犯。

所以。让我们正视问题，分析分析其错误的根源。这个根源就是持续数月后才得到的反馈。

分析整个项目的过程，我们惊奇地发现，从整理需求、设计接口、着手开发、測试，最后交付，在整整数月的时间，我们都无法知道，我们做得对还是不正确。

最后的结局因此就变成了一场dubo。要么成功。要么失败，各50%的几率，这就是问题的关键。什么是成功的项目管理？就是要将失败的几率降至最低，而这里我们没有做到。

如何才干将失败的几率降至最低呢？假设我们每工作一个月就能够知道这个月的工作对不正确，则错误给我们的损失就是一个月；假设我们一周一检查，错误的损失就是一周；假设是一天，损失的就是一天。数小时。损失的就是数小时。总之，错误发现得越早。我们的损失也就越小。

假如时光能够倒转，当我们又一次回到以往那个会议室又一次规划那个系统改造方案时，我们应当如何做呢？不要再去布那么大个局了。大布局你伤不起！不要去规划那个遥远而无法掌控的未来，它仅仅会让你头昏脑胀。

小设计能够让你获得成功。

大话重构连载首页：

特别说明：希望网友们在转载本文时。应当注明作者或出处。以示对作者的尊重，谢谢。