作为优秀开发人员,重构应当成为一种习惯,自然而然地运用重构的开发模式,自然而然地在优化和调整我们的代码。它首先要求我们掌握重构的开发模式,就是“小步快跑”的开发模式,运用“两顶帽子”的设计顺序,去开发我们的程序。但作为重构初学者来说,这并不容易,即使你已经从业很多年。
所谓改变一种习惯,就好像习惯了左手吃饭的人,突然被要求改成右手,你必然会感到许多的不适。首先的不适是一种心理上的障碍,即如何能迈出重构代码的第一步,这需要一种决心。初次尝试重构的开发人员总是要经历一段很长时间的纠结,纠结对既有的代码是隐忍还是重构。是的,走出重构的第一步并不容易,它对于你来说是一小步,但对于这个项目甚至这个机构来说却是一大步。
另一种不适则是来源于一种思维的定式,是小设计还是大布局。来看看我曾经经历过的一个故事吧:
一个已经维护了很多年的大型软件项目,典型的遗留系统。经过多年的维护,代码已经凌乱不堪,开发人员已经换了很多茬,维护工作变得越来越困难。这时,甲乙双方经过仔细的沟通达成了一致,就是要对其进行一次大规模的改造。
毫无疑问,改造工作总是从会议开始的。经过许多轮会议,起初是跟客户谈,然后是闭门会议,项目经理、资深开发人员、系统架构师坐在一起,探讨的就一个事儿,系统改造的行动方案。这时,一位颇有经验的系统架构师说话了:“系统改造嘛我以前做过。我们首先应当对现有系统进行梳理,梳理它的业务功能。维护了那么多年,业务需求文档肯定不齐全。功能业务都没有梳理清楚,怎么改造呀?”说得还挺中肯。
“功能梳理清楚了,就开始梳理系统架构:怎么分层,怎么制定接口。这是一个非常细致的工作,分层一定要合理,要反复论证。然后,所有的接口都是梳理之后设计出来的,要形成设计文档。”
“制定这个设计文档非常重要,没有设计文档怎么开发呀?设计错了谁来负责呀?岂不是会乱成一锅粥了。所以设计文档也应当论证,反复论证,最后才开始开发、测试、交付。整个项目搞下来怎么也得好几个月吧。”
听了系统架构师的发言,大家一致觉得可行。再一想到他之前做过,有经验,项目经理就这样拍板了。随后就是持续数月的分析、整理、开发、测试,几十号人干得不亦乐乎。最后到了该结尾的时候了,和谐社会嘛应当是一个相当和谐的结局,系统改造成功,新系统顺利上线,甲乙双方十分满意。但非常遗憾的是,这个故事却没有得到那个和谐的结局。原系统经过多年的维护,发现并解决了许多问题,这些问题都体现在程序代码中非常细节的设计,但却为之后的分析设计师们所忽略。因此在新系统上线试运行时问题此起彼伏,新系统仿佛就是数年前那个旧系统的翻版。许多在旧系统曾经发现并早已修复的问题都在新系统中再次出现。当最终系统试运行结束时,我们花费了数月的辛苦劳动打了水漂,客户再也不提这个改造后的新系统了。
听了这个故事你作何感想呢?你有过类似的经历吗?正是有了那么多系统改造惨痛的教训,才使得那么多项目经理对系统重构讳莫如深。人总是喜欢学会遗忘,遗忘那些曾经刺痛过我们心灵的经历。忘了吧,不要再去触碰那根脆弱的神经。是的,你可以选择遗忘,但遗忘永远不可能让我们进步。勇敢者总是选择面对问题,正视问题,去分析,去总结,让错误永远不会再犯。所以,让我们正视问题,分析分析其错误的根源。这个根源就是持续数月后才得到的反馈。
分析整个项目的过程,我们惊奇地发现,从整理需求、设计接口、着手开发、测试,最后交付,在整整数月的时间,我们都无法知道,我们做得对还是不对。最后的结局因此就变成了一场dubo,要么成功,要么失败,各50%的几率,这就是问题的关键。什么是成功的项目管理?就是要将失败的几率降至最低,而这里我们没有做到。
怎样才能将失败的几率降至最低呢?如果我们每工作一个月就可以知道这个月的工作对不对,则错误给我们的损失就是一个月;如果我们一周一检查,错误的损失就是一周;如果是一天,损失的就是一天;数小时,损失的就是数小时。总之,错误发现得越早,我们的损失也就越小。
假如时光可以倒转,当我们重新回到以往那个会议室重新规划那个系统改造方案时,我们应当怎样做呢?不要再去布那么大个局了,大布局你伤不起!不要去规划那个遥远而无法掌控的未来,它只会让你头昏脑胀。小设计可以让你获得成功。
大话重构连载首页:http://blog.csdn.net/mooodo/article/details/32083021
特别说明:希望网友们在转载本文时,应当注明作者或出处,以示对作者的尊重,谢谢!