
生产力决定生产关系,生产关系必须适应生产力的发展水平。 马克思。
传统的生产关系(包括架构分层、角色分工、协作流程)是围绕旧时代的生产力建立起来的。现在,生产力跃迁了,旧的生产关系自然开始失效。
本文尝试从“生产力决定生产关系”的视角,探讨 AI 会如何重塑软件架构(技术结构)和团队协作(组织结构)。当然,本人水平有限,抛砖引玉,欢迎大家讨论。
AI 对软件架构最深刻的影响是如何让 AI 能够以最低的成本来理解代码、理解对代码。长期以来软件架构的演进方向都是“对人类工程师友好”,现在我们需要“对 AI 友好”的结构。从自我经验来尝试给出几个可能的演进方向。
传统的 MVC 、DDD 等分层模型,本质是约束人的行为,防止开发者在屎山随意拉屎,但是传统的分层方式天然对 AI 不友好,同一个领域的代码分布在不同的层级,AI 需要跨层理解大量文件才能理解一个业务。
领域优先( Domain-First )+ 自包含( Self-contained )的组织方式大概率会取代传统分层架构。相对于传统的 DDD ,分层将在领域内部,每个领域都要有完整的业务语义(数据模型、服务逻辑、用例、规则),而不是像传统的 DDD 一样,分层在领域之间。相当于每个领域都是一个小型的 DDD 架构。
这一类工具天然对 AI 不友好,人可以很容易提取出冗余信息中的重点。但是 AI 很难做到,而且用于造成大模型的幻觉。而 AI 的出现让这类工具的原始动机正在消失,AI 可以生成比这些工具更好的代码。这些工具的使用场景完全可以交给 AI 来完成。
现阶段很多大厂的团队压根就没有自动化测试这回事,有一部分中层管理混子压根都不知道测试金字塔是什么东西。更不要说小厂了。当然,一些人才密度比较高的团队还是做的比较好的。归根结底的原因是自动化测试的收益不可量化,在 OKR\KPI 的考核思路下,自动化测试属于善战者无赫赫战功。
而 AI 时代,自动化测试几乎会变成不可或缺,一是因为 AI 可以自动生成测试,成本较低,二是因为 AI 可以通过自动化测试发现自己代码中的问题。AI 可以自我测试、自我修正。这会让自动化测试的优先级大幅提升。就需要相关的基础建设来支撑。三是自动化测试会给 AI 的重构提供安全保障。
程序员比较常说的 “代码就是文档” 在 AI 时代是不生效的,一是会提高 AI 的理解成本,二是 AI 无法从代码中推断“为什么这样设计”,也无法从代码理解业务规则的隐性部分。很多业务逻辑甚至是口口相传的。这就是为啥很多旧项目只能重写,不能重构。
显式知识变得非常关键。未来的代码库中,需要包含:用例( Use Cases )、领域语义( Domain Glossary )、领域规则( Domain Rules )。因为这些是给 AI 看的,人能读懂只是附带好处。AI 自我实现自动化测试并且能够回归,非常依赖这些显性知识。
AI 对协作关系的影响,基本上已经到了技术的奇点,换句话说,现在让前端结合 AI 写普通的 CRUD 逻辑、让后端结合 AI 写普通的页面逻辑,已经差不多是水到渠成的事情。以下讨论一下可能的组织结构变化。
以下内容中 80% 是同一个语义的不同呈现:
全是沟通成本和理解成本,甚至夹杂着各种扯皮。个人觉得 AI 时代,这些会变成: 文档、代码、接口、测试都围绕同一份语义知识库生成。PRD 不再是单独的文档,而是代码库的一部分。所有团队围绕同一个“源头”协作。
传统协作的核心是“阶段隔离”:
这是工业化生产线式的协作方式,本质是因为过去软件开发的瓶颈在于工程师的编码效率。所以整个组织都围绕工程师的产出瓶颈来安排。所有需求都是一步步的走流程。
AI 的出现会让整个协作流程更加的灵活,甚至会带来岗位的合并,前后端不久的将来会合并成一个岗位。而且技术开发甚至可能是前置到需求前(听起来不可思议,但是现在技术架构的设计是不是已经走在需求前面了,AI 时代会有更多开发方面的内容走在前面)。当然,现阶段的此类变动还较少。属于各公司都在探索的阶段。
从瀑布流过渡到 scrum ,本质上也是一种生产力带来的组织结构调整。瀑布流是工业化生产线式的协作方式,最大的问题就是流程很容易失控,容易进入死亡之谷。不太适合互联网高速发展时代需求迭代的节奏。而 scrum 的协作方式现在看起来也不符合 AI 时代的需求。未来可能会有更小的团队粒度。