昨天，一位老上级邀请我一起吃午餐。当坐在哪里等待上菜时，我们缅怀起早期这个公司的往事。他有一句话让我心里一虚：

    啊，你这个判官…我记得当你看到Dan(公司的第一位程序员)写的代码时的样子。你说：“这代码写的真烂，需要重写！”

    我恐怕是没有足够的勇气告诉他，我这“代码需要重写”的主张是错误的。不错，我认为这代码写的很乱。但是，据过去历次的经验，我感觉大部分的程序员看着别人写的程序时都会想：这代码写的真烂。事实上，当一个程序员数年后再看自己写过的程序时也会想：这代码写的真烂。也许他们想的是对的；这代码确实很烂。

    但是，如果你认为代码需要重写，你将犯下一个低级错误。

    公司里有一些想当然的看法会让你可能现在不能认识到这点。大量的不成文的想当然的观点可能会让你无法解释清楚。

    我喜欢Joel Spolsky说的关于这种事情的话，有些事情你永远不要去做：

    我们是程序员。程序员，在他们自己的心里，是建筑师，当他们来到一个地点，第一件想要做的事情就是：把这地方推平，盖上辉煌的建筑。他们对慢慢的修缮没有兴趣：小修小补，改善，培植花草。

    有一种不可捉摸的原因让程序员们总是希望丢掉这些代码、重新再写。原因是他们认为老的代码是混乱的。可是，你会观察到一种非常有趣的现象：他们的判断通常是错的。他们之所以会认为老的代码很烂的原因来自于一个重要的、基本的编程定律：

    读代码比写代码要难。

    这就是为什么代码很难重用的原因。这就是为什么每个团队喜欢用自己不同的函数来做把字符串拆分成数组操作的原因。他们要写自己的方法，这更容易，更有趣，不需要弄清楚老的函数的工作原理。

    根据这种定律必然得出这样的一个结论，你现在可以问一问任何一个程序员，问他们对正在写的程序感觉如何。“乱的不能再乱了，”他们会这样告诉你。“我宁愿把它们都删了重新再写。”

    当你招募来了一个程序员，如果他想重写看来工作的不错的程序，你要抵制。他也许会说Java过时了，太慢，Ruby on Rails如何的酷。也许他会向你抛了一大堆专业名称术语。不管他如何做，你要三思而行。

    你觉得呢？

建议继续学习：

1. 如何避免重构带来的危险    (阅读：3721)
2. 什么是重构，什么不是重构    (阅读：3492)
3. 前端重构实践（一） —— 性能优化    (阅读：3188)
4. 实践中的重构    (阅读：3059)
5. 网站重构到底是什么，网站重构到底要多久    (阅读：2929)
6. 关于重构和重写    (阅读：2589)
7. 重构发现：指针操作问题    (阅读：2408)
8. 网页重构应该避免的10大 CSS 糟糕用法    (阅读：2258)
9. 实战遗留代码    (阅读：1809)
10. 代码重构方向原则指导    (阅读：1637)