转载

为什么好好的开发者，会写出这么糟糕的程式？

当我接下把旧 Python 程序库转移到 Node 的这份工作，心里是有点兴奋的。这种项目比维护程序要自由得多，而且重写别人的程序码有时候还满有趣的。

不过我们稍微看过要处理的程序后，这种兴奋感就消失殆尽了。我知道别人留下的程序码常常一团乱，但我写程序 15 年来没碰过几次这麽严重的案例。先前的作者创造了自己的框架，而它毫无模式可循：没有做好关注点分离（Separation of concerns，SOC）、混乱的空白和缩排、变数被来自相似却不尽相同的方法得出的相同数据覆写、滥用魔术字串（magic string）⋯⋯。

这团混乱简直就像让一群只会鬼叫的猴子随机从 Google 複製一堆程序码下来一样。

然而，并非这程序码惨不忍睹的品质激发了我些这篇文的动力。而是我在那裡工作了几个月后，竟然发现写出这份程序的是一组有经验且技术精良的资深工程师。究竟是什麽因素，让一组如此有竞争力的开发者製造，甚至交出这样的成品？为此我列出了一份清单。

以下是连有丰富经验的团队都可能会犯的坏习惯陷阱，而且会严重地影响你的最终产品，任何静态分析工具或开发方法论都救不回来。

「估计进度」大灌水

这份项目很重视截止期限，甚至为此会影响程序品质。当你的开发者把交件看得比写好程序还重，最终他们得为了让主管开心而妥协。两种常见的应对就是做出过量的预期或过度承诺，进而大大地增加工作负担。

通常要做出过高预期比较困难，因为效果通常会即时反映项目成本。所以开发者可能就会转而许下过高的承诺。接著他们就只好跳过一些重要的工作，比如思考结构上的问题，或者设计一些自动化机制来解决任务，而去满足那不切实际的目标和期限。这些任务通常被视为附加价值，所以被砍掉了也不会发现。当你开始欠技术债的时候，产品的品质就会下降，然后因为重整程序码的成本呈指数型成长，所以直到一切太迟的时候你才会发现。

以这个案子为例，可以看到有些程序码明显就是複製来的，但开发者显然赶著交件，连查一下以前有没有别人写过一样的方法或 SQL 查询都没做。

有时候估计本身也可能是假的。比如说敏捷开发有个词叫「开发速率」（Velocity），是要计算你的团队多久可以交件，然后做一些微调来加快进度。问题在于，在短期至中期开发间不可能准确地估计速度。就像

平均律（law of averages），通常你无法用过去的表现来预测你现在能做多快，因为情况不同，过去的表现对未来的成果来说不是个有效的指标。

开发者一天其实可以写很多程序码，但如果要看完全部的说明文件并花时间和组员沟通，可能 3 天还写不到 5 行。平均写多少程序并不能反映出心态准备等重要的资讯。

忽视项目背后的知识

随著项目推进，你的团队会学到一些商业上的东西，诸如背后的概念或各项业务之间的连接方式等等。因为在完成前很难完整预知结果，也不知道会碰到哪些挑战，他们也会在开发过程中逐步了解程序应用的状况。有些产业比较複杂，更是需要长时间的累积才能消化。

既然我这个项目是改写旧程序，上述这点影响就特别大。团队管理层对这项项目了解的程度，会和项目进度息息相关。如果你负责一项大型项目，裡面的模组你没经验又没人可问，那就得小心了。改写程序码重点就是要利用第一次写旧程序码时的背景知识，所以必须格外重视这点。

像我的例子，若找另一组团队来改写，那就是扬弃了既有知识，全靠新团队的技术，却无法弥补缺乏资讯的短处。就算是程度普通的开发者重写自已的程序码，绝对会比你另外找人做还要更快更好。

甚至聘用也要考虑项目的背景知识。一项项目内含愈多资讯，要让人跟上进度就愈困难。所以产业知识不只开发的时候很重要，在雇用对的人的时候也很重要，不然你就会跟一组糟糕的团队卡在一起好几个月。

追求错误指标，比如「完成的 issue」或「每日贡献」

当评量指标变成目标，就不再是个好指标了。

－Goodhart’s law

在我正渐渐掌握这个项目的时候，有人问我为什麽另一个家伙完成 issue 的数目比我多，讲得好像只要快点交差就是好事。当然可想而知，我只看了他的成品一眼就在一行程序裡面发现四个错误。聚焦在这种错误的指标上会让你的项目脱轨，而且带来的压力不亚于项目期限。

比如「退化率」（ regression rate ）就是常被忽略的指标。像 null pointer exception 就是要一段时间之后才会显现的问题，如果你没注意退化率，那这些 bug 就会不断从各处突然冒出来，而因为你找错地方，所以永远找不到根本原因。

儘管最终极的考量还是呈现给客户的成果，以及他们对产品满不满意、有没有超越期待。但要不被贡献率和 issue 完成数等指标诱惑，却需要极强的自制力。

要知道指标有没有用，有个好方法就是试著去了解它代表什麽样的个人价值。著重那些促进细节、沟通和态度，又很难作弊的指标。

以为好的流程能解决糟糕的人

在企业中，好的流程已经被当成某种万灵丹。根据我的经验，一些招聘技巧很糟的大公司，特别爱订一堆严格的规范，好让糟糕的人也能正常运作。但这却限制了团队领导者的创造自由，而且还必须有人先开始正确执行这些流程，后面的人才能跟进。

这是个恶性循环，但只要解决聘雇问题就能解决。好的人才会自动弥补你团队中的不足，而这也就是用聪明工作取代努力工作的意义所在。

这些开发者们有时候也特别难沟通。身处一个複杂的程序库中，我常常得向周遭求援，但是其他人通常都不愿放下手边工作来帮忙。这样的态度不怎麽好，尤其碰到特别困难、不得不求救的工作时，很少同事同时具有知识和意愿伸出援手，这会让工作压力倍增。

你需要有常识又有品味，并且敢于指出作业流程哪裡会妨碍进度的人。每种开发工具、静态分析工具和通讯工具都有好用和不好用的时候。你需要有人指出不合理的地方，而非盲目地搬来几个月前在不同情况下用过的流程照本宣科。

忽视实证有用的方法，比如程序码审查（code review）、单元测试

就算跟著现代最新的软件开发流程，可能也不足以把脱轨的项目救回来，但想要团队有竞争力，这点不论如何还是得做。而这就是经过实证有效的方法登场的时候。用测试来推进项目，可以减少 40%-90 的瑕疵；程序码审查也能降低错误率，在人工测试下甚至可降低 80%。

想像一下我碰到这种情况有多挫折：我和其中一位旧程序码的开发者一起工作，而他的萤幕上骄傲地显示著「笔记本」软件。在 90 年代光用「搜寻」功能来找方法可能很潮，但现在要是 不能用 IDE、版本控制、程序码检查工具，根本绑手绑脚。 现在不管项目大小，这些工具都是基本配备。

想进一步看看软件开发中已经证实有用的方法，可以参考《Making Software: What Really Works, and Why We Believe It》这本书。它充分列出了近年来已经证实好用又有用的应用方法。

雇用不愿交流的开发者

并非所有开发者都不会和人交谈。我曾经也是个害羞的开发者，现在还是可以好好地面对观众发表演说。

最大的问题还是自己连尝试都不愿意，或觉得增进沟通技巧的要求很烦。相较于上述所有问题，加强沟通技巧是最能加快开发流程的方式。尤其当你藉此拉近距离，分享资讯，就能营造更有热忱、彼此连结的办公环境。就算另一个人远在好几万哩外，只要一通 Skype 就能花 5 分钟解决原本又臭又长的 coding 马拉松。