大话重构连载9：大布局你伤不起

作为优秀开发人员，重构应当成为一种习惯，自然而然地运用重构的开发模式，自然而然地在优化和调整我们的代码。它首先要求我们掌握重构的开发模式，就是“小步快跑”的开发模式，运用“两顶帽子”的设计顺序，去开发我们的程序。但作为重构初学者来说，这并不容易，即使你已经从业很多年。

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

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

一个已经维护了很多年的大型软件项目，典型的遗留系统。经过多年的维护，代码已经凌乱不堪，开发人员已经换了很多茬，维护工作变得越来越困难。这时，甲乙双方经过仔细的沟通达成了一致，就是要对其进行一次大规模的改造。

毫无疑问，改造工作总是从会议开始的。经过许多轮会议，起初是跟客户谈，然后是闭门会议，项目经理、资深开发人员、系统架构师坐在一起，探讨的就一个事儿，系统改造的行动方案。这时，一位颇有经验的系统架构师说话了：“系统改造嘛我以前做过。我们首先应当对现有系统进行梳理，梳理它的业务功能。维护了那么多年，业务需求文档肯定不齐全。功能业务都没有梳理清楚，怎么改造呀？”说得还挺中肯。

“功能梳理清楚了，就开始梳理系统架构：怎么分层，怎么制定接口。这是一个非常细致的工作，分层一定要合理，要反复论证。然后，所有的接口都是梳理之后设计出来的，要形成设计文档。”

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

听了系统架构师的发言，大家一致觉得可行。再一想到他之前做过，有经验，项目经理就这样拍板了。随后就是持续数月的分析、整理、开发、测试，几十号人干得不亦乐乎。最后到了该结尾的时候了，和谐社会嘛应当是一个相当和谐的结局，系统改造成功，新系统顺利上线，甲乙双方十分满意。但非常遗憾的是，这个故事却没有得到那个和谐的结局。原系统经过多年的维护，发现并解决了许多问题，这些问题都体现在程序代码中非常细节的设计，但却为之后的分析设计师们所忽略。因此在新系统上线试运行时问题此起彼伏，新系统仿佛就是数年前那个旧系统的翻版。许多在旧系统曾经发现并早已修复的问题都在新系统中再次出现。当最终系统试运行结束时，我们花费了数月的辛苦劳动打了水漂，客户再也不提这个改造后的新系统了。

听了这个故事你作何感想呢？你有过类似的经历吗？正是有了那么多系统改造惨痛的教训，才使得那么多项目经理对系统重构讳莫如深。人总是喜欢学会遗忘，遗忘那些曾经刺痛过我们心灵的经历。忘了吧，不要再去触碰那根脆弱的神经。是的，你可以选择遗忘，但遗忘永远不可能让我们进步。勇敢者总是选择面对问题，正视问题，去分析，去总结，让错误永远不会再犯。所以，让我们正视问题，分析分析其错误的根源。这个根源就是持续数月后才得到的反馈。

分析整个项目的过程，我们惊奇地发现，从整理需求、设计接口、着手开发、测试，最后交付，在整整数月的时间，我们都无法知道，我们做得对还是不对。最后的结局因此就变成了一场dubo，要么成功，要么失败，各50%的几率，这就是问题的关键。什么是成功的项目管理？就是要将失败的几率降至最低，而这里我们没有做到。

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

假如时光可以倒转，当我们重新回到以往那个会议室重新规划那个系统改造方案时，我们应当怎样做呢？不要再去布那么大个局了，大布局你伤不起！不要去规划那个遥远而无法掌控的未来，它只会让你头昏脑胀。小设计可以让你获得成功。

大话重构连载首页： http://fangang.iteye.com/blog/2081995
特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！