（转）写代码比读代码简单, "说自己"比"理解别人"简单

昨天一位年长的老板约我一起吃午饭。我们一边等着送吃的过来，一边追忆着他公司初创时期的情景。他的一句话让我感到局促不安：

哎呀，JP，我记得那时候你看 Dan（公司的第一开发者，首席程序员）写的代码，你说：“这代码写的可不怎么样，需要重写！”

遗憾的是，我当时没勇气告诉他，其实，我犯了一个错误。那些代码并不需要重写。虽然我那会儿确实认为那些代码写的不怎么样，但是经过这些年的经验积累，我发现大多数的开发者都会觉得别人写的代码不怎么样。甚至就连他们自己多年前写的代码，在现在看来，他们也觉得不怎么样。这些人很可能是对的，因为那些代码（他们认为不怎么样的代码），确实真的不怎么样。

但是，如果铁定要重写代码这种事儿，我认为那是个低级错误。

There were business assumptions made that you can’t possibly know now. Plenty of undocumented business assumptions that the code will handle just fine. You can’t possibly account for all of them. 有些业务假设你可能一直都不知道。许多未成文档的业务假设，代码却又能够恰当处理。而你没法解释所有业务假设。

我喜欢Joel Spolsky 写的《你永远不要做的事》这篇文章中的一些话：

我们是程序员。程序员是什么？在他们内心深处，认为自己是建筑师。当他们初次去某地时，第一件事就是推平这块地，然后从头开始，建造出一些宏伟的东西来。修修补补，优化改良，培养花圃这些后加的整修，我们并不感到兴奋。（译注：直白的说法就是，程序员都喜欢从项目的一开始就参与进来，而并不喜欢接手别人弄了一半的项目）

有一种更微妙的原因促成了程序员往往喜欢抛开旧代码，从头再来，那就是他们认为以前的代码一团糟。于是乎就有了一个有趣的现象了：他们有可能错了。原因是这种认为“以前的代码一团糟”的观点，其实是基于一个基本的编程法则：

写代码往往比读代码要简单的多。

这也是为什么代码复用这么难的原因。这同样也是为什么你团队里的每个人都喜欢用不同的函数去实现一个长字符串分解成字符串数组的功能。因为写他们自己的函数既容易又有趣，所以他们就不愿意去弄清楚以前的函数到底是怎么实现的。

按照此理论推论下去，你可以去问当今任何一个程序员关于他们现在正在写的代码。他们会告诉你，“简直是乱成一锅粥，没有什么比扔掉它们从头再来更好的了。”

当你雇了一个开发人员，如果他想重写那些能正常工作的代码，请抵抗这种行为。他或许会说Java又慢，而且已经过时了，Ruby on Rails 才是最酷的选择。他甚至可能给你说一堆时髦的词来劝说你。无论怎样，请你认真考虑一下。