Dan North谈误导的艺术
jopen 12年前
Dan North 最近发表文章《 <a href="/misc/goto?guid=4958348797869391140">误导的艺术</a>》，着重讨论了 <a href="/misc/goto?guid=4958348798678009022">机会成本</a>的影响。机会成本通俗地来说是指你针对某个情况作出来一个选择，然而有时候，可能还有一个更好的选择被放弃了。特别对于软件工程师而言，机会成本是个不得不说的故事，毕竟在每天的工作中，他们需要不断做出各种决定。 <p> Dan 认为，软件工程师在工作中总是面临着很高的机会成本。为了证明他的观点，他提议做一个试验：</p> <blockquote> <p>试一下这个试验：想一个你在开发软件的时候会用到的技术或者实践，或者就那个你最喜欢的实践吧，容易吧？好吧，第一步：你为什么用它？有什么好处呢？可能你想到了一些答案，那么就先写下来。现在，第二步：如果你不用那个技术或者实践，有哪些别的可供选择的方案吗？也请写下来，并且列出每一个的优缺点。</p> </blockquote> <p> Dan 以那个在他看来是他遇到过的最被盲目推崇的实践之一：TDD (<a href="/misc/goto?guid=4958348799478951636" target="_blank">测试驱动开发</a>)为例进行了阐述。</p> <p> Dan 认为，倡导 TDD 的那些理由，诸如为了系统稳定和应对变化，涌现式设计，自动化测试以及测试即文档等，背后也有着机会成本。比如，对于财务交易系统那一块而言，使用一些草图来理解系统可能会很有用，而不需要可能会导致很高成本的 TDD 了。至于涌现式设计，TDD 就像在查找最大值，然而寻找最佳的解决方案可能需要彻底的重新思考。而测试即文档则说不定会导致很多不必要的不同声音，反而让人搞不清真正有用的文档在哪里。</p> <p> Dan 最后总结了他的文章并且建议：</p> <blockquote> 所以不要被表面利益所迷惑，在你做每个决定的时候，都要好好权衡机会成本，因为不管你看得到还是看不到，机会成本都在那里，不多不少。但如果你能学会识别这些，你也能更上一层楼。 </blockquote> <p> 有些读者同意 Dan 的观点。<a href="/misc/goto?guid=4958348800277311968">Gene Hughson</a> 解释道：</p> <blockquote> <p>很棒的文章。尝试任何事情，不管是新技术还是技巧，如果不去考虑成本和收益，那么将是个灾难。</p> </blockquote> <p> 然而，也有些读者有着不同的意见。比如，Sam Weisen 就在他的评论中提到，Dan 的文章这样去讨论 TDD 是有失公允的。</p> <blockquote> <p>我恐怕不得不说，你误解了 TDD，你对 TDD 的攻击是毫无意义的。你的有些观点可能不错，但淹没在你的长篇大论之中。</p> </blockquote> <p> <a href="/misc/goto?guid=4958348801074614427">Liz Keogh</a> 则支持 Dan 的观点和提议，他觉得敏捷开发的信徒们应该更加开发地去聆听别的意见：</p> <blockquote> <p>我发现评论中的很多人都犯了“不是真正的苏格兰人（No True Scotsman）”的谬误，也就是说如果某个事物对某人不起作用，那么一定是那个人用错了。我在一些敏捷博客中也都发现过这种情况，特别是提到 TDD 和 Scrum 的时候。其实很多情况下，TDD 并不是最合适的选择，比如统计工时的程序、修改一个紧急的产品缺陷。当然也有不少情况，TDD 还是比较合适的，但也不是最佳选择之一。</p> </blockquote> <p> 看来很难让每一个人都赞同 Dan 的观点，特别是有关于 TDD 的，那么也可以此为契机从另一个角度来审视这个问题。<a href="/misc/goto?guid=4958348801876334085">Justin</a> 就提到：</p> <blockquote> <p>谢谢你让我们看到、思考这些盲点：这篇文章迫使你走出你的思维定式，重新审视你的想法。我相信，很多成功的团队都是一步步从那些方法和实践集中提取部分内容，组成自己的方法，从而构建一支高效的团队。</p> </blockquote> <p> 查看英文原文：<a href="/misc/goto?guid=4958348802680340874">Dan North Discusses The Art Of Misdirection</a></p>