消灭项目中的烂代码
软件系统的运行时间越久，代码就愈发弥漫着一股腐烂的气息。
?
在实际的工作经历中，很少能遇到从零开发重新开发一个新系统的任务，很多时候都是在维护了一个运行多年的老系统，不是修改那些甚至已经不知所谓的老代码，就是在已有的软件框架基础上进行新功能的添加开发，但是那个框架为了保证系统稳定性，也是再修修补补中愈发的臃肿，增加一个功能的过程那是颇为曲折。
?
良好的设计是优雅代码实现的前提。
?
没有计划就盲目的开发，得到的肯定是有坏味道的代码（除非是天才）。即使是xp极限编程，提倡立即动手写代码实现功能，也并不是说完全没有实现规划设计就开始写代码。
?
无论怎样，事先花一点时间做设计，完全是值得的，对你未来的代码，以后的修改完善必定是有好处的。
?
但是不管怎么样的细心分析，谨慎设计，得到的设计结果也不会是十全十美，无懈可击的。跟不用提在根据设计实现过程中，还会不断的失真放大，偏离了设计的原方向了。最后在项目逐渐开发深入的过程中，设计中的不足，考虑的不周就会不断被发现，而且实现的代码也会逐渐凸显问题，需要你着手去处理。
?
这个时候怎么办？设计错误了，决不能继续这样将错就错下去。计算机是很执拗的，1、0泾渭分明，沿着错误的道路一路走到黑肯定是不行的。当方向错误的时候，不是仅仅调整步伐就可以挽救了了的。
?
必须修改设计，然后再根据重新设计的结果对代码动手了。这点和需求功能的补充完善不一样的，必须立即进行，不然最后烂代码的泥沼必然会将项目带入万劫不复的地步。
?
即使是设计良好的代码，在未来软件长期运行维护过程中，多人加入了代码的维护工作，每个人的水平参差不齐，有高有低，自然编写的代码的质量也有好有坏，代码结构的流失是累积性的，代码就越来越烂了，这个时候，也得想办法如何改善代码，让它回到应有的轨道上，现在也许修修补补的还能将就维持，但总有一天，它烂到无法再下手的状况后，维护的人员就会崩溃了。
?
下面就看对代码怎么动手了。
?
第一反应肯定就是当下流行的代码重构了。这肯定是第一选择。在现有代码的基础上，进行代码的小规模改动，保证软件能够正常的按照原需求设定的方式运行，实现新的正确的设计结果，这是最好的选择了。
?
就像前面说的，改进软件的设计，代码如何与改进的设计相对应？重构。并且甚至很多情况下，设计的改进想法从何而来？都是来自具体的代码实现修改过程。没有重构，程序的设计会逐渐变质。当人们只为短期目的，或是在完全理解整体设计之前，就贸然修改代码，程序将逐渐失去自己的本来面目，软件开发人员就愈来愈难以通过阅读源码来理解软件的设计，从而更加难以入手修改源代码。
?
重构就像是在整理代码，随着对代码的理解的深入，对代码进行重构，改善代码的结构和实现，也会最终帮助你更好的修改代码，维护软件。所以，重构，最后都会促进改进软件的设计。
?
重构改进了软件结构和实现，我们常说，源代码不仅要正确，还得有良好的可读性，毕竟更多的时候，它是让程序员来阅读的。良好结构实现的代码，更容易去阅读理解它，也就意味着改动更容易。
?
说了这么多重构的好处，说起来重构虽然不是包治百病的万灵丹，但却是一剂良药，可以帮助始终良好的控制代码的质量。
?
提到了“始终”，就意味着要经常性的重构，而不是专门在开发工作中，安排重构任务。很有可能让你专门去对代码重构的时候，你已经没有了当初要重构代码的冲动了。
?
在你添加功能或者修补代码的时候，如果发现代码已经难以下手，或者代码的结构混乱到无法去阅读理解了，在你就要发狂之前，这就是代码重构最好的时机了。这股冲动会帮助你一鼓作气的去完成代码的重构，毫不迟疑。
?
其实重构虽然看起来要专门去阅读理解代码，然后重新编写代码（不管代码编写工作量是大是小）来实现，是需要花时间的。但是最终得到的结果是，你花掉的时间是值得的，你得到的是清晰易读的代码，你以后的维护修改工作要轻松的，节省下更多的时间。
?
这里肯定不能详细的去说如何进行代码重构，这方面的资料现在很多很详细（我正在读《重构改善既有代码的设计》这本书，有时间把重构的内容也写写）。而且也不必把重构看的那么神秘。很有可能你已经在工作中在进行代码的重构了，只是你没有认识到罢了。
?
【 就像是我当时做一个老系统的维护一样。那个时候最主要的工作就是进行系统报表的添加和修改。也许系统最开始报表不多，都是单独一张报表添加一个类，去实现该报表功能。现在的报表越来越多，而且代码的实现和结构都差不多。每天重复这样的工作肯定很无趣。于是就专门花了时间，将我主要维护的那一类报表仔细分析了下，把功能实现相雷同的代码整理出来，专门实现了一个报表框架功能类，以后只要在该类基础上进行具体报表业务功能的添加，就能完成报表的功能实现了。
?
虽然当时看起来耽误了工作任务进度，但最终的结果是我最后还是提前完成了工作任务，并且还是在很轻松的进度下完成的，以后的工作也变得分外轻松，从一天多的工作量，变成了只需要两到三个小时就ok了。】
?
没错，消除重复的代码，这就是重构，改进设计的一个重要的方向。代码量的减少，其实并不会使系统运行更快，但是代码量的减少将使未来可能的程序修改动作容易很多。
?
代码越简单，越不会出错，这绝对不会错的。
?
但是并不是任何时候都能用代码重构来应对设计的改变的。
?
有的时候，在不得已的情况下，重写比起重构来，是更好的方法。
?
重写是需要花更多的精力和时间的，但是有的时候，代码的实现与设计的新的目标已经差距太大了，或者说系统的现有代码已经烂到一定程度了，实在是无从下手，比起分析这些代码，然后进行重构，根据新的设计想法，重新实现真的是个更好的办法，花的时间精力反而少。
?
或者现有的代码根本不能正常工作，或者不是设计实现上的偏离，而是完全偏离的系统功能需求定义的方向，那就放弃它吧，它已经是满是错误的代码，根本无法稳定工作。
?
不过这只是个别的极端情况，我也在工作中遇到仅有的几次，想想干脆把那些已经不知所谓的代码一口气统统删掉，长长的出一口气，忘记那些烂代码带来的坏味道，然后精神抖擞的重新实现的感觉，真是痛快！
?
当然，如果你总是选择这痛快的感觉的话，很有可能会乐极生悲的。所以，如果没有那个必要的话，还是老老实实的对代码重构吧。?
?
?
?
