我们在做任何系统的时候，都不要指望系统一开始时需求确定，就再也不会变化，这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化时，设计软件的可以相对容易修改，不至于说，新需求一来，就要把整个程序推倒重来。
够用的代码
曾经一个同事跟我吐槽过，队友工作四五年了，代码质量依然不咋样，命名不规范，逻辑嘛，除了自己外，谁也看不懂，注释更是凤毛麟角，但是这样的代码却能正常运行着，每次出bug，都能迅速定位，每个变量和方法，不看代码都能说出来，并且bug还不高，很神奇。
是的，这个问题现在社会中还真很常见，命名混乱，不加注释，这是目前很普遍的现象。我也遇到一些朋友，有的甚至写了快十年的代码了，依然写的一坨一坨的，看了都难受，还有一部分完全是看不懂的命名和逻辑，但bug率却很低，对于这样的代码应该怎么定义？猪队友写的蠢玩意？还真不能这样定义，如果这个工程自始至终只有一个人维护，那个人也维护的很好，那它似乎就成了够用的代码。当然，这样的代码肯定算不上好代码，如果作者离职了，那功能模块只能选择重构了，维护的成本是显而易见的。反而言之，写的再优雅，代码跟诗一样，但bug满屏幕都是，也是烂代码，就好像一篇好文章到处错别字一样，看的也头疼。
烂代码的主要由来
相信很多朋友都遇到过，原本一个很普通的需求，在经历过N次迭代和修改后，bug的不断修复，再加上大量冗余的代码，已经形成一个庞大的模块，随着版本的不断迭代，维护起来的成本也随着越来越大，再过上一段时间，有个相似的需求，想要复用里面的逻辑，这时才意识到代码里做了各种特定场景的专用逻辑，可复用性和灵活性太差，为了赶进度只好拷代码然后改一改。问题解决的同时，问题也加倍了，这样就形成了一种恶性循环，够用代码渐渐也会为了一个重大的负担，维护，越来越觉得力不从心。
绝大部分的烂代码都是由够用的代码演化而来，当自己还能快速维护的时候，这就是够用的代码，但作者离职或者作者也越来越难维护的时候，就形成了烂代码。
是否真的要重构？
不可否认，从维护成本上看，重构确实是一个很不错的方案，重构的成本比原基础维护的成本更小，也更方便以后的维护。有些公司甚至在多次版本迭代后，直接把整个项目推到重构，这样的事情不仅仅发生在小公司，在一些大公司，也是会发生多次。
从技术上来说，重构复杂代码时要做三件事：理解旧代码、分解旧代码、构建新代码。而待重构的旧代码往往难以理解，尤其是在多次迭代且多人经手的模块；模块之间过度耦合导致牵一发而动全身，不易控制影响范围；旧代码不易测试导致无法保证新代码的正确性，尤其是在产品文档不全的时候。这三个操作，每个操作都是很难的。对于重构，不一定要用到某些设计模式才显得合理，在文档健全的情况下，你可以先画图，把一个大的模块拆分拆解，面向这些拆解后的功能模块编程，看起来会更好一点。
但对于一些人来说，重构并不是一个好的方式，只会浪费更多的时间，花了大量时间，辛辛苦苦重构的代码，却在很不轻易间，又回到了原来的难以维护的状态。比如，有些人写代码写成一种习惯了，就像一个人生活的房间，本来就是脏乱差的那种（烂代码），请了保洁阿姨打扫后（重构），生活了一段时间后，臭袜子不分东西，烟头不分南北，各种零食袋遍地都是，再次回到了脏乱差的时代，只有平时生活中养成一个好的习惯，抛弃一些不好的习性，才能写出更优质的代码。
建议：重构，并不是万能的，重构后的代码，当再次经历后续几个版本修改后，代码又显的杂乱无章，那一坨坨代码总是在不断的重演。既然无法确定需求日后是否会修改，那我们只能通过提高代码质量来应对，以不变应万变，合理设计接口，每次更改需求时多思考，对于多次使用的代码进行封装提取，尽可能少的改动既有的逻辑。
必要的重构
大量重复或冗余的代码–>上文提到，可复用性和灵活性太差，为了赶进度只好拷代码然后改一改，这样的情况还是比较常见的，如果同一个类中有相同的代码块，请把它提炼成一个独立的方法，如果不同类中具有相同的代码，请把它提炼成一个新类。
过大的类和过长的方法–>过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。亲身体验，当看到一个庞大的类的时候，内心就有点怂了，尤其是一些不规范的写法后，看了显得很蛋疼。过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破，可读性和可维护性都不太好。当看到一个过长的方法时，需要想办法将其划分为多个小方法，以便于提高可读性和可维护性。
高耦合性–>当增删改一个小功能时，牵一发而动全身，功能模块与功能模块之间直接用类耦合，这些都是不合理的，这些都是抽象设计的不够理想，功能代码太过分散所引起的，面向接口编程思想还需要提高，尽可能抛开面向实现编程。
臃肿的类–>类之所以会臃肿，是因为开发者缺乏对最基本的编码原则，即“单一职责原则”（SRP）的理解。这些类往往会变得很臃肿，是由于不同的且在功能上缺少关联的方法都放在了相同的类里面。
不规范的书写–>不规范的命名、错误的书写习惯、缺乏必要的注释、乱七八糟的逻辑等，形成了一坨烂代码，别人没法维护，自己维护越来越乏力。
建议：最好别把希望寄托于重构，应该在日常开发中更加注重书写习惯，才能节约更多的时间，把规范养成一种习惯。总结的应该不全，目前只能想到这么几条，也欢迎各位补充。
总结
“一个程序员用在写程序上的时间大概占他的工作时间的10-20%，大部分的程序员每天大约能写出10-12行的能进入最终的产品的代码——不管他的技术水平有多高。好的程序员花去90%的时间在思考、研究和实验，来找出最优方案。差的程序员花去90%的时间在调试问题程序、盲目的修改程序，期望某种写法能可行。”这句话摘抄自《鲜为人知的编程真相》，我很喜欢这句话，做好码前思考和准备，才能写出更优质的代码，一个良好的习惯，胜于一切。
