年轻程序员的悲伤

这是一个真实的故事，故事的主角是一位虽然年轻却充满了激情的程序员。那还是2004年底，他刚开始在一家小公司工作：一份不错的薪水，使用的是他最爱的编程语言，能接触到各种疑难杂症，还可以做建模架构的工作。

对于这位年轻的开发人员，这并不是第一次工作经验。但是他的第一个项目却被证明是有问题的。那时候，他认为功能是不需要变的。但是他错了，于是乎，每个功能的改变都需要全部重构，从而导致bug横行以及时间的巨大浪费。他甚至尝试了一些良性的方法，如编写测试。但是他的测试需要维护，需要编写时间，以及更多的时间才能被执行。

和每一个年轻的开发人员一样，他的成长道路上都是那些经验丰富的开发人员的声音，“过早的优化是罪恶的根源！”，以及“写测试！测试！测试！”。也许他只是在重构一个小型的实用方法，但这个时候经验丰富的开发人员过来了，郑重其事严肃地警告他，“不是告诉过你不能过早的优化吗？”，或者“你这是在写测试么？”。

但往往，年轻的开发人员直接就左耳朵进右耳朵就出了。因为他们不明白为什么过早的优化应该是罪恶的根源，以及为什么要写好测试。从他以往有限的经验来看，他认为接下来的技术指标并不能长效工作（因为它们往往会改变），以及写测试纯粹是浪费时间。

“到底是为什么我每次都需要重写代码？究竟又是为什么现在我写的代码之后还需要重构？还有就是到底是为什么我得花这么多的时间用来写那些没用的测试？“年轻的开发人员心里在咆哮。

于是乎，终于有一天，年轻的开发人员又开工了一个新项目。这一次，他决定无视那些经验丰富的开发人员的警告：他相信他写的每一个代码片段都会既快捷、可配置，又强大，并且可以承受每一次参数规格的改变。

在他绞尽脑汁地搞定项目的核心之后，年轻的开发人员忍不住得瑟起来：“哈哈，我就说那些‘老家伙’的话是错的！”仿佛凯旋在望，年轻的开发人员眼中已经出现了胜利的光芒。

然而，发布一段时间之后……

突然有一天，客户告知他们程序发现了bug。经验丰富的开发人员看了这个bug，找到问题的所在，就要求年轻的开发人员去修复他自己造成的bug。

听到自己的代码被嫌弃了，年轻的开发人员第一感觉是生气。但是当看了项目之后……却发现，他居然无法理解自己写的代码了！他已经完全看不懂这些代码的含义！天哪，呜呼哀哉！

但是没办法，这是他的问题，他也只能硬着头皮上，好了，终于修复好了这个bug——但是过几天又出现了新的bug。bug——补丁，bug——补丁，焦头烂额。

年轻的开发人员简直要崩溃了，“也许我并不适合这种工作，不然我的代码怎么总也写不好？”在各种质疑自己的声音中，年轻的开发人员半信半疑地打开了经验丰富的开发人员的项目。

他震惊了！代码是如此简单易懂——有注释、有测试。这跟他写的代码完全有着本质的不同。特别明显的区别就是：没有额外的配置，对每一行代码都进行了测试，每一个方法都有一个有意义的名字，并且方法非常短（最长的也只有几十行代码），代码只做了客户要求做的事情。

在那一刻，年轻的开发人员是非常沮丧的，但是经验丰富的开发人员来了，他走到年轻的开发人员的身边，一边走他其实一边已经在开始考虑如何重构这些错误的代码。

在一起合作解决问题的时间里，年轻的开发人员目睹了经验丰富的开发人员一步步解决问题的过程；有时候经验丰富的开发人员还会监督年轻的开发人员编写代码。

几天以后，又一次发布标志着bug已经被修复了。造成bug的那部分代码片段现在已经进行了测试，不但易于阅读，并且非常稳定。经验丰富的开发人员看着年轻的开发人员，问：“你现在应该明白了吧？”

年轻的开发人员点点头。现在他确实明白了。想要完美，其关键并不是能够预测未来，而是编写易于改变并经过测试的代码（这样，如果要改变代码的话才不会造成bug），而且只需要满足当前的需求。而当他意识到这一点的时候，他在无形之中，已经蜕变成为了“差不多”经验丰富的开发人员。

“我们现在要重构整个项目吗？”年轻的开发人员问。

“当然不！这又没有预算的。”经验丰富的开发人员斩钉截铁地回答。

“但是，要是出现其他bug怎么办？”年轻的开发人员问。

“可以让自由职业者来解决那些问题。”经验丰富的开发人员答复。

然后，“差不多”经验丰富的开发人员开始能写出优良的代码，渐渐地向更高层次的水平靠近。当然，这是另一个故事了。

对于年轻的开发人员的建议：请回过头去看看你曾经写的代码，如果你的代码现在看上去没有以前感觉的那么漂亮，那么说明你在进步。

对于经验丰富的开发人员的建议：当你的身边出现了一个年轻的开发人员，或许你需要不时地替他们收拾烂摊子。如果你想摆脱这样的处境，那么就让他们尽快学会编写得体的代码。

对于自由职业者的建议：你或许应该提高你的酬劳了：-P