摘要：在创业圈里，“有了好想法就立刻行动”、“大胆打破常规”几乎成了一种信条。但也有人提醒，这种 Slogan 有时更像是在“加速走向灾难”。

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

在创业圈里，“有了好想法就立刻行动”、“大胆打破常规”几乎成了一种信条。但也有人提醒，这种 Slogan 有时更像是在“加速走向灾难”。

最近，构建软件开发公司 Gliltech Software的创始人兼 CEOMeir Avimelec Davidov在 Reddit 上分享了他审查 47 家失败创业公司代码库后的总结，其提出一个观点——“快速行动、勇于打破”这句话只适用于像 Facebook 那样有无限预算的公司，对于小型创业公司而言，如果这样做了，无异于「慢性自杀」。此话一出，争议也随之出现。

从高速增长到技术泥潭：24 个月的坠落轨迹

Davidov 的工作，是在初创公司陷入技术危机时“救火”。他说，自己干这行已经三年了，创业公司通常只有在“出大事”的时候才会找他帮忙——不是那种“钱快烧完了”的危机，而是“产品彻底无法扩展、没人知道为什么”的那种。

在他接触的几十个案例里，几乎都沿着同一条轨迹坠落：

第 1–6 个月：团队士气高涨，功能上线快、客户满意，产品看似一切顺利。

第 7–12 个月：进度放缓，bug 开始堆积，“以后再修”成了口头禅。

第 13–18 个月：每加一个新功能，就会搞坏三个旧的功能。每次部署都如履薄冰。

第 19–24 个月：工程团队规模扩大，却只是在维护混乱的代码。创新停滞。

第 25 个月后：要么推翻重写，要么看着产品和公司一起崩塌。

他总结道：“到第 18–24 个月，创始人通常才意识到问题。但那时公司往往已经完成了 A 轮融资，增长数据即将坍塌。”

47 个代码库里的“灾难共性”

在审查 47 家失败创业公司的代码库后，Davidov 得到了一组令人震惊的数字：

89% 的项目没有为数据库建立索引，每次请求都在全表扫描十万条数据；

76% 的公司花的钱是所需服务器的 8 倍，平均利用率只有13%——相当于花100 台服务器的钱，只用到 13 台，每月白烧三千到一万五千美元；

68% 的项目存在严重的身份验证漏洞，让安全专家看了都要“心梗”；

91% 根本没做自动化测试。每上线一个新功能，就像在玩“代码轮盘赌”。

换算成成本，他进一步估算，一支 4 人开发团队在三年内，仅因糟糕的代码质量，就会浪费 60 万美元以上。再加上后续的重构成本和营收损失，平均每家公司因技术债损失高达200–300 万美元。

“三天省下 46 万美元”

那要怎么避免这种灾难？Davidov 认为，大多数初创公司的问题并非技术复杂度太高，而是根基没打好。

为此，他也分享了他的建议：

在写第一行代码前花两周时间做架构设计。或许有人觉得这很无聊，就想要快点上线，但 Davidov 指出，花费的这两周能让你少受 18 个月的折磨。

其次，要以 1 万用户为起点思考架构，而不是执着于“在 100 用户时能不能跑起来”。数据库查询、文件上传、后台任务——都得从一开始就能撑得住 100 倍负载。

从第一天就上自动化测试。“如果你不能点一下就验证一切正常，那就是在赌。”

选择“无聊”的技术栈。React / Node / Postgres 这类“无聊”的技术其实是好事——你能招到人、有现成答案、凌晨两点它不会突然挂掉。

在第一个星期就找有经验的人来帮你审架构，别等到系统已经塌了才求助。

Davidov 说道，很多初创公司的技术负责人都擅长写代码，却缺乏系统架构经验。“这就像一个出色的厨师第一次独自扛起高峰期的餐厅厨房——理论上懂，但实际会乱成一团。”

为此，他提到一个真实案例——一家 SaaS 公司每月在 AWS 上的支出高达 $47,000。经过他为期三天的架构审查后，发现：

这家公司实际上只需要 6 台服务器，却运行了 40 台；

文件存储使用的是最昂贵的方案；

数据库查询耗时 4 秒，本可缩短至 40 毫秒。

经过其优化后，账单降至 $8,200/月，每年节省$46.5 万美元。一切只用了三天时间。

自查的四问

时下，之所以分享这些，Davidov 称，是因为自己真的看够了这样的案例——创始人白白浪费 18 个月、烧掉 50 万到 200 万美元，却没有去学习那些完全可以避免的教训。

他认为，“快速行动、勇于打破”这句话只适用于像 Facebook 那样有无限预算的公司。对于小型创业公司而言，如果这样做了，无异于「慢性自杀」。

他最后留下了四个问题，供每一位正在创业的技术团队自查：

当前用户量的 10 倍时，系统会崩在哪？

有自动化测试吗？

数据库能撑 100 倍查询量吗？

若用户增长 10 倍，基础设施成本是否也要暴涨到 $50,000/月？

“如果这些问题里有一个你回答‘不知道’，那你现在做的一切，都是在建一座‘流沙上的房子’。”

争议四起

Davidov 的分享，也引发了不少技术人的共鸣。

一位名为 octave1 的网友表示：

描述那段“每隔几个月系统状况如何变化”的部分，和我上一家公司经历的完全一样。

我入职两周后就礼貌地建议他们：“老实说，最好的办法就是全部重写。”

那时候我们连最基础的优惠券逻辑（x - y = z）都无法在生产环境里正常跑，原因谁也搞不清。缓存和会话数据共用同一个 Redis 实例，所以每次清缓存，所有用户都会被登出、购物车也会被清空。

接下来的两年，我们都在修 bug、救火。唯一上线的新功能，两个月后也被撤掉了。直到他们终于给开发团队（就我和另一个人）招了个“更懂技术的经理”。结果这位上任第一天就拍板：“我们要重写一切”——只是这次用的技术栈比原来复杂十倍。

另一位技术人 TimMensch 称：

说得没错，我也见过类似情况。我见过一些公司花了三年时间开发一个本应只需要六个月就能完成的产品，结果因为最初设计糟糕，他们开发出来的应用最后还是得重建。

我还见过一家公司开发了一个本可能大受欢迎的软件，但最终不得不放弃——原因是他们发现，每个客户在服务器上的成本都超过了客户愿意支付的费用。但造成高成本的原因并不是“必然如此”，而是因为当初的架构设计问题：如果有良好设计的架构，只需要 1 台服务器的工作量，他们却用了 50 台。

确实，如果你的收入非常高，即便软件工程一开始很糟糕，有时候依然可以成功。但很多商业机会本身就足够有潜力去成功，只是必须从一开始就有正确的软件工程。

讽刺的是，第一次就做好软件工程，并不需要花更多的钱。确实，为建立稳固的基础，每个开发者的成本可能高一些，但如果你只需要 3 个开发者而不是 20 个，而且他们能更快完成工作并写出更稳健的代码，这就是巨大的收益。可惜很多公司最终会去雇佣“便宜”的海外团队，结果花费数年时间制造出一堆毫无价值的技术债。

不过，也有人持有不同的看法，另一名用户 londons_explore 评论道：

我不同意这种方法。在最初几个月里，你的产品方向会变化得非常快，第一年结束时，你原本所谓的“合理设计”早就荡然无存了。

我的建议是：当团队规模很小（比如三名开发者或更少）时，就把所有东西先拼凑起来。不要讲究编码规范，也不必写测试，只做出能在 Demo Day 展示的质量即可。

然后，当团队超过四人，产品方向也明确了，再从零重建一切。

听起来好像浪费时间，但重建一次比第一次构建要快得多，而且你可以拥有一个合理的设计，而不是不断被多次改变方向折腾出来的东西。这时也正是把编程语言从适合原型开发的方案换成更适合生产环境、且容易招聘开发者的语言的好机会。

对此，你怎么看？

来源：CSDN一点号