创建软件*困难的部分并没有想象的那么难

菏泽炫佑科技

创建软件*困难的部分并没有想象的那么难

出品| CSDN（ID：）

图片来源：

随着各种有关AI发展的热门文章纷至沓来，我们这些软件开发者深深担心自己会在不久的将来被AI取代，失去工作。 有人想象，企业高管和产品经理会绕过大多数或所有软件开发人员，直接要求人工智能创造他们想要的东西和他们想要的东西。 作为一个花了 15 年时间根据这些人提供的规范创建软件的人，我很难认真对待所有的问题。

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

本文将讨论需求与软件之间的关系，以及人工智能要取代人类软件开发人员需要具备哪些能力或条件。

这不是一个错误，这是...等等，这是一个错误

在我的软件职业生涯的早期，我自愿承担一个项目的任务，并加入一个团队来帮助提高它的生产力。 该软件的主要功能是为电子商务网站上的定制产品提供配置服务。 我的任务是生成动态条款和条件。 条款和条件中包含的表述不仅取决于所购买产品的类型，还会根据客户所在美国州的法律要求进行调整。 在开发过程中，我想我发现了一个可能的错误。 用户选择产品类型，该类型会生成相应的条款和条件，但在工作流程的后期，软件允许用户选择具有预定义条款和条件的不同产品类型。 这将违反业务需求中指定的功能，该功能已由客户书面确认。 我诚实地问客户：“我应该删除允许用户覆盖正确条款和条件的选项吗？” 我清楚地记得他的回答。 “这永远不会发生，”他肯定地说。

该高级管理人员已在该公司工作多年，了解公司的业务流程，并自愿监督该软件。 作为一个新人，我怎么能质疑任何人，尤其是一家付钱让我们建造东西的公司的高级管理人员？ 我疑惑地摇摇头，但也没有多想。

几个月后，就在软件上线前几周，客户的一位测试人员发现了一个错误并将其分配给我。 当我看到这个缺陷的细节时，我苦笑了。

我之前担心覆盖默认条款和条件，但我被告知永远不会发生这种情况，猜猜发生了什么？ 猜猜谁对此负责，谁被要求解决这个问题？

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

为了用人工智能取代程序员，客户需要能够准确地描述他们想要什么。 我们还不能这么做，我们仍然安全。

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

尽管人工智能的概念早已存在，但近期取得的令人瞩目的成就也引起了媒体甚至会议的高度关注。 人工智能在一些领域取得了巨大成功，**个想到的就是桌游。 早在20世纪80年代，人工智能就开始应用于桌游中。 人们普遍认为，人工智能已经超越了人类在棋盘上的水平。 这并不奇怪，因为棋盘游戏的变量是有限的（但游戏尚未完全解决）。

棋盘游戏总是从 64 个方格上的 32 个棋子开始，有完善的规则，*重要的是，有一个明确的目标。 在每一轮中，可能的移动次数是有限的。 下棋就是要遵循一套规则。 人工智能系统可以计算每一步棋的后果，并选择*有可能吃掉对方棋子、占​​据优势位置、*终获胜的棋步。 人工智能还有一个非常活跃的领域——自动驾驶汽车。 制造商一直承诺推出自动驾驶汽车。 有些汽车有能力自动驾驶，但有局限性。 在许多情况下，汽车需要持续监控； 驾驶员可能需要双手放在方向盘上，并且自动驾驶功能并不是完全自主的。

就像下棋的人工智能程序一样，自动驾驶汽车在做出决策时主要使用基于规则的引擎。 与棋盘程序不同，如何应对每种可能情况的规则并没有明确定义。 在旅途中，驾驶员可能需要做出数千个小判断，例如避开行人、绕过双站以及在繁忙的十字路口转弯。 做出正确的判断可能意味着安全到达购物中心还是被送往医院。

在科技行业，标准是 99.999% 甚至 99.9999% 的可用性——网站或服务在 99.999%（或 99.9999%）的时间内可用。 到达底部 99% 的成本并不高，这意味着您的网站或服务每年可能无法使用三天以上 - 87.6 小时。 然而，每增加 9 个，成本就会呈指数级增加。 当您处于 99.9999% 的状态时，每年只允许您有 31.5 秒的停机时间。 这需要更多的计划和努力，当然成本也更高。 获得前 99% 的部分可能并不容易，但它绝对比*后一小部分更容易、更便宜。

无论人工智能水平有多高，都不可能消除事故和死亡的危险。 当人类驾驶员驾驶汽车时，这些风险和后果每天都会发生。 我不知道政府会接受什么程度的事故和死亡人数，但我们必须期望自动驾驶汽车至少比人类司机的事故和死亡人数要低。

之所以难以达到可接受的安全水平，是因为驾驶汽车涉及的变量比棋盘游戏多得多，而且变量不受限制。 底部的 95% 或 99% 可能是可预测的并且很容易实现。 然而，除了底部的 99% 之外，还有许多边缘情况，每种情况可能都有一些共性，但又都是独特的； 道路上有其他人类驾驶的车辆、道路封闭、施工、事故、天气条件或在道路新铺柏油但尚未涂刷道路隔离线后行驶。 让你的人工智能系统处理和识别这些异常和边缘情况，更重要的是如何避免事故并做出适当的反应，是比较困难的。 每个边缘情况可能都有一些共性，但很少是相同的，这些变量使人工智能更难确定适当的响应。

AI不能创建软件，只能编写代码

构建和维护软件更像是开车而不是下棋。 涉及的变量较多，规则基于判断。 当您构建软件时，您可能会得到期望的结果，但它不太可能像棋盘游戏那样确定。 软件很少是完美的； 添加了功能并修复了错误； 这是一个持续的过程。 然而，与软件不同的是，一旦游戏决定了，游戏就结束了。

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

更糟糕的是，需求可能会改变或被忽略。 *近，我被要求帮助一个团队构建一些东西，帮助人们获取与 COVID-19 相关的健康问题的信息。 该应用程序适用于那些没有可靠 WIFI 的地区。 该团队希望我帮助构建一个可以通过 SMS（手机短信）进行调查的应用程序。 起初，我很高兴能成为其中的一部分。

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

在解决了所有这些问题之后app开发，团队得出了相同的结论。 我们决定*好不要继续。 不管你信不信，我想说这实际上是一个成功的结果。 当提交无效的用户数据时，如果没有明确解决所有潜在错误，继续下去会更加浪费。

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

为了从人工智能生成功能齐全的软件，您需要知道您想要什么创建软件*困难的部分并没有想象的那么难，并能够清晰准确地定义它。 有时，直到开始编码时我才意识到潜在的困难和挑战。 过去十年，软件行业已经从瀑布模型转向敏捷开发。 瀑布式在编写任何代码之前准确定义了您想要的内容，而敏捷则允许您一路进行调整。

许多使用瀑布的软件项目都失败了，因为利益相关者认为他们知道自己想要什么，并且认为他们可以准确地描述和记录它。 然而，当*终产品交付时，他们常常感到非常失望。 敏捷软件开发被视为解决这个问题的方法。 人工智能也许*适合重构我们已有的软件，但需要使用更新的硬件或更现代的编程语言进行重写。 仍然有很多机构的软件是用 COBOL 编写的，但是越来越少的程序员正在学习如何使用它。 如果你确切地知道自己想要什么，也许你可以让人工智能比人类程序员团队更快、成本更低地开发软件。 我认为人工智能将能够比人类程序员更快地开发软件，但前提是有人首先弄清楚软件的用途和需求。

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

您是否也认为需求的定义是软件开发中*困难的部分？ 您是否遇到过因为需求不明确或者错误而导致软件开发出错的情况？ 你是怎么解决的？ 欢迎在评论区分享你的经验教训。

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等