软件工程是关于管理复杂性

人工智能正在使人们对软件工程产生越来越明显的误解：我们倾向于将编写代码与构建软件混为一谈。在某些方面有一些重叠，但它们不是同一件事。编写代码意味着将想法转化为计算机可以执行的指令。构建软件意味着首先决定哪些指令应该存在，它们应该如何交互，哪些约束很重要，决策的成本是多少，哪些权衡可以被认为是可接受的，以及最终的系统如何能够在自身的约束和限制下不断发展而不会崩溃。让我们从一个基本前提开始：人工智能是一个重要的工具，因为它非常擅长解决第一个问题。第二个是软件工程真正开始的地方。困难的部分从来不是输入代码考虑一个相对普通的工程需求。我们需要处理传入的事件并更新一些数据。这些是技术讨论期间出现的一些首要问题：我们应该同步处理它们吗？我们应该将它们放入队列吗？我们是否需要精确一次处理，或者至少一次就足够了？系统能够容忍最终一致性吗？处理中途失败怎么办？我们应该重试吗？多少次？如果消费者三个小时没能联系到，会发生什么？事件需要保留顺序吗？我们预计今天的流量有多少？两年后呢？如果一个事件被处理两次会产生什么后果？ … 等等。这些问题与语法关系不大。编程语言的选择很重要，因为它会影响团队的流畅性、团队的绩效、系统的性能、安全性、可维护性、工具和操作特性，但它并不能回答根本问题。困难的部分是选择代表正确的妥协集的架构。而且很少有一个普遍正确的答案。 1 个问题可以有 N 个完全不同的正确解决方案，当软件存在于企业内部时，这一点尤其明显。想象一下，两家公司要求他们的工程团队构建听起来完全相同的功能。他们的要求在纸面上可能看起来相同。但是：A公司有500个用户，B公司有2000万用户。 A 公司可能有三名工程师维护系统。 B 公司可能有 200 个。可能需要很强的一致性，因为错误会带来严重的财务后果。另一个可能会高兴地接受最终的一致性以换取可用性和吞吐量。一家公司可能需要在三周内发货。另一些人可能期望该系统能够保持运行十五年。人们可能已经拥有 Kafka、Kubernetes、PostgreSQL、可观察性基础设施以及具有分布式系统经验的工程师。另一种可能有一个应用程序服务器和一个由四名开发人员维护的 PostgreSQL 数据库。对于一家公司来说，技术上令人印象深刻的解决方案对于另一家公司来说可能是一种不负责任的解决方案。这就是为什么架构不能简化为问：实现 X 的最佳方式是什么？正确的问题通常更接近于：考虑到这些限制、这个团队、这个业务、这个基础设施、这个预算、这些风险以及产品的预期演变，今天实施 X 的最合适的方法是什么？这是一个完全不同的问题。人工智能生成解决方案。工程师自己权衡。由于软件组织如何采用人工智能，这种区别变得越来越重要。人工智能对于软件开发非常有用。我们将其用作加速器：生成样板文件、探索 API、提出实现方案、发现潜在错误、解释不熟悉的代码、生成测试、比较方法，或者只是减少将想法转化为工作代码所需的机械工作量。但有一种危险的倾向是将这种能力扩展到更广泛的领域：委托工程判断本身。你可以：给人工智能模型一个要求，并要求它设计系统，“没有错误”：它会设计一个。要求它选择一个数据库：它会选择一个。询问您是否应该引入队列、微服务、缓存、CQRS、事件源、Kubernetes、Redis 或其他抽象：它会给您答案。然而，答案的存在并不意味着根本的工程问题已经得到解决。真正的问题是，正确的决策取决于上下文，通常是大量的上下文，需要数小时、数天甚至数周的时间来分析、理解和评估，通常涉及同一组织内的多个部门，并且经常留下难以正式化的灰色区域，并且在未来需要变革时可能会成为挑战。这就是现实世界的运作方式：文档中存在一些上下文。其中大部分都没有。它存在于与客户的对话中。在产品的历史上。在年代