软件开发最难的不是编码，而是需求，你认同吗？

【编者按】文章主要讨论了在软件开发过程中，编码并不是最困难的部分，而是需求的定义。作者通过自己的经验和例子，强调了需求的不明确、不一致或错误是导致软件问题的主要原因。文章还讨论了人工智能在软件开发中的应用，指出虽然 AI 在某些领域（如棋类游戏）已经取得了很大的成功，但在软件开发中，由于需求的复杂性和不确定性，AI的应用还面临很大的挑战。作者认为，人工智能可能最适合重写已经存在的软件，但对于新的、复杂的需求，人工智能还无法替代人类。

原文链接：https://stackoverflow.blog/2023/06/26/the-hardest-part-of-building-software-is-not-coding-its-requirements/

未经允许，禁止转载！

作者 | Jared Toporek       译者 | 明明如月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

图源：stackoverflow

随着各种有关 AI 发展的热门文章大量涌现，我们这些软件开发者深感担忧，担心不久的将来就会被 AI 取代，失去工作。有些人想象商务高管和产品经理将绕过大多数或所有的软件开发者，直接要求 AI 按他们的需要创建他们想要的东西。作为一个已经花了 15 年时间根据这些人提供的规格来创建软件的人，我很难对所有的担忧认真对待。

编程虽然需要一定的基础，但学起来也并没有想象的那么难。一旦你掌握了语法、逻辑和技术，大多数时候你就可以按部就班编写代码了。真正困难和复杂的问题通常涉及到软件应该满足什么样的需求，以及如何设计出优雅和高性能的方案。创建软件最困难的部分并不是编写代码，而是创造需求、分析需求，而且这些软件需求仍然需要由人类定义。

本文将讨论需求和软件之间的关系，以及如果 AI 要替代人类的软件开发者，它需要具备什么样的能力或条件。

这不是 bug，这是 feature…等等，这是 bug

在我软件职业生涯的早期，我主动接受了一个项目的任务，并加入了团队，以帮助提高团队的工作效率。该软件的主要功能是在电子商务网站上提供定制产品的配置服务。我被分配了生成动态的条款和条件的任务。条款和条件中包含的表述不仅依赖于购买的产品类型，还要根据客户所在的美国州的法律要求进行调整。在开发过程中，我认为我发现了一个可能的缺陷。用户会选择一种产品类型，这会生成相应的条款和条件，但在工作流的后续过程中，软件会允许用户选择不同的产品类型和预定义的条款和条件。这将违反商业需求中规定的一个特性，该需求已得到客户的书面确认。我诚恳地问客户，“我应该删除允许用户覆盖正确条款和条件的选项吗？”我清楚地记得他的回答。他肯定地说道：“那永远不会发生”。

这位高级执行官在公司工作了多年，了解公司的业务流程，并且主动承担了监督这个软件的责任。我作为一个新人，怎么能质疑任何人，尤其是这是一家付钱让我们为其构建产品的公司的高级执行官呢？我有些疑惑地摇了摇头，但也没有多想这件事。

几个月后，就在软件即将上线的几周前，客户方的一个测试员发现了一个缺陷，并把它指派给了我。当我看到这个缺陷的详细情况时，我苦笑了一下。

我之前对覆盖默认条款和条件的担忧，我被告知永远不会发生的事情，猜猜发生了什么？猜猜谁为此负责，谁被要求修复它？

修复这个问题相对简单，而且“bug”的影响较小，但这种经历在我开发软件的职业生涯中一直反复出现。我与很多软件工程师交谈过，知道我并不是唯一一个遇到这种情况的人。问题变得越来越大，更难修复，从而导致成本也更高，但问题的源头通常是一样的：需求不明确、不一致或错误。

想要用 AI  取代程序员，客户需要准去额描述他们想要什么。目前还做不到，我们还是安全的。

当前的人工智能：棋盘游戏与自动驾驶汽车

尽管人工智能的概念已经存在很长一段时间，但最近引人瞩目的成就也引发了媒体，甚至过会的高度关注。人工智能在某些领域已经取得了巨大成功，第一个让人想到的就是棋类游戏。早在1980年代，人工智能就开始应用于棋类游戏中。公认的是，人工智能已经超越了人类在棋盘上的水平。这并不令人惊讶，因为棋类游戏的变量是有限的（但是游戏还未被完全解决）。

棋盘游戏总是从 32 个棋子在 64 个格子上开始，有公认的明确的规则，最重要的是有明确的目标。在每一轮中，有有限的可能着法。下棋就是遵循规则系统。人工智能系统可以计算每一步的后果，选择最有可能俘获对手棋子、占领优势地位，最终获胜的走法。还有另一个人工智能非常活跃的领域 —— 自动驾驶汽车。制造商们一直承诺着自动驾驶汽车的推出。有些汽车有自动驾驶能力，但也有限制条件。在许多情况下，汽车需要持续监控；驾驶员可能需要双手握住方向盘，自动驾驶功能并不是完全自主的。

就像玩棋的人工智能程序一样，自动驾驶汽车在做决定时主要使用基于规则的引擎。不同于棋盘程序，如何在每一种可能的情况下导航的规则并没有明确定义。在一次行程中，驾驶员可能需要做出数千个小判断，比如避开行人、绕过双停车，以及在繁忙的交叉路口转弯。做出正确的判断意味着区别在于安全抵达商场还是被送到医院。

在科技行业，标准是可用性达到99.999%甚至99.9999% —— 一个网站或服务在 99.999%（或99.9999%）的时间内是可用的。达到最低的 99% 的成本并不高，这意味着你的网站或服务一年可以不可用超过三天——87.6 小时。然而每多一个 9，成本就呈指数级增长。当你达到 99.9999%的 时候，你一年只能允许 31.5 秒的停机时间。这需要更多的规划和努力，当然花费也更高。获得首个 99% 可能并不容易，但相比于那最后的微小部分，它在比例上显然更容易也更便宜。

• 一年有 365 X 24 X 60 分钟 = 525,600 分钟

• 99% 可用性 -> 故障 5256 分钟，87.6 小时

• 99.9% 可用性 -> 故障 526 分钟，8.76 小时

• 99.99% 可用性 -> 故障 52 分钟，少于1小时

• 99.999% 可用性 -> 故障 5.2 分钟

• 99.9999% 可用性 -> 故障 0.52 分钟，大约 31.5 秒

人工智能的水平再高，也不可能消除事故和死亡的危险。这些风险和后果每天都在人类驾驶员驾驶汽车的过程中发生。我不知道政府会接受何种程度的事故和死亡率，但我们必须期待自动驾驶汽车至少要比人类驾驶者有更低的事故和死亡率。

之所以难以达到可以接受的安全水平，是因为驾驶汽车涉及的变量比棋类游戏多得多，而且这些变量并不是有限的。最低的 95% 或 99% 可能是可预测的，也容易达到。然而，在最低的 99% 之后还有许多的边缘情况，每一种可能都有一些共性，但每一种都是独一无二的；还有其他由人类驾驶的路上车辆、道路封闭、施工、事故、天气情况，或者在道路被铺设新沥青后，但道路的分隔线还未被画上的情况下驾驶。使你的人工智能系统能够处理和识别那些异常和边缘情况，更重要的是如何避免事故并适当应对，这比较难。每一个边缘情况可能有一些共性，但很少完全相同，这些变量使得人工智能更难确定适当的应对方式。

AI 无法创造软件，只能编写代码

构建和维护软件更像驾驶，而不是下棋。涉及的变量更多，规则基于判断。当你构建软件时，你可能有期望的结果，但它不太可能像棋类游戏那样确定。软件很少完善；功能会被添加，错误会被修复；这是一个持续的过程。然而与软件不同，一旦棋局胜负已定，比赛就结束了。

在软件开发中，我们确实有一个工具可以使我们的软件设计更接近于棋类游戏的严格控制的规则引擎：技术规格。在最佳的情况下，规格说明了预期的用户行为和程序流程。这就是用户进行数字交易的方式：点击这个按钮，创建这个数据结构，运行这个服务。然而，我们往往得不到这样的规格。我们经常被赋予一份清单，上面列出了功能规格的期望，草草画在餐巾纸背面的线框图，以及含糊不清的需求文档，然后被告知要做出最好的判断。

更糟糕的是，需求可能会变更或被忽略。最近我被要求帮助一个团队构建一个能够帮助人们获取关于与 COVID-19相关的健康问题信息的东西。这个应用程序将面向那些没有可靠 WIFI 的地区。该团队希望我能帮助构建一个可以通过 SMS（手机短信）进行调查的应用程序。起初，我对能参与其中感到非常兴奋。

然而，当我开始听到团队描述他们想要的东西时，我意识到这将是一个问题。对于一个零售公司来说，询问你在1-10 的范围内再次在他们的店铺购物的可能性是一回事。但是通过多选问题询问你可能表现出的 COVID 感染症状的多步调查则是另一回事。我从未说不，但我确实提出了在这个过程中可能出现的所有故障点，并希望团队清楚定义我们将如何处理所有问题的方案。我们是否会使用逗号来分隔数字，将每个数字映射到一个答案？如果提交的答案并未映射到给出的任何选项，将会发生什么？

经过所有这些问题，团队达到了同样的结论。我们决定最好还是不要继续进行。信不信由你，我会说这实际上是一个成功的结果。如果在提交的用户数据无效时，所有潜在错误没有明确的解决方案，那么继续进行将更浪费。

使用 AI 来创建软件的想法，是让那些相同的利益相关者直接与计算机对话来创建一个基于 SMS 的调查吗？AI是否会问一些探究性的问题，关于如何处理通过 SMS 收集调查数据可能出现的所有问题？它是否会考虑到我们作为人类在这个过程中可能做错的所有事情，以及如何处理这些失误？

为了从 AI 中生成一个功能完整的软件，你需要知道你想要什么，并能够清楚、准确地定义它。有时，在我开始编写代码之前，我未意识到一些潜在的困难和挑战。在过去的十年中，软件行业从瀑布方模型变为敏捷开发。瀑布方法在编写任何代码之前就准确定义了你想要什么，而敏捷则允许你在过程中进行调整。

许多使用瀑布法的软件项目失败了，因为利益相关者认为他们知道他们想要什么，并认为他们可以准确地描述和记录它。然而，他们在最终产品交付时常常感到极度失望。敏捷软件开发被视为是这一问题的解决方案。AI 或许最适合用于重构我们已有的、但需要使用更新硬件或更现代编程语言进行重写的软件。还有很多机构的软件是用 COBOL 编写的，但学习如何使用它的程序员越来越少。如果你确切知道你想要什么，也许你可以让 AI 比一组人类程序员更快、以更低的成本开发软件。我认为 AI 能够比人类程序员更快地开发软件，但这是建立在有人先搞清楚了软件的功能和需求的基础上的。

尽管瀑布法被亲切地称为“死亡行军(death march)”，AI在使用瀑布法构建软件时可能表现得相当好。在瀑布法中做得糟糕的是谁？是我们自己！软件开发的关键是写代码前的大量工作，而不是把签署的文档交给程序员团队编写代码的部分。人工智能可以把事情做得很出色，但它还不能直接读取你的思想，也不能告诉你应该想要什么。

你是否也认为需求的定义是软件开发中最困难的部分？你有没有遇到过因为需求不明确或错误而导致软件开发出现问题的情况？你是如何解决的？欢迎在评论区分享你的经验和教训。

本文文字及图片出自 CSDN