面对很乱的代码，你会慢慢看，慢慢改，还是重写？ 第1页

也许你有很强的编程能力，能驾驭1000行，5000行甚至10000行代码的重写，短时间内可以完成，并且bug不多，但是10万行呢，100万行呢，甚至数千万行呢？个人的能力总是有极限的。

团队的力量呢？2-3个人或许好找，但是去哪里找50-100个愿意去重写代码的人，并且还能保证质量呢？

更难的是，到哪里找到经理或老板愿意等你半年甚至一年不响应需求，不改bug，而是去重写代码，去用一套新代码完成和老代码一样的功能，甚至可能更多的bug。

抛开程序员的完美主义情怀，理性地看待分析旧代码，问自己几个问题：

是不是继续维护的成本真的比重新开发还要高？

是不是新的团队在设计开发能力上比原有团队上了一个台阶？

是不是有一些硬需求在旧代码上无论如何都无法做到？

是不是没有竞争对手在穷追不舍而不能停止更新维护？

是不是重写能提供些杀手级功能压制竞争对手？

分别对旧代码和新架构做下 SWOT分析，看看优势，劣势，机会，威胁都是什么。

旧代码或许在架构，接口设计，变量命名和缩进风格上不如人意，但是它是可以工作的，可以工作的代码意味着解决了很多问题，而这些问题在新重写的代码里并不会因为代码写得漂亮就自动得到解决，仍然要把前辈们踩的坑再踩一遍。

那么是不是就不能重写代码呢？不是，要等机会，看缘分的。

个人认为，如果我上面问的五个问题至少三个问题的答案是“是”，SWOT分析的结果里至少三项是有利于重写的，那么可以说也许缘分来了。