不同领域有不同的方法？
（这个问题的部分灵感来自于 Donald Knuth 对极限编程的贬低 此处）
我最近一直在阅读有关敏捷的内容，并且对极限编程感兴趣已有好几年了。但我想知道这些方法在某些“极端”问题空间中是否合适 - 例如 航天飞机。
你怎么认为？某些领域是否本质上与“现代”方法不兼容？是否有一个明确的指标来将给定领域映射到最佳方法？
(This question was partly inspired by Donald Knuth's put-down of Extreme Programming here)
I've been reading up on Agile recently, and been interested in Extreme Programming for several years now. But I got to wondering about how appropriate these methdologies might be in certain 'extreme' problem-spaces - for example coding for space shuttles.
What do you think? Are some domains inherently incompatible with 'modern' methodologies? Is there a clear metric for mapping a given domain to the best methodology?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一句话，不，没有。不适用于每个域。
某些领域/应用程序更适合非常严格的缺陷控制和测试（这可能非常昂贵），并且成本必须合理（例如，生命攸关）——其中包括医疗设备、航天飞机和军事设备等。
许多其他领域/应用程序无法证明此类费用合理。
即使在单个域内，您也会找到不同的答案（航天飞机本身的操作计算机与宇航员随身携带的笔记本电脑）。
像往常一样，对于这样的问题，答案是“这取决于”……涉及太多因素，无法在每个领域给出通用答案。
In a word, no there isn't. Not for every domain.
Some domains/applications are better suited for very strict defect controls and testing (which can be very expensive), and the cost has to be justified (life at stake, for example) - these include medical devices, space shuttles and military equipment amongst others.
Many other domains/applications cannot justify such expenses.
Even within a single domain you will find different answers (the operational computers in the space shuttle itself versus the laptops that astronauts take with them).
As usual with a question like this, the answer is "It depends"... too many factors are at stake to give a general answer on each domain.
我曾与帮助规划太空任务的人进行过交谈，例如卡西尼号和火星漫游车。每一行代码都经过整个团队的检查。敏捷开发实践都是以迭代循环的方式进行的。在每个周期结束时，产品所有者从积压日志中选择他们想要查看的下一个模块，或者他们可能会插入一些全新的内容。在不允许出错的关键系统中，系统的所有必要功能和规则都在相当早的时候就明确设置了。这意味着敏捷实践可能不适合。
I have spoken with people who have helped program Space Missions, like Cassini, and the Mars rovers. Each and every line of code is inspected by the whole team. Agile development practices all work as iterative cycles. At the end of each cycle, product owners choose the next module they want to see next from back log, or they may insert something brand new. In critical systems where there is no room for error, all the necessary functionality and rules of the system are clearly set fairly early. This means agile practices probably won't be suitable.
我认为许多人对他们使用的方法感到满意，并且对新的方法不感兴趣。即使对于极端的问题空间，TDD 和其他敏捷实践也有明显的好处。显然，像这样的空间必须涉及大量测试，特别是与任务关键型应用程序相比。
无论您的领域如何，前期设计往往会出现巨大的失败，并且在开发过程中会发生重大变化。在我看来，引入敏捷实践（甚至可能是混合或瀑布式和敏捷）肯定是有益的。
I think that many people are comfortable with the methodologies that they use and are closed off to newer methodologies. Even for extreme problem spaces, there are clear benefits to TDD and other Agile practices. There clearly must be a significant amount of testing involved in spaces like this, especially compared to less mission critical apps.
Regardless of your domain, up front designs tend to be massive failures that will change significantly during development. Bringing in Agile practices (maybe even a hybrid or Waterfall and Agile) would certainly beneficial in my mind.
就像为工作使用正确的工具一样，我说为工作使用正确的方法。没有普遍正确的答案/范式/工具/等等……所有这些都必须放在上下文中。
Like using the right tool for the job I say use the right methodology for the job. There are no generally right answers/paradigms/tools/etc... all must be put in context.