很早之前听说过这样一个故事：

一个漂亮的女子与马戏团的小丑坠入爱河，并迅速结婚。小丑十分珍惜得来的幸福，努力挣钱，瞒着女子做了整容手术，为了给女子惊喜。整容后的小丑出现在女子眼前时，女子提出离婚，因为他喜欢的是原来长的并不帅的小丑。

一个项目重构的动机(目的)无外乎两种：1. 给用户带来更好的体验、2. 项目代码失控（难以维护、添加新特性）。重构必然导致变化，用户接受现在的产品，重构后的版本并不一定喜欢。至于极端，哪怕重构后的版本比老版本好的多，也会有用户高声喊：给我老版本。这和小丑的故事一样了，哪怕整容帅的像郭德纲一样，女子照样甩一甩衣袖走了。

现实生活中的重构往往是程序员自己发起的，Martin Fowler都有一本书起名为《重构》，并被许多程序员奉为圭臬。程序员的初衷是好的，但往往会低估重构的难度，项目越大耦合越多，往往牵一发而动全身，当老板跑过来问你进度时，你只能回以尴尬的笑，因为进度会进入无法掌控的地步。最近自己差点陷入这种进退维谷的境地，还好项目比较小，最后算是挺了过来。

但大的项目移筋动骨的重构就真的很难成功了。记得在核新软件的时候，项目庞大臃肿，添加新功能困难，软件的开发与执行效率都很低。记得一段时间内，大家重构的呼声很高，不过最后不了了之，因为工程浩大、重构后的兼容性、重构后软件多长时间可以稳定、重构后版本的测试等等需要考虑的各种问题已不单单是几个开发可以掌控的了的。而同时产品的需求还是不会减少，因为产品根本不关心软件的技术架构、可靠性、可维护性等等。

产品不关心重构是正常的。确实，一个可以正常运行，用户没有太多投诉、谨慎的编码也不会出太大问题的项目为什么要重构呢？假如某地发现了一个煤矿，第一批人来开采，一年时间采掉了50%的煤; 第二批人来了，煤已不那么好采，必须小心谨慎的对待，因为矿难不断，不过还好花了两年时间采到了30%的煤; 第三批人来了，矿上留下的全是前人留下的坑，无处落脚，须将前面的坑填掉，才能保证采得到煤，先花费了三年填坑，最后又花了一年时间采到了10%的煤。软件开发也一样，软件的生命期有限，是否需要花费人力将软件重构的完美值得商榷，可能重构完成之日，为项目终结之时，留下完美的架构与设计又有何用呢？

既然程序员呼吁重构的理由是，项目代码难以维护，那为什么不从一开始写出易维护的代码？