从烂代码到重构

我们在做任何系统的时候，都不要指望系统一开始时需求确定，就再也不会变化，这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化时，设计软件的可以相对容易修改，不至于说，新需求一来，就要把整个程序推倒重来。

够用的代码

曾经一个同事跟我吐槽过，队友工作四五年了，代码质量依然不咋样，命名不规范，逻辑嘛，除了自己外，谁也看不懂，注释更是凤毛麟角，但是这样的代码却能正常运行着，每次出bug，都能迅速定位，每个变量和方法，不看代码都能说出来，并且bug还不高，很神奇。

是否真的要重构/h2>

不可否认，从维护成本上看，重构确实是一个很不错的方案，重构的成本比原基础维护的成本更小，也更方便以后的维护。有些公司甚至在多次版本迭代后，直接把整个项目推到重构，这样的事情不仅仅发生在小公司，在一些大公司，也是会发生多次。

从技术上来说，重构复杂代码时要做三件事：理解旧代码、分解旧代码、构建新代码。而待重构的旧代码往往难以理解，尤其是在多次迭代且多人经手的模块；模块之间过度耦合导致牵一发而动全身，不易控制影响范围；旧代码不易测试导致无法保证新代码的正确性，尤其是在产品文档不全的时候。这三个操作，每个操作都是很难的。对于重构，不一定要用到某些设计模式才显得合理，在文档健全的情况下，你可以先画图，把一个大的模块拆分拆解，面向这些拆解后的功能模块编程，看起来会更好一点。

但对于一些人来说，重构并不是一个好的方式，只会浪费更多的时间，花了大量时间，辛辛苦苦重构的代码，却在很不轻易间，又回到了原来的难以维护的状态。比如，有些人写代码写成一种习惯了，就像一个人生活的房间，本来就是脏乱差的那种（烂代码），请了保洁阿姨打扫后（重构），生活了一段时间后，臭袜子不分东西，烟头不分南北，各种零食袋遍地都是，再次回到了脏乱差的时代，只有平时生活中养成一个好的习惯，抛弃一些不好的习性，才能写出更优质的代码。

建议：重构，并不是万能的，重构后的代码，当再次经历后续几个版本修改后，代码又显的杂乱无章，那一坨坨代码总是在不断的重演。既然无法确定需求日后是否会修改，那我们只能通过提高代码质量来应对，以不变应万变，合理设计接口，每次更改需求时多思考，对于多次使用的代码进行封装提取，尽可能少的改动既有的逻辑。