主页 > B生活史 >为什幺好好的开发者,会写出这幺糟糕的程式? >

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

发布时间:2020-06-15   浏览量:108   

 

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

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

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

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

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

「估计进度」大灌水

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

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

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

有时候估计本身也可能是假的。比如说敏捷开发有个词叫「开发速率」,是要计算你的团队多久可以交件,然后做一些微调来加快进度。问题在于,在短期至中期开发间不可能準确地估计速度。就像 平均律,通常你无法用过去的表现来预测你现在能做多快,因为情况不同,过去的表现对未来的成果来说不是个有效的指标。

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

忽视专案背后的知识

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

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

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

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

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

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

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

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

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

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

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

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

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

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

忽视实证有用的方法,比如程式码审查、单元测试

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

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

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

雇用不愿交流的开发者

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

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

结论

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

以偏概全的俗语,指用过小的样本数,来推算普遍情形。

回归测试发生错误的比率。回归测试旨在检验软体原有功能在修改后是否保持完整,新加入测试的模组,可能对其他模组产生副作用,故须进行不同程度的回归测试。

上一篇: 下一篇: