重构项目，你真的准备好了吗.docxVIP

重构项目，你真的预备好了吗 在重构项目之前，肯定要一再的问本人（和本人的组员）这个问题：我们真的需要重构吗？ 重构项目，在只是重构的前提下，对于公司的收益来说是——0，由于你的产品的用户，他们并不会为你的重构行为来买账，对于他们来说，你的源代码写的好看与否根本无所谓，对他们重要的是产品本身有没有改进。对于公司来说，重构行为不但没有带来任何利益，反而消耗了程序员资源，对于公司来说是损失。 一个互联网产品的生命周期可能就只要短短的几年，放长一点看，现在写的代码可能过几年就会毫无用处，在这样的前提下，现有项目的重构，肯定是建立在项目本身还格外有前景的基础上，这个项目将来还有多少潜力，值不值得去重构？假如这个产品本身并没有什么可做的了，那么能否还值得花时间去重构它？ 为什么需要进行项目重构 每个项目重构的理由各不相同，但个人总结来次要是以下两点 原来的项目漏洞太多，或者稳定性太差，当前的框架很难彻底根治。 新的项目需求，原有的程序框架已经无法满足。 假设你的项目没有很多bug，稳定性也很好，或者临时没有在现有框架下很难实现的新的需求，那么不建议进行项目重构。 我在上一家公司的SEM组工作时，经受的第一次重构，是将后台的竞价计算出的竞价的结果，由数据库的表（Table）存储改成了推送到队列系统（RabbitMQ）。后台竞价程序算出的竞价结果需要由另一个上传程序上传到Adwords等竞价平台，我们在过去的做法是在数据库建立了一张表，竞价程序将算出的新竞价存储在其中，上传程序则定期的去查询表中的新加入的记录，将其成批上传，并在上传后删除。那么为何要进行这次重构？ 随着公司的投放的广告词添加，单一上传程序实例很难在短时间内上传全部的竞价，但是假如运转多个上传程序的实例，则会消灭多个示例同时查询新加入竞价并上传，删除同一记录形成数据库死锁。（1. 原来的项目漏洞太多，或者稳定性太差，当前的框架很难彻底根治。） 新业务需求需要计算另一种格式的竞价，假如连续使用数据库表来存储，则要么需要对已有的表进行字段扩容/修改，要么建立新的表单。但是当时已经预见将来可能会支持更多格式的竞价，于是数据库表的存储方式将不再机警。（2. 新的项目需求，原有的程序框架已经无法满足。） 重构项目 经过一再衡量，我们最终还是打算重构项目，恭喜你，你将有一段踩坑之旅。 重构项目之前 重构项目的第一步是要了解项目。 重构时最简约发生的一类错误是没有能够完全的将原来的功能忠实的重现出来。很多开发者并不是手头的项目的原作者，并且项目也经过了很长时间的迭代，当代码越滚越大的时候，几乎没有人（包括原作者和产品经理）能够完全了解项目到底包含了哪些内容。当你看到重构后的功能和原来一模一样，并且测试人员也没有测出问题的时候，说不定哪个猴年马月添加进来的特殊功能，静静的被你干掉了。等到上线后，这个特殊功能的用户突然发觉功能没了，于是过来赞扬。 重构ING —— 测试 假如说什么是重构中最重要的第一步， 我认为是测试。 假如原来的代码没有单元测试、集成测试，有条件的话肯定要补充上。为什么测试如此重要？打一个比好，重构就好像对着一把老钥匙来配新钥匙，而测试代码则是老钥匙的模子，我们做出来的新钥匙要能够和这个模子全对上。这个模子越具体，则新钥匙可以正常开锁的概率越大。 回想我在过去的重构中消灭的一次严重失误，便是在重构过程中，有一个原来的单元测试消灭了错误，本来的断言是结果为NULL，但是我的结果是0，当时觉得可能两种结果都可以，于是错误的选择了将单元测试的结果“改正”，结果在代码上线后，0的结果形成了程序输出和之前相比大不相同。总结一下：1. 假如有集成测试，则这样的错误可以在上线之前发觉。2. 应当信任原来的单元测试集，而不应当“想当然”的去认为本人重构的规律正确。 重构ING —— 分支 代码重构的过程中，肯定不建议先删除代码全部重写。比较推举的是先拷贝出一个新的函数/文件/文件夹，然后写全新的代码。为什么要这么做？ 在写新代码的时候可以一边写一边参照原来的代码。 新代码的代码审查（Code Review）会比较洁净。 项目管理工具（Git，SVN）的历史比较洁净。 回到我上面说的由数据库的表（Table）存储改成了推送到队列系统（RabbitMQ）的重构，当时我的做法是，在竞价程序端，重新实现了输出的函数，使得竞价结果可以改为推送到队列系统。而在上传程序端，则重新实现了一个新的程序，只从消息队列中消费推送的消息，然后上传到Adwords等广告平台。原有的旧上传程序则没有改动丝毫。 重构项目的上线 —— 开关 略微大一些的重构，我会比较推举使用程序开关，使用一些把握参数来把握规律入口是用老代码还是新代码，这样在线上消灭了问题，可以准时的调整把握参数，快速的回滚到老的规律。 假如程序运转的结果