从烂代码到重构

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

够用的代码

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

是的，这个问题现在社会中还真很常见，命名混乱，不加注释，这是目前很普遍的现象。我也遇到一些朋友，有的甚至写了快十年的代码了，依然写的一坨一坨的，看了都难受，还有一部分完全是看不懂的命名和逻辑，但bug率却很低，对于这样的代码应该怎么定义队友写的蠢玩意真不能这样定义，如果这个工程自始至终只有一个人维护，那个人也维护的很好，那它似乎就成了够用的代码。当然，这样的代码肯定算不上好代码，如果作者离职了，那功能模块只能选择重构了，维护的成本是显而易见的。反而言之，写的再优雅，代码跟诗一样，但bug满屏幕都是，也是烂代码，就好像一篇好文章到处错别字一样，看的也头疼。

是否真的要重构/h2>

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

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

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

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

来源：下一个丶奇迹