小软件团队已不复存在

# 再没有小规模软件团队这回事了 来源：https://jacob.gold/posts/theres-no-such-thing-as-a-small-software-team/ 优步运行着数千个微服务早已是众所周知的事（https://www.uber.com/us/en/blog/up-portable-microservices-ready-for-the-cloud/）\。之所以最终形成如此庞大的服务数量，是因为数百名工程师希望按照自己的节奏部署代码，明确所有权，而非在庞大的合并队列中等待\。 几十年来，5到10人规模的小团队同步编码甚至无需考虑这种模式\。在繁忙的工作日，小团队可能产生50次提交/20次推送/10个拉取请求\。而如今的小团队，若同时运行20\-100个智能体，可能产生500次提交/200次推送/100个拉取请求\。 因此优步当时采取的模块化方案看似极端，却可能成为新常态\。 **开发者以"单线程"方式编码，一次编辑一个文件：**单个VS Code窗口打开一个代码库，手工编辑一个文件，同时在终端运行构建命令（https://jacob.gold/images/theres-no-such-thing-as-a-small-software-team-vscode.webp） **开发者以"多线程"方式编码，并行使用编程智能体：**跨多台机器同时运行多个智能体工作空间，并排查看差异列表、任务清单和聊天会话（https://clor.com/） ## 代码模块化程度越高，可并行运行的智能体就越多（https://jacob.gold/posts/theres-no-such-thing-as-a-small-software-team/#the-more-modular-your-code-the-more-agents-you-can-run） 如果你的大型单体服务每次变更都需要精心协调，那么两项重要工作很可能相互冲突，迫使你解决合并冲突并重构代码\。 如果你拥有像优步那样的数千个微服务，就拥有了"天然适合并行"的代码协作方式\。为每个服务启动编程智能体，指示其"提升性能"，很可能在所有服务中实现显著改进\。 100余个并行运行的编程智能体必须具备良好的独立工作能力\。若它们将全部时间消耗在解决合并冲突、修复损坏构建和处理部署难题上，最终可能导致生产力净损失\。 ## 模块化的成本已大幅降低（https://jacob.gold/posts/theres-no-such-thing-as-a-small-software-team/#modularity-got-cheap） 过去拆分服务成本极高，因为每个服务都意味着更多样板代码、管道配置和CI设置\。如今智能体可自动生成这些内容，因此开销已大幅降低\。 智能体的上下文感知能力也极为有限\。当模块（无论是服务还是库）规模小到能完全装入上下文窗口时，编程智能体的性能将显著提升\。 代码库的模块化程度决定了可并行有效运行的编程智能体数量，因此现在值得从架构设计阶段就考虑模块化\。