每当看到以前团队遗留系统中的乱糟糟的代码，就会有一种国骂的冲动。这算是什么软件开发人员？没有了解过基本的设计原则吗？没有学习过常见的设计模式吗？没有训练过基本的面向对象设计思想吗？不讲究封装，不讲究抽象，不讲究解耦，不讲究可复用性，一个大函数平铺直叙下来好几百行，什么逻辑都往里面塞，除了当时写的人外，谁能看的明白，谁能维护的了？

这也就不奇怪为什么后来的团队，总是倾向于把系统重写，而不是维护遗留系统了。因为重构的难度太大了，重构的代价相当于重新开发一套新的系统，为什么不把它重写呢？

一般来说，这样糟糕的系统大都是赶工赶出来的结果，常见于那些工期要求很紧的项目中。开发人员被项目工期追着跑，不管三七二十一，先把功能实现了再说，什么设计原则、设计模式、抽象和解耦，先不要跟我扯那个淡，没那个时间。

所以，代码写成这样，不完全是开发人员的责任，有项目成本的问题，有项目管理的问题，有项目周期的问题，有开发人员素质和经验的问题，多种因素叠加在一起，共同塑造出了一个糟糕透顶的烂系统。

这样的系统表面看起来运行正常、功能齐全，满足了当时客户的需求，项目完成后大家还开了一个庆功宴。只有开发人员自己明白，这个系统到底是怎么拼凑出来的！

使出了洪荒之力，终于把项目给应付过去了，那接着呢？噩梦才刚刚开始啊。还没有松口气，客户又提出了新的需求，接着改吧。项目经理觉得很奇怪，不就是改动一个小需求吗，你要做两周？不就是加一个模块吗，你要一个月？你是不是在磨洋工？！No！最多一周！好吧，那接着复制粘贴吧，重复的代码满天飞，再塞进去更多的业务逻辑，系统变得越来越复杂和不可维护。

当客户一次又一次提出新的需求时，开发人员已经准备跑路了，反正这坨屎一样的代码再跟我没关系了，谁能维护谁维护去吧，老子去也！

等系统变得不可维护，大家都束手无策，只能考虑重新开发时，上面的管理者往往把责任推给下面的开发人员，说他们不负责任，素质低下，技术糟糕，坑了我们坑了公司，却不反思是什么原因造成了这样的局面。为什么开发人员放弃自己的原则去胡乱拼凑代码？为什么明明需要三个月的开发量却压缩到一个月完成？为什么客户可以无休止地提出新的需求而不加以控制管理？开发人员是有责任，但他们的责任只是局部环节，不应该把整体的责任强加到他们身上。

无论如何，开发人员是有责任的。作为一个有责任的开发人员，要尽量把这种风险降低，而不是逆来顺受，管理者说什么就是什么，要有讨价还价的勇气和底气。要顶住压力，争取更多的时间去完善设计，尽可能地让代码符合设计之道，而不是破罐子破摔，反正已经这样了，随便造吧，造死拉倒！

作为直接参与过不少项目的开发人员，我是能够理解开发人员的处境的，也是能够理解开发人员这样写代码的动机的。有时候，为了图快，就顾不了那么多了！形势所迫，我难免也会这样做。但不同的是，每个开发人员针对重构的态度和技巧是各不相同的。我可以允许自己的代码在项目初期赶工期的时候设计差一些臃肿一些，但我不允许它们一直烂下去，我总会找机会把它们重构掉。

一个开发人员，应该把重构这件事当成吃饭睡觉一样平常自然，完全融入自己日常的工作中。这是一种态度，也是一种技能。一个团队能不能开发出好的产品，跟能不能重构、会不会重构有着莫大的关系。我告诉团队里面的开发人员，敏捷开发体现在方方面面，不只是看板才叫敏捷，不只是站立会议才叫敏捷，不只是用户故事才叫敏捷，不只是结对编程才叫敏捷，重构也叫敏捷，而且是敏捷很重要的一部分，我们应该大力提倡微重构。

什么是微重构？不要把重构想的那么高大上，非要斋戒沐浴才能开始重构？非要给你一个月空闲时间才能开始重构？非要学完了二十三种设计模式烂熟于胸了才能开始重构？重构随时都可以发起，花上十分钟就可以完成一次重构，在每天的开发任务中可以穿插进去很多轮的重构，为什么不可以呢？

把一个大函数分解成几个小函数，难道不叫重构？把一个胡乱命名的类名、函数名、变量名修改成一个自然达意的名称，难道不叫重构？把一个类按照单一职责原则重新做一下抽象，难道不叫重构？这样的重构能花费多长的时间？几分钟，十几分钟，或者半个小时。

每一次微重构，产品就往前优化了一小步，日积月累的微重构，产品就往前优化了一大步。不知不觉，我们的产品就旧貌换新颜，大为改观了。微重构的一小步，产品质量的一大步。

当然，重构不能是无源之水、无根之木，重构的思想和技巧不是无缘不顾就具备的，需要学习，需要实践，需要经历很多产品和项目的洗礼。

我有时候就有些自以为是，总是想责问年轻的开发人员为什么不按照这种设计思想去做开发，为什么不对这段代码进行一下重构，这难道不是很简单很明显的事情吗？但转念一想，才意识到自己犯了主观臆断的错误，有点把自己的思想和经历强加给他人了。我为什么是我，他又为什么是他？是什么塑造了我，又是什么塑造了他？我所看到的，不一定是他能够看到的；他所想的，也不一定是我能够理解的。一想到这点，我就稍微有点释然了，也就没那么愤懑了。每个人的修炼之路需要自己去完成。

关于设计和重构的书籍很多，每个人喜爱的也有所不同。我这里推荐几本作为参考吧：《重构：改善既有代码的设计》（Martin Flower）、《代码整洁之道》、《架构整洁之道》、《敏捷整洁之道》、《敏捷软件开发》。后面四本都是Robert C.Martin的书，他被业界尊称为Bob大叔，是我最喜爱的技术类作家之一，他的书引人入胜，思想深刻，值得一读再读。