老项目代码乱，谁都想重构。但重构最怕的是一改就崩，所以顺序比决心重要。先动哪一块，是有讲究的。客户一开口问的是，代码重构到底要不要上。答案取决于，它能不能替掉一部分人工。
先补测试再动手
没有测试的重构等于闭着眼走路。先把核心流程的测试补上，改完之后才知道有没有改坏。
补测试不用一次补全，挑最重要的几条流程就行。比如下单、支付，另外还有登录这几条，先盖住。
有了这个安全网，后面改动才敢下手。
再拆最独立的那块
重构不要一上来就动核心。找相对独立、耦合少的那一块先拆，风险最小，也能练手。
独立模块改坏了影响面小，改好了还能给团队积累信心。第一步走稳，后面才推得动。
拆的时候尽量保持对外接口不变。外面调用的方式不变，内部怎么改都行。
边跑边换，不停机
重构不用停机。新旧逻辑可以并行一段时间，新逻辑稳定了再把旧的撤掉。
做法是先让新代码接管一小部分流量，观察一段时间，没问题再逐步放大。
这样即使新代码有问题，影响也只是一小部分，随时能切回来。
我们的经验是，重构真正的成本不在写代码，在验证。把验证的路径设计好，重构就成功了一半。
怎么让团队也跟上
重构不是一个人的事，团队得步调一致。
先把标准说清楚。改成什么样、什么算改好，大家心里有同一杆秤，才不容易各改各的。
改动的代码要有审查。哪怕只是简单过一眼，也能拦下不少低级问题，比上线之后回滚便宜。
还有一点是别在赶进度的时候动手。重构要留出余量，赶工的时候做重构，两头都容易出问题。
另外可以挑一个愿意学的人先带。重构的过程其实是很好的学习机会，跟一遍下来，对系统的理解会深很多。
别指望一次就把代码改漂亮。能改到「看得懂、改得动，还有出问题好定位」，就已经很有价值了。
一次不行就多来几回，别急。
关于重构，问得最多的那几点
要全部推倒重写吗
多数情况不用。逐块替换风险更低，也能随时停下来。
重构要停业务吗
不用。并行运行、逐步切换，业务可以照常，风险也可控。
怎么判断重构有没有效果
看改动后的缺陷率、发布速度，以及新人上手时间，这几项改善了才算有效。
这话常斌敢答应，也敢承认：先补测试，再动最独立的那块，一步步来。
从最独立的一块开始
我的建议是先补测试，再挑耦合最少的模块试手。第一步稳了，后面才有底气往下推。
带过的 1000 多名学员，反过来也帮我们把课件磨得更实。做老项目维护这种事，信服无限会先给核心流程补一层测试。铺开之前，告诉我你的项目最不敢动的是哪一块。