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就提到:
谢谢你让我们看到、思考这些盲点:这篇文章迫使你走出你的思维定式,重新审视你的想法。我相信,很多成功的团队都是一步步从那些方法和实践集中提取部分内容,组成自己的方法,从而构建一支高效的团队。