代码库翻倍如何创造出完全不同的工程挑战——以及为什么大多数团队对这种转变毫无准备。
当我开始我最近的创业项目时,我和我的联合创始人开始构建我们的 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)变得至关重要
- 大型状态树需要更好的组织
核心洞见是:为你所处的当前阶段进行优化,而不是为你想象中的未来。
为过渡做准备(我们现在在做什么)
最聪明的团队会在撞墙之前为复杂性的过渡做好准备:
我们目前的投入:
- - 现在把这个做好,以后可以节省数月的时间
