您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 开发技术 > 正文

构建软件最难的不是编码,而是需求

发表于:2023-07-03 作者:徐杰承 来源:51CTO技术栈

作者 | Jared Toporek

编译 | 徐杰承

最近几个月,关于人工智能的惊人文章在互联网泛滥。这也引发了很多人的担心——软件开发人员可能很快就会失业,被人工智能取代。他们想象所有的企业高管和产品研究人员将绕过大多数或所有的软件开发人员,直接要求人工智能构建他们想要或需要的东西。但作为一个拥有15年一线开发经验的人,我觉得这些担心有点危言耸听。

编码可能是一项挑战,但是我从来没有在写单一任务上花费过太多时间。一旦掌握了语法、逻辑和技术,这在大多数时候是一个非常简单的过程。在软件构建过程中,真正的问题通常集中在软件应该做什么。创建软件最难的部分不是编写代码,而是创建需求,而这些软件需求仍然是由人类定义的。

等等,好像这是个错误

在我职业生涯的早期,为了帮助提高某个团队的研发效率,我被安排中途接手一个项目——软件的主要目的是在电子商务网站上配置定制产品。

我的任务是负责动态的条款和条件。有条件的关键词取决于所购买产品的类型,以及由于法律要求客户所在的地区。

在某种程度上,我认为我发现了一个潜在的缺陷,用户将选择一种产品类型,这将生成适当的条款和条件,但是在工作流中,它将允许用户选择不同的产品类型和预定义的条款和条件,这将违反在有客户签名的业务需求中明确约定的特性之一。

我天真地问客户,“我应该删除允许用户覆盖正确条款和条件的输入吗?”从那以后,我得到的回答就烙在了我的脑海里。他的原话是完全自信地说出来的:“这永远不会发生。”

这是一位在公司工作多年的高级管理人员所说的,他了解公司的业务流程。更何况我有什么资格去质疑他,更别说他是一家付钱给我来制造这种产品的公司的高管了。

几个月后,就在软件上线前几周,客户端的一名测试人员发现了一个缺陷,并将其分配给了我。当我看到缺陷的细节时,我笑出声来。这个Bug正是我所担心的覆盖默认条款和条件的事情,我被告知永远不会发生的问题。

修复相对容易,错误的后果也很低,但这种经历在我的职业生涯建设软件中是一个反复出现的主题。我和大量的软件工程师同事交谈过,知道我并不孤单。问题如果不被发现,就总会变得更大,更难解决,修复成本更高,但是问题的根源通常是相同的:需求不清楚,不一致,或者是错误的。

图片图片

2、人工智能:国际象棋/自动驾驶

人工智能的概念已经存在了很长一段时间近来高调的进步也引起了媒体的关注。我们可以说的是,人工智能在某些领域已经非常成功了。

早在20世纪80年代,人工智能就已经被应用于国际象棋。人们普遍认为,人工智能已经超过了人类在国际象棋中的能力。这不奇怪,因为国际象棋的参数是有限的)。

国际象棋总是从64个方格上的32个棋子开始,有很好的记录和官方认可的规则,最重要的是有明确的目标。下棋只是遵循一个规则引擎。人工智能系统可以计算每一步棋的影响,以选择最有可能的结果来击败对手的棋子或获得位置,并最取胜。

人工智能一直非常活跃的另一个领域是自动驾驶汽车,制造商承诺自动驾驶汽车已经有一段时间了。但在绝大部分情况下,汽车仍需要主动监督;驾驶员可能需要将手放在方向盘上,自动驾驶功能目前仍然不是自主的。

像下棋的人工智能程序一样,自动驾驶汽车在很大程度上也使用基于规则的引擎做决定。与国际象棋程序不同,如何在每种可能的情况下导航的规则没有明确定义。在给定的行程中,司机会做出成千上万个小判断,比如避开行人、绕开并排停放的汽车、在繁忙的十字路口转弯。做出正确的判断意味着你最终会到达商场还是到达医院。

在技术上,网站或服务的标准是5—6个9,也就是在99.999%(或99.9999%)的时间内可用。实现前99%的成本并不算高。这意味着你的网站或服务一年中可能会有三天(87.6小时)的停机时间。然而,每增加一个9,实现的成本就会指数级增长。当你达到99.9999%时,一年只能允许31.5秒的停机时间。它需要更多的计划和努力,当然也更昂贵。获得前99%可能不容易,但按比例来说,这比最后那一小部分要容易得多,也便宜得多。

无论自动驾驶离足够好有多近,总有发生事故的风险。人类开车时,这些风险也会每天发生。我不知道政府可以接受的事故率和死亡率是多少,但自动驾驶想要实现大范围普及,它至少要和人类做得一样好。

之所以如此难以达到可接受的安全水平,是因为驾驶汽车比下棋需要更多的变量,而这些变量是无限的。前95%或99%可能是可预测的,也很容易解释。然而,在那第之后有如此多的边缘案例,并且每一个都可能是独特的;道路上其他人驾驶的其他车辆、道路封闭、施工、事故、天气事件等等。

让人工智能模型解释和识别这些异常和边缘情况明显更难,更重要的是如何在不发生事故的情况下做出适当的反应。每个边缘案例可能共享一些特征,但它们很少相同,这使得人工智能更难确定适当的应对方式。

3、AI不能创造软件,只能创造代码  

相比于下棋,创建和维护软件与开车的逻辑更加接近,涉及的变量很多。当你在构建软件时,你可能会有一个期望的结果,但它不太可能像国际象棋一样单一。软件总会面临功能增加与错误修复,这是一个持续的过程。这并不像下棋,一旦赢了或输了就结束了。

在软件开发中,我们确实有一个工具可以让我们的软件设计更接近严格控制的国际象棋规则引擎:技术规范。在最好的情况下,规范会遍历预期的用户行为和程序流。用户是这样购买产品的:点击这个按钮,创建这个数据结构,运行这个服务。然而太多时候,我们得到的需求清单是功能规格、架构图和不清楚的需求文档,并被告知要在此基础上做好判断。

更糟糕的是,需求常常会发生变化或者被忽略。最近,我被要求构建一个可以让用户通过做有关自己身体感觉的选择题来判断是否感染新冠的功能。该应用程序将用于全球没有可靠WIFI的地区。团队希望我帮助构建一个可以通过SMS(手机短信)进行调查的应用程序。

起初我对此很感兴趣,但当我听到团队描述他们想要什么时,我意识到这将是一个问题。对于零售公司来说,以1-10为标准询问您再次光顾他们商店的可能性是一回事,这与用多项选择题询问关于用户感染新冠时的症状的多步调查是非常不同的。我提出了这个过程中所有可能的失败点,并希望团队明确定义我们将如何处理所有问题的答案。

在明确所有这些问题之后,团队得出了相同的结论——我们决定暂时放弃这项功能,这实际上是一个成功的结果。如果在提交无效用户数据时没有明确解决所有潜在的问题,那将造成是更大的浪费。

使用人工智能创建软件背后的想法是让这些利益相关者直接与计算机对话来创建基于SMS的调查,但AI并不会问一些试探性的问题,比如如何处理通过短信收集调查数据时可能出现的问题,它无法解释人类可能会做错的事情,也不知道该如何处理这些失误。

为了利用人工智能构建一个功能性的软件,你需要知道你想要什么,并且能够清楚准确地定义它。尽管有时候我只是为自己写软件,但往往直到我真正开始写代码时,我才意识到其中的困难和挑战。

4、瀑布vs敏捷,AI做不到的事

在过去的十年中,软件行业已经从瀑布方法过渡到了敏捷。瀑布在编写任何代码之前会准确定义你想要的内容,而敏捷则提供了足够的灵活性,因此开发者可以在编写过程中进行调整。

但是事实,很多使用瀑布的软件项目都失败了,因为领导者认为他们知道他们想要什么,并认为他们可以准确地描述它并记录它,但是当最终产品交付时却并不是这样。最终,敏捷软件开发模式成为了这个问题的解毒剂。

人工智能最适合做的,可能是用更成熟的语言重写我们已经拥有的软件。目前仍然有很多机构使用非常古老的软件,而这些软件通常是由非常古老的语言所构建的,但是学习如何使用它们的程序员越来越少,这会是将来人工智能的一大优势。如果你确切地知道你想要什么,也许你可以让人工智能比人类程序员更快更便宜地生产软件。我相信人工智能可以创造出比人类程序员更快的软件,但那是因为有人在这个过程中发现了软件应该做什么。

人工智能实际上在使用瀑布方式构建软件方面做得更好,而人类通常并不擅长于此。但开发一款成功软件的流程并不单单是将文档交给一个研发团队,然后由他们完全按照文档进行编码。人工智能可以做一些非凡的事情,但它不能读懂你的思想,也不能告诉你你到底应该做些什么。

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