小型软件团队已经不复存在

Uber 因运行数千个微服务而臭名昭著。他们最终获得了如此多的服务，因为数百名工程师希望按照自己的时间表进行部署，并明确其代码的所有权，而不是在一个巨大的合并队列中等待。几十年来，一个 5 到 10 人同时编写代码的小团队甚至不需要考虑这样做。在忙碌的一天，一个小团队可能会生成 50 个提交/20 个推送/10 个 PR。如今，并行运行 20-100 个代理的小团队可能会生成 500 次提交/200 次推送/100 个 PR。因此，Uber 的模块化方法在当时看来可能有些极端，但它可能会成为新常态。一名开发人员以“单线程”方式编码，一次编辑一个文件： 一名开发人员以“多线程”方式编码，并行使用编码代理：如果您有一个大型整体服务，其中每个更改都必须仔细协调，那么很可能两项重要工作将相互践踏，并迫使您解决合并冲突和重构。如果你有数千个像 Uber 这样的微服务，那么你就会有一种“令人尴尬的并行”的代码工作方式。为每个代理启动一个编码代理，告诉它“提高性能”，那么您很有可能在所有代理上实现重大改进。并行运行的 100 多个编码代理必须能够独立良好地工作。如果他们把所有时间都花在解决合并冲突、修复损坏的构建以及制造部署噩梦上，那么您最终可能会出现净负生产力。过去，拆分事物的成本非常高，因为每项服务都意味着更多的样板文件、管道和 CI 配置。现在所有这些都由代理编写，因此开销的影响要小得多。代理也受到上下文的极大限制。足够小以适合上下文窗口的模块（无论是服务还是库）可以显着提高编码代理的性能。代码库的模块化决定了您可以有效并行运行多少个编码代理，因此现在值得从一开始就对其进行设计。