创业公司工程中隐藏的规模法则：我从2个月写5万行代码中学到的事

写在前面：本文成文于 2025 年 5 月，文中的判断和数字只对应当时的模型能力。此后模型迭代很快，有些结论现在已经不再适用，权当一份彼时的记录来读。

代码库变大以后，问题不是“更多代码”这么简单。

最近这个创业项目做到 5 万行代码左右时，我开始明显感觉到一件事：代码库不是线性变大的。

我和联合创始人在做一个 React Native 应用，当时大概 1,000 DAU。数字看起来不大，团队也只有两个人，但系统已经开始有了另一种重量。

一个以前十分钟能改完的东西，现在要先想：这个状态在哪里被复用？会不会影响另一个页面？缓存有没有同步？移动端生命周期会不会有坑？发布后要看哪条路径？

我不确定这算不算严格的“定律”。但至少在我的项目里，每一次代码规模翻倍，都不像是同一阶段的延长，更像换了一种游戏。

我开始用翻倍来理解阶段变化

我现在大致这样看代码规模：

• 2.5万 → 5万 LoC: 从原型到功能性产品
• 5万 → 10万 LoC: 从产品到可持续的系统
• 10万 → 20万 LoC: 从系统到平台
• 20万 → 40万 LoC: 从平台到企业级架构
• 40万 → 80万 LoC: 从企业级到大规模分布式系统

这些边界不是精确数学，也不是每个团队都一样。它们更像提醒：当代码量翻倍，真正翻倍的不是文件数量，而是你要在脑子里同时保留的关系。

一开始只是多几个组件。再往后，一个改动会牵出状态、接口、缓存、页面生命周期、权限、监控和发布路径。代码没有突然变坏，只是关系密度上来了。

康威定律、邓巴数、布鲁克斯定律都能解释一部分。但对我来说，最直接的体感是：我还勉强能理解系统，只是每次重新把它装进脑子里的成本越来越高。

第一阶段：5万行代码的现实检验

5 万行左右，项目已经不像原型了。

功能能跑，用户在用，问题也开始真实。最明显的几个痛点是：

• 跨组件的状态管理开始失控
• 快速原型开发积累的技术债开始反噬
• 性能问题出现（我们花了好几天优化一个阻塞用户的 FlatList）
• “简单”的变更现在会触及多个文件
• 在前端、后端、移动端、基础设施之间频繁切换上下文

FlatList 那次让我印象很深。它不是一个“以后有空优化”的问题。它卡住的是用户核心路径。我们花了好几天处理它，最后我才真正接受：性能问题在 1,000 DAU 时也会直接影响增长。

那时我们两个人还能把大部分系统装进脑子里。

但已经很吃力了。

下一阶段的挑战：10万行代码之墙

如果继续从 5 万行走到 10 万行，我预计问题会换一组。

• 单一代码库（Monorepo）变得难以维护
• 服务边界变得模糊
• 数据库成为瓶颈
• 代码所有权的争夺开始
• 到处都是合并冲突
• 新功能破坏了其他功能
• 知识孤岛开始形成
• 发布之间的协调越来越棘手

这不是吓自己。很多团队都是在这个阶段发现，真正的问题已经不只是“谁来写代码”，而是“谁还知道哪里该改、哪里不能改”。

我现在的判断是，第三个工程师往往应该在你觉得“还能撑一下”的时候就开始找。到了每天都在救火时再招人，新人进来只会先消耗更多上下文。

团队该怎么扩，其实没那么夸张

我一开始以为，代码复杂度如果接近平方增长，团队也许也要跟着夸张地扩张。

后来觉得没那么简单。

更现实的模式可能是每次代码量翻倍，团队规模增长 2-3 倍：

• 5万 → 10万 LoC: 2 → 4-6 名工程师
• 10万 → 20万 LoC: 4-6 → 10-15 名工程师
• 20万 → 40万 LoC: 10-15 → 25-40 名工程师

原因也很直观。优秀工程师会适应，工具会变好，团队会开始分工。可协调成本一定会上来。人越多，沟通路径越多，谁拥有哪块代码也必须更清楚。

哪些技术选择扛得住规模，哪些扛不住

状态管理是我们很早遇到的选择。

在当前阶段，我们选了 Zustand，没有选 Redux。

• 5-10 分钟的设置时间，而 Redux 需要 30-60 分钟
• 在快速迭代时样板代码更少
• 在架构变更期间更容易重构
• 在 React Native 中性能更好

这个选择在 5 万行左右很舒服。它轻，改起来快，不会在我们还没稳定领域边界时引入太重的结构。

但我也能理解为什么 10 万行以后，Redux 这类更强约束的方案会重新变得有吸引力：

• 复杂的异步流程占主导地位
• 多名开发者需要既定的模式
• 需要能回放状态的时间旅行调试
• 大型状态树需要更好的组织

我从这件事里学到的是：不要为了想象中的未来提前支付所有复杂度。

但也别把今天的轻量选择写死。给迁移留出口。

撞墙之前，能先做的准备

我现在更关心的是，在真正撞墙之前，能不能先做一点准备。

• 状态管理基础 - 现在把这个做好，以后可以节省数月的时间
• 组件设计系统 - 在 UI 出现分歧之前建立模式
• API 层抽象 - 统一的数据获取和错误处理
• 性能监控 - 在你急需之前就添加指标

我不想把 80% 的时间花在“未来架构”上。那会拖慢当下。

但如果完全不投入，后面就会用 60% 的时间救火。

所以我更喜欢一个粗略比例：现在拿 20% 做预防，剩下 80% 继续推进产品。

性能这件事，1000 个用户也不会等你

FlatList 那次之后，我对性能的看法变了。

以前我会把很多性能问题归到“还早”。用户不多，先验证需求。

但如果性能问题堵住的是核心路径，它就不早。1,000 个 DAU 也不会容忍核心功能卡住。用户不会因为你还在创业早期就更有耐心。

先为 1 万用户做，而不是 10 万

我们的目标比 1 万用户更大，但我现在更愿意先为 1 万用户构建。

• 适用于 1 万用户的架构决策可以演进到支持 10 万用户
• 为 10 万用户过度设计会增加复杂性，从而拖慢我们现在的速度
• 在为大规模优化之前，我们需要证明产品与市场的契合度（PMF）
• 规模不同，要解决的问题和需要的团队也不同

这不是降低目标，而是避免在还没证明产品之前，把自己困在过度设计里。

我们遵循的实用准则

基于这些经历，我们给 AI 编码助手和自己都设了一些规则：

• 立即修复性能瓶颈（用户不会等待）
• 选择可以演进的简单解决方案
• 设计易于迁移的方案（避免紧耦合）
• 仅在当前方法失效时才增加复杂性
• 简单、可维护的模式优于“企业级”方案
• 能够随团队成长而演进的模式
• 必要的监控，而非企业级的可观察性平台

这些话看起来朴素，但在 AI coding 里很重要。AI 很容易生成“看起来完整”的企业级结构。早期项目真正需要的，往往是能跑、能改、能迁移。

如果你也在早期，该盯哪些信号

如果你也在做早期产品，我会特别留意这些信号：

• 简单的变更开始花费超出预期的时间
• 开发者花在调试上的时间比写代码的时间还多
• 性能问题影响了用户体验
• 团队开始讨论“我们或许应该重构这个了”

这些信号出现时，不一定要立刻大重构。但你应该开始问：我们是不是进入了下一个阶段？

我现在会用几个触发点判断是否该升级：

• 仅在当前方法导致频繁 bug 时才增加复杂性
• 当团队协作成为瓶颈时，升级架构
• 当维护工作超过开发时间的 40% 时，就该招聘了

接下来我们准备做的

我们现在就在准备下一次翻倍。

具体来说：

• 投资于测试基础设施
• 建立清晰的组件边界
• 计划在代码量达到 7.5 万行左右时招聘第三名员工
• 构建部署自动化

我以前总想提前把架构想对。

现在更现实一点：今天的系统别把三个月后的自己锁死。

每一次代码翻倍都会带来新的问题，也会让团队获得新的能力。关键不在于精准预测未来，而在于早点识别阶段变化，然后给下一次演进留下路。

如果你也在类似阶段，我很想知道你在哪个规模点开始感觉系统变重了。