代码库翻倍如何创造出完全不同的工程挑战——以及为什么大多数团队对这种转变毫无准备。
当我开始我最近的创业项目时，我和我的联合创始人开始构建我们的 React Native 应用。我们刚刚达到了 50,000 行代码（LoC），增长到 1,000 日活跃用户（DAU），我发现了一个非常有趣的现象：每当你的代码库规模翻倍，你就会进入一个完全不同的开发阶段。
这不仅仅是代码变多了。它关乎于根本上不同的问题、团队动态和架构决策。以下是我从中学到的，关于支配着创业公司工程的隐藏规模法则。
翻倍定律：每一次 2 倍的增长都是一次阶段性转变
通过我们的历程和研究，我发现了一个清晰的模式：
- 2.5万 → 5万 LoC: 从原型到功能性产品
- 5万 → 10万 LoC: 从产品到可持续的系统
- 10万 → 20万 LoC: 从系统到平台
- 20万 → 40万 LoC: 从平台到企业级架构
- 40万 → 80万 LoC: 从企业级到大规模分布式系统
为什么翻倍会带来阶段性变化：
复杂性不是线性增长的，而是指数级增长的。两倍的代码意味着组件之间潜在的交互大约是四倍。每一次翻倍都会突破人类理解和维护能力的又一个认知边界。
这与康威定律（Conway's Law）、邓巴数（Dunbar's number）和布鲁克斯定律（Brooks' Law）相符——这些社会和技术限制影响着我们构建软件的方式。
第一阶段：5万行代码的现实检验
我们目前正处于我称之为“从产品到可持续系统”的过渡阶段。以下是我们的经历：
痛点：
- 跨组件的状态管理变成了一场噩梦
- 快速原型开发积累的技术债开始反噬
- 性能问题出现（我们花了好几天优化一个阻塞用户的 FlatList）
- “简单”的变更现在会触及多个文件
- 在前端、后端、移动端和基础设施之间不断进行上下文切换
残酷的真相： 在 5万行代码和 2 名工程师的情况下，我们正在触及认知负荷的极限。我们仍然可以勉强将大部分系统装在脑子里，但已经非常吃力了。
下一阶段的挑战：10万行代码之墙
根据研究和与其他工程团队的交流，以下是在下一次代码翻倍时等待着我们的：
架构崩溃的痛苦：
- 单一代码库（Monorepo）变得难以维护
- 服务边界变得模糊
- 数据库成为瓶颈
- 代码所有权的争夺开始
团队协作的地狱：
- 到处都是合并冲突
- 新功能破坏了其他功能
- 知识孤岛正在形成
- 发布协调成为噩梦
残酷的现实是： 大多数团队在代码量达到 7.5 万行左右时就需要第三名工程师，而不是在他们自认为需要的时候。
团队规模的数学（这和你想象的不一样）
我最初认为，当代码量翻倍时，团队规模可能需要扩大 4 倍（遵循复杂性的增长）。但真实的模式更像是每次代码量翻倍，团队规模增长 2-3 倍：
- 5万 → 10万 LoC: 2 → 4-6 名工程师
- 10万 → 20万 LoC: 4-6 → 10-15 名工程师
- 20万 → 40万 LoC: 10-15 → 25-40 名工程师
为什么不是 4 倍： 优秀的工程师会适应，工具有所改进，专业化分工也有帮助。但协调开销是真实存在的——沟通的复杂性是呈二次方增长的。
能够扩展的技术选择（以及不能的）
我们最重要的决定之一是状态管理。在我们目前的阶段，我们选择了 Zustand 而不是 Redux：
Zustand 在 5 万行代码阶段胜出的原因：
- 5-10 分钟的设置时间，而 Redux 需要 30-60 分钟
- 在快速迭代时样板代码更少
- 在架构变更期间更容易重构
- 在 React Native 中性能更好
但当代码量达到 10 万行以上时，Redux 变得更具吸引力：
- 复杂的异步流程占主导地位
- 多名开发者需要既定的模式
- 时间旅行调试（Time travel debugging）变得至关重要
- 大型状态树需要更好的组织
核心洞见是：为你所处的当前阶段进行优化，而不是为你想象中的未来。
为过渡做准备（我们现在在做什么）
最聪明的团队会在撞墙之前为复杂性的过渡做好准备：
我们目前的投入：
- - 现在把这个做好，以后可以节省数月的时间