分类： 开发学习感悟

我相信很多人都不能一次就写出整洁、漂亮的程序。 要编写整洁的代码，必须先编写肮脏代码，然后再逐步改进它。
估计大家都有过这种想法，首要任务是编写出能工作的程序。只要程序“能工作”，就转移到下一个任务上，而那个“能工作”的程序就在了最后那个所谓“能工作”的状态。其实，这是一种自毁行为。
毁坏程序的最好方法之一就是以改进之名大动其结构。因为很难让程序以“改进”之前的方式工作。

如何避免该状态发生？
可以采用测试驱动开发，这种方法的核心原则就是保持系统始终能运行。确保每次修改都能保证系统能像以前一样工作。

要知道，代码能工作还不够，能工作的代码经常会严重崩溃。不要满足于仅仅让代码能工作的状态。更不要拿没时间改进代码结构和设计来说话，因为进度可以调整，需求可以重新定义，团队可以动态调整。但糟糕的代码只会一直腐败发酵，然后拖团队的后腿。当然，糟糕的代码可以清理，不过成本比较高，随着代码的腐败，模块之间相互渗透，存在着大量的依赖，想找到它们清理出去，很难。所以解决之道，就是保持代码持续整洁和简单，不让腐败有机可乘。

第二章内容：为何重构。

重构与性能优化有很多相似之处：两者都需要修改代码，并且两者都不会改变程序的整体功能。不过两者的差别在于其目的：重构是为了让代码“更容易理解，更容易修改”，性能优化是为了让程序运行的更快。

为何重构：
1、改进软件的设计。
2、使软件更容易理解。
3、帮助找到bug。
4、提高编程速度：从长远来看。

何时重构：
有这么一个三次法则：第一次做某事时只管去做，第二次做类似的事情时会产生反感，但是还可以去做，第三次再做类似的事情，你就应该重构。正如老话：事不过三。
1、预备性重构：让添加新功能更容易。
2、帮助理解的重构：使代码更易懂。
3、捡垃圾式重构：清除垃圾代码。
以上三种都是见机行事类型的重构，遇到了顺便去做，或者记下稍后去做。这些应该是我们编程的一部分，让绝大多数的重构在我们的编程中自然而然的做到。剩下的就是：长期重构（有计划的重构） 和复审代码时重构。

何时不该重构：
第一条：我确定以后都不需要修改它，那我就可以不重构它。
第二条：为了API，暂时可以容忍。
第三条：如果重写比重构容易，那就重写吧，因为重构还得先理解整块代码。不过到底是重写还是重构，这实在不好建议，需要你或者你的leader根据自己丰富的经验来决定。

重构的挑战：
1、延缓新功能开发：显而易见。
2、代码所有权：是否有权限修改，是否会对其他人的代码造成较大的影响。
3、分支：在分支上工作越久，集成回主干的难度越大。建议：每天至少向主干提交一次（在我们这里是，每天都要将主干的代码合并到当前分支）。
4、测试：最好有可以自测试的代码。不然就需要我们的开发环境很好的支持自动化重构，或仅仅使用那些一定安全的重构手法。
5、遗留代码：往往很复杂，最关键的是这是别人写的，且没有相关的测试。
6、数据库。