Dan North 最近发表文章《误导的艺术》,着重讨论了机会成本的影响。机会成本通俗地来说是指你针对某个情况作出来一个选择,然而有时候,可能还有一个更好的选择被放弃了。特别对于软件工程师而言,机会成本是个不得不说的故事,毕竟在每天的工作中,他们需要不断做出各种决定。
Dan 认为,软件工程师在工作中总是面临着很高的机会成本。为了证明他的观点,他提议做一个试验:
试一下这个试验:想一个你在开发软件的时候会用到的技术或者实践,或者就那个你最喜欢的实践吧,容易吧?好吧,第一步:你为什么用它?有什么好处呢?可能你想到了一些答案,那么就先写下来。现在,第二步:如果你不用那个技术或者实践,有哪些别的可供选择的方案吗?也请写下来,并且列出每一个的优缺点。
Dan 以那个在他看来是他遇到过的最被盲目推崇的实践之一:TDD(测试驱动开发) 为例进行了阐述。
Dan 认为,倡导 TDD 的那些理由,诸如为了系统稳定和应对变化,涌现式设计,自动化测试以及测试即文档等,背后也有着机会成本。比如,对于财务交易系统那一块而言,使用一些草图来理解系统可能会很有用,而不需要可能会导致很高成本的 TDD 了。至于涌现式设计,TDD 就像在查找最大值,然而寻找最佳的解决方案可能需要彻底的重新思考。而测试即文档则说不定会导致很多不必要的不同声音,反而让人搞不清真正有用的文档在哪里。
Dan 最后总结了他的文章并且建议:
所以不要被表面利益所迷惑,在你做每个决定的时候,都要好好权衡机会成本,因为不管你看得到还是看不到,机会成本都在那里,不多不少。但如果你能学会识别这些,你也能更上一层楼。
有些读者同意 Dan 的观点。 Gene Hughson 解释道:
很棒的文章。尝试任何事情,不管是新技术还是技巧,如果不去考虑成本和收益,那么将是个灾难。
然而,也有些读者有着不同的意见。比如,Sam Weisen 就在他的评论中提到,Dan 的文章这样去讨论 TDD 是有失公允的。
我恐怕不得不说,你误解了 TDD,你对 TDD 的攻击是毫无意义的。你的有些观点可能不错,但淹没在你的长篇大论之中。
Liz Keogh 则支持 Dan 的观点和提议,他觉得敏捷开发的信徒们应该更加开放地去聆听别的意见:
我发现评论中的很多人都犯了“不是真正的苏格兰人(No True Scotsman)”的谬误,也就是说如果某个事物对某人不起作用,那么一定是那个人用错了。我在一些敏捷博客中也都发现过这种情况,特别是提到 TDD 和 Scrum 的时候。其实很多情况下,TDD 并不是最合适的选择,比如统计工时的程序、修改一个紧急的产品缺陷。当然也有不少情况,TDD 是比较合适的,但却不是最佳选择。
看来很难让每一个人都赞同 Dan 的观点,特别是有关于 TDD 的,那么也可以此为契机从另一个角度来审视这个问题。 Justin 就提到:
谢谢你让我们看到、思考这些盲点:这篇文章迫使你走出你的思维定式,重新审视你的想法。我相信,很多成功的团队都是一步步从那些方法和实践集中提取部分内容,组成自己的方法,从而构建一支高效的团队。
活动推荐:
2023年9月3-5日,「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题,策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229(微信同手机号)。
评论