… 有趣的是，一切旧的又变成新的了。当我刚开始在工业界工作时，我在国防承包商工作，参与了为F-22建造“黑匣子”的项目。当我加入团队时，他们已经进行了一年的规格编写工作，但还没有写出任何代码，他们（我记得大概是）在规格编写上还有另外一年的时间。在我第三份工作中，我发现了一排书架，上面有多个活页夹，详细列出了一个1970年代用某种语言编写的主机发布应用的规格。回顾过去，我意识到敏捷运动，这是对这种我职业生涯初期经历的重型瀑布流程的反动，基本上是试图“感受代码”整体系统设计。至少对我来说，AI辅助的微型瀑布（“增强级联”？）似乎是一条回到生产更高质量软件的道路，而不会受到敏捷“哦，我没考虑到这一点”的困扰。
源讨论自动编程原帖 241 条评论 · 导入时统计把你的经验，加入这段讨论。
瀑布模型在以下情况下可以非常有效：1/ 项目关注长期发展，既包括知道公司可能需要几年时间才能将产品上线，也包括知道公司将在未来很多年里持续存在；2/ 编写规格说明和编写代码的人基本上是同一批人。 敏捷方法主要是为了确保公司在倒闭之前就能推出软件（即第1点），并解决第2点中出现的反模式，即非技术人员的业务人员编写（马马虎虎的）规格说明，然后技术团队被期望完成机械式的实现工作。
完整原文正如生活中经常发生的一样，极端的方法往往并不好。如果你采用纯粹的瀑布模型，可能会在很晚的时候才发现你的计划可能无法实现，这可能是因为实施过程中出现了未预见的技术难题，或者给定的需求实际上有误或不完整，或者只是错过了你计划中足够的时间点。如果你采用极端的敏捷方法，你往往会得到一个糟糕的架构，这实际上会损害你未来的敏捷性，但你却能获得一个可以与现实验证的结果。‘哦，我没想到这一点’在两种极端情况下都会出现。
完整原文我认为编程的未来将是基于规格说明的，因此我想问问你，作为已经以这种方式运作的人，有没有任何公开的规格说明值得学习和推崇？我想到的是，就像上一代人会参考约翰·卡马克的《雷神之锤》代码一样，下一代人也会推崇优秀的规格说明。
完整原文是的。我长期以来一直致力于基于规格说明的开发（当有人员作为执行者的时候），它从未让我失望过。只是我们现在从大语言模型（LLM）那里获得的关注比从人类那里多得多（哈哈！）。
完整原文敏捷方法解决了在环境不断变化时发现可行的需求集的问题。 如果你已经知道所有需求，那就不需要它发挥作用了。
完整原文根据我的经验，这种一次性项目在面对现实时往往无法生存下去。即使有极其详细的需求规格说明，最终结果也不会是人们所期望的，因为人类的思维无法完全预见软件的复杂性以及它需要处理的所有边缘情况。"哦，我没考虑到这个定时警报会非常烦人，我实际上希望另一个警报能覆盖它。我们能构建这个原型真是太好了，因为这在纸上很难预料到。" 我不是说我不相信你的报告——也许你所处的领域一切都是高度确定性的。不管怎样，我不这么认为。
完整原文也许更好的方式不是把它们看作相互替代的选择，而是看作不同的工作模式，有时在这些模式之间切换是有帮助的？ 我们知道传统的瀑布模型缺乏灵活性，而敏捷方法缺乏计划性，但我看不出为什么不能在同一个项目中来回切换多次。
完整原文这不就是"契约式设计"的新名称吗？ https://www.goodreads.com/book/show/15182720-design-by-contr... 只不过使用的是大型语言模型而不是下属团队？ c.f., https://se.inf.ethz.ch/~meyer/publications/old/dbc_chapter.p...
完整原文那么生成的代码看起来是什么样的呢？我发现虽然<插入你最喜欢的LLM>可以快速生成几乎能运行的C++代码，但之后我不得不花10倍的时间去修改它，使其看起来至少有点像样的代码。 不管我怎么告诉它，它在项目或全局配置文件中是一个“专业经验丰富的10倍开发者，精通现代C++，是Stroustrup的第二位到来”，它仍然不断生成同样的垃圾代码，大的（比如在某些地方使用手动内存管理而不是RAII，初始化字段在构造函数体中而不是初始化列表中，类中使用手动初始化/清理方法而不是正确的构造函数/析构函数设计来确保对象始终处于一致状态，以及其他各种反模式），小的（在将指针传递给delete/free之前检查nullptr，手动实例化对象作为shared_ptr构造函数的参数而不是使用其他方式）等等）。 和小的（在将指针传递给delete/free之前检查nullptr，手动实例化对象作为shared_ptr构造函数的参数而不是使用其他方式）等等）。 和小的（在将指针传递给delete/free之前检查nullptr，手动实例化对象作为shared_ptr构造函数的参数而不是使用其他方式）等等）。 …
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。