本文转载自 程序员编程社区
当你觉得眼前的旧代码很烂时，该怎么办?
你觉得旧代码写的很烂，那又怎样呢?它们已经上线，已经在实际运行中经受住了考验。
重写代码消耗了12个月！
我们从头开始重写代码浪费的时间。你能想象在软件行业，12个月的时间没有任何新产品推出，没有任何新版本更新吗？
真的，我不由自主地问自己这个问题：
在这个快速发展的世界里，12月的时间能让我们做多少事情？
“2015年1月20日，星期二，下午5:10，AntiMalware软件终于进入了第一次公测。”
经过几十个小时的不眠不休后，第一个版本的软件说明书终于发布到了网站上，这标志着我们的新旅程的开始。
我在一家为企业和终端用户提供安全软件的小型网络安全公司工作。我们开发的软件保护用户免受恶意软件的侵害。如果用户的电脑被恶意软件感染，我们的软件会帮助他们清理。AntiMalware就是其中一个软件。
第一个测试版收到的反馈令人鼓舞。我们有四个开发人员为这个产品工作，不断地修复Bug, 改进产品功能，推出新版本。
为什么你觉得旧代码异常混乱？因为读代码更难
这大概就是代码Reuse难以实现的原因，也可以解释为什么你组里的每个人都喜欢用不同的功能将分割的字符串转换成一个数组。比起猜测旧的功能是怎样实现的，重新写一个自己的功能要简单和有趣多了。
作为这个公理的推论，你可以问问身边的程序员他们正在奋战的代码怎么样？“简直是一塌糊涂！”他们肯定会这样说。“我简直想推倒重来！”
为什么认为代码这么糟糕呢？“额，看看这个功能，竟然有两页长！完全不知道这些东西为什么在这里！完全不知道这些API是干什么的。”他们会这样回答你。
怎么避免代码重构？
重构是避免不了的，程序员永远需要在好的架构和不停变更的需求中做取舍，通过不断重构消化掉脏代码。你需要避免的是代码彻底超出掌控之后完全重构这个过程。
简单，别省钱，别找外包，找牛逼一些的程序员，最好招一队人马。
反正你要的又不是好代码，只是一个结果，代码的好坏你也不在意对不对，所以没责任心也没能力的程序员把事情搞砸再正常不过，这个便宜可不好占。
我见过把好代码重构成垃圾的，也见过垃圾代码维护不下去只能重构的，全看拿工资的人是不是有品味。
不过老板们大约也不用担心，花钱从高端一点的公司里边挖人，由靠谱的人来把关就好了。
怎么理解代码
所以当你发现前任留下的代码乱七八糟的时候，不妨冷静下来，从以下三个方面入手理解代码、改善代码：
1、代码的结构有问题
如果一段网络代码突然弹出了自己的对话框，应该是UI代码需要被处理。这些问题可以被解决掉，你要一次次小心地移动代码，重构，改变接口。
还需要一位细心的工程师立马仔细地检查这些改变是否有问题，从而不打扰到其他人。事实上，甚至比较大的结构变化也可以不扔掉代码来完成。
大牛程序员Joel Spolsky回忆说，曾经在某个项目中，他和他的团队花了好几个月重新架构在一点上：
把代码动来动去、清理、创建有意义的基类，并创建了模块之间的完美接口。但是他们始终非常小心翼翼，并没有产生新的bug、也没有丢掉任何旧代码。
2、代码的效率不高
曾经，Netscape的渲染代码被传非常缓慢。但事实上，这只会影响该项目的一小部分，这部分是你可以优化甚至重写的。你完全不必重写全部代码。
优化速度的1%工作量，会让你获得99%的爆炸性提高。
3、代码写得很丑
有些代码真的写的很丑，比如Joel曾参与一个项目，开始用下划线做开始的成员变量约定，但后来改用更标准的「M_」。
所以一半的功能用「_」开始，一半用「M」开始，这看起来真的很丑陋。但这个问题5分钟就能解决，而不用从头开始写全部的代码。
最后，你要记住，从头开始再写一遍并不意味着你会写出比以前更好的代码。因为你没有参与到上一个版本的创建，所以你其实根本就不算有经验。
一旦你准备推倒重写，你可能会再犯一遍版本一犯过的错，甚至会产生更多的新问题。