出品| csdn (ID: csdnnews)
来源:stackoverflow
随着各种关于AI发展的热门文章的出现，我们软件开发人员深深担心自己在不久的将来会被AI取代，丢掉饭碗。有人设想，企业高管和产品经理会绕过大部分或者全部软件开发者，直接让AI根据需求创造出他们想要的东西。作为一个花了15年时间按照这些人提供的规范来创作软件的人，我很难认真对待我所有的顾虑。
虽然编程需要一定的基础，但是学起来并没有那么难。一旦你掌握了语法、逻辑和技术，大部分时间你就可以按部就班地写代码了。真正困难和复杂的问题通常涉及软件应该满足什么样的需求，以及如何设计优雅和高性能的解决方案。创建软件最难的部分不是写代码，而是创建和分析需求，而这些软件需求仍然需要由人类来定义。
本文将讨论需求与软件的关系，以及AI如果要取代人类软件开发人员，需要具备哪些能力或条件。
这不是一个bug，这是一个特性...等等，这是个bug。
在我软件生涯的早期，我主动接受了一个项目的任务，加入了团队，帮助提高团队的工作效率。这款软件的主要功能是在电子商务网站上提供定制的产品配置服务。我被分配了生成动态条款和条件的任务。条款和条件中包含的表述不仅取决于所购买的产品类型，还会根据客户所在的美国州的法律要求进行调整。在开发过程中，我想我发现了一个可能的漏洞。用户将选择一个产品类型，这将生成相应的条款和条件，但在工作流的后续过程中，软件将允许用户选择不同的产品类型和预定义的条款和条件。这将违反业务需求中规定的特征，该特征已经由客户书面确认。我真诚地问客户，“我应该删除允许用户覆盖正确条款和条件的选项吗？”我清楚地记得他的回答。“那永远不会发生，”他肯定地说。
高管在公司工作多年，了解公司业务流程，主动监督软件。作为一个新人，我怎么能质疑任何人，尤其是一家付钱给我们为其打造产品的公司的高管？我有些疑惑地摇了摇头，但也没多想。
几个月后，就在软件即将上线的前几周，客户端的一个测试人员发现了一个缺陷，把它分配给了我。看到这个缺陷的细节，我苦笑了一下。
我担心覆盖默认条款和条件，我被告知这永远不会发生。猜猜发生了什么？猜猜这是谁的责任，让谁来修？
修复这个问题相对简单，“bug”的影响也小，但这种经历在我开发软件的生涯中不断重复。我和很多软件工程师聊过，知道我不是唯一遇到这种情况的人。问题越来越大，越来越难修复，导致成本更高，但问题的来源通常是一样的:不清楚、不一致或错误的需求。
用AI取代程序员，客户需要准确描述自己想要什么。我们还做不到。我们还是安全的。
当前的人工智能:棋盘游戏和自动驾驶汽车
虽然人工智能的概念由来已久，但最近的显著成就也引起了媒体甚至大会的关注。人工智能在一些领域取得了巨大的成功，首先想到的就是桌游。早在20世纪80年代，人工智能就开始在桌游中使用。公认人工智能已经超越了人类在棋盘上的水平。这并不奇怪，因为桌游的变数是有限的(但游戏还没有完全解决)。
棋盘游戏总是从64个方格上的32个棋子开始。有公认的明确规则，最重要的是明确目标。在每一轮中，可能性都是有限的。下棋是遵循规则体系的。人工智能系统可以计算每一步的后果，选择最有可能捕捉到对手棋子的一步棋，占据优势地位，最终获胜。还有一个人工智能非常活跃的领域——自动驾驶汽车。制造商一直承诺推出自动驾驶汽车。有些车有自动驾驶的能力，但也有限制。很多情况下，汽车需要持续监控；驾驶员可能需要双手握住方向盘，自动驾驶功能并不是完全自主的。
就像人工智能程序下棋一样，自动驾驶汽车在决策时主要使用基于规则的引擎。与棋盘程序不同，如何在每种可能的情况下导航的规则没有明确定义。在一次旅行中，司机可能需要做出成千上万个小判断，比如避开行人、绕过双停车、在繁忙的十字路口转弯。做出正确的判断，意味着区别在于安全到达商场还是被送往医院。
在技术行业，标准是99.999%甚至99.9999%的可用性——一个网站或服务在99.999%(或99.9999%)的时间内可用。99%的最低成本并不高，也就是说你的网站或服务可以不可用三天以上——一年87.6小时。但是，每多一个9，成本就成倍增加。当你达到99.9999%时，一年只能允许31.5秒的停机时间。这需要更多的规划和努力，当然也需要更多的成本。拿到前99%可能不容易，但从比例上来说，显然比最后那微小的一部分要容易和便宜。
一年有365 X 24 X 60分钟= 525600分钟。
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不会造软件，只会写代码。
构建和维护软件更像是开车，而不是下棋。涉及的变量更多，规则基于判断。当你构建软件的时候，你可能已经预料到了结果，但它不太可能像棋盘游戏那样确定。软件很少是完美的；将添加功能并修复错误；这是一个持续的过程。但是，和软件不同，游戏一旦决定，游戏就结束了。
在软件开发中，我们确实有一个工具可以让我们的软件设计更接近于桌游严格控制的规则引擎:技术规范。在最好的情况下，规范描述了预期的用户行为和程序流程。这是用户进行数字交易的方式:单击此按钮创建此数据结构并运行此服务。但是，我们往往得不到这样的规格。我们经常被给予一个功能规格的期望列表，在餐巾纸背面勾画的线框，以及模糊的需求文档，然后被告知做出最好的判断。
更糟糕的是，需求可能会改变或者被忽略。最近，我被要求帮助一个团队建立一些东西，可以帮助人们获得与新冠肺炎相关的健康问题的信息。这款应用将针对没有可靠WIFI的地区。该团队希望我帮助构建一个可以通过SMS进行调查的应用程序。起初，我非常兴奋能参与其中。
然而，当我开始听到团队描述他们想要什么时，我意识到这将是一个问题。对于一个零售公司来说，在1-10的范围内问你在他们店里再次购物的可能性是一回事。但是用选择题问你COVID感染的症状就是另一回事了。我从来没有说不，但我确实提出了这个过程中所有可能的失败点，我希望团队明确我们将如何处理所有的问题。我们是否使用逗号分隔数字，并将每个数字映射到一个答案？如果提交的答案与给定的任何选项都不对应，会发生什么情况？
在所有这些问题之后，团队得出了相同的结论。我们决定最好不要继续。信不信由你，我要说这其实是一个成功的结果。如果在提交的用户数据无效时，对所有潜在的错误都没有明确的解决方案，继续下去会更浪费。
使用人工智能创建软件的想法是让这些利益相关者直接与计算机对话，以创建基于短信的调查？AI会不会问一些探索性的问题，关于如何处理所有通过短信收集调查数据可能出现的问题？会不会考虑到我们作为人类在这个过程中可能做错的所有事情，以及如何处理这些错误？
为了从人工智能中生成一个全功能的软件，你需要知道你想要什么，并且能够清晰准确地定义它。有时候，在我开始编码之前，我没有意识到一些潜在的困难和挑战。在过去的十年中，软件行业已经从瀑布模型转变为敏捷开发。瀑布式方法在编写任何代码之前准确地定义了您想要的内容，而敏捷允许您在这个过程中进行调整。
许多使用瀑布方法的软件项目失败了，因为涉众认为他们知道他们想要什么，并且他们能够准确地描述和记录它。然而，当最终产品交付时，他们通常会感到极度失望。敏捷软件开发被认为是解决这一问题的方法。AI可能是最适合重建我们现有软件的，但它需要用更新的硬件或更现代的编程语言来重写。有许多组织的软件是用COBOL编写的，但是越来越少的程序员学会如何使用它。如果你确切地知道你想要什么，也许你可以让AI比一群人类程序员更快、更低成本地开发软件。我认为AI可以比人类程序员更快地开发软件，但这是建立在有人先搞清楚软件的功能和需求的基础上的。
虽然瀑布法被亲切地称为“死亡行军”，但AI在使用瀑布法构建软件时可能表现得相当不错。瀑布法中谁做的不好？是我们自己！软件开发的关键是写代码前的大量工作，而不是把签好的文档交给程序员团队写代码。人工智能可以把事情做好，但是它不能直接读懂你的想法，也不能告诉你你应该想要什么。
你是否也认为需求的定义是软件开发中最难的部分？你在软件开发中遇到过因为需求不明确或者错误而导致的问题吗？你是怎么解决的？欢迎在评论区分享你的经验和教训。"