作为软件开发者的你，一定听说过重构一词，在我们平时的开发生活中，为了使代码更加易于理解和处理一些代码编写过程中没有注意到的问题，我们会相当频繁的对我们的代码进行重构处理。不过今天我在这里不是想讲该如何重构，或者我们为什么要做重构，如果你的确有这方面的需求你可以查看《重构：改善既有代码的设计》这本书。
今天我想讲的是重写，这是我作为一名入门级架构师屡试不爽的必杀技，在这里分享给你。
其实从思想和技法上来说，重写应该可以归类为重构，但有一点不同的，就是重构需要熟悉遗留代码，而重写不需要熟悉遗留代码。
代码是有生命力的，他会随着时间的推移，逐渐的老去，失去活力。
写出一段好的代码，他的生命力将会很长（何谓好的代码，其实有很多讨论，例如应用SOLID原则编写代码，这个就不在这里讨论了），但无论如何，他始终是有生命周期的，终将有老去和失去活力的一天，当那一天到来，我们应该决定推翻重做还是任由其自生自灭？
而且在团队合作中，本来可能以你个人的素养，你可以做到代码永世长青，但是你无法避免你的团队成员破坏你代码的生命力，当然有一个很好的实践——只有代码库的Owner才能签入代码，任何由其他人完成的代码都需要由Owner亲自审核后，亲自签入，故他可以在签入前，保证这段代码的素质是符合自己的，但这对Owner的要求高，且若需要在短时间内开发大型工程就会有极大的局限，Github上的代码几乎都是用这种方式管理的，甚至像Linux这类源代码也是用这种模式进行管理的。
若非上面那种实践，设想你处于一个水平参差不齐的团队，每个人负责一个模块的开发，系统上线进入维护阶段后，某人离职后发现其设计的模块复杂且不易理解，有极大的难度让后续人员去理解并进行修改，这个时候再来考虑重写？
我知道你的疑问，一定会觉得这样是不是成本更高，风险更加不易控制，若你是在这件事情已经发生后才开始考虑重写这件事情，那不用想了，一定是成本很高，且风险极大，这种时候的确不建议轻易下结论重写。
于是，我之所以写这篇文章便是希望你能在发生这件事情之前就做好准备。
我们首先来分析一下，一般都会有些什么情况会导致重写是必须发生的。
一般有些什么原因会导致需要重写注解：所谓打补丁的方式，是指你在发现未被框架预先考虑到的异常情况出现后，通过判断特定情况给予特殊处理的方式让程序得以正常的方式。这种处理方式的潜在危害就是你不知道还会有多少个这种特殊情况存在。
我们是不是应该在这个时间到来之前，提前做一点什么准备呢？
我们应为重写提前做好什么准备末了，我还是得再强调一下，我的观点不是要让大家去经常重写代码，而是希望能够让大家认识到，一定会有不得不重写代码的可能性，尤其是在水平参差不齐的团队中，所以提前为这种可能性做好准备，绝对比临时抱佛脚强上很多倍。
| 欢迎光临 (http://www.51hei.com/bbs/) | Powered by Discuz! X3.1 |