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

qowng4sypim-joel-beukelman-1024x683

当我接下把旧 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 马拉松。

结论

当你用好的工具、实证技巧和良好的沟通来鼓励聦明工作,软件开发的过程也会自然流畅。 然而你不能因为采用了敏捷开发或什麽其他的工具,就自动假设其他都不重要,而且事情会迎刃而解。 如果一切都对了,你可以收到让生产力指数成长的综效,但要是忽视细节,也可能让一切陷入又慢又混乱的泥淖。

你也许感兴趣的:

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注