编译 | Tina

跑得快，不等于跑得稳。

有不少初创公司，不是在市场竞争中失败codejock software，也不是因资金耗尽而告终，而是产品没法进行扩展 ，被自身所积累的代码以及混乱的架构给困住，最终落得陷入慢性死亡绝境的下场 。在过去的3年里 ，有一位架构顾问 ，审阅了47家处于“产品无法扩展”节点前来求助的初创公司的代码库 ，令人惊讶地发现 ，它们几乎都是沿着同一条时间线走向停滞的 。

初创公司技术债：死亡时间线

创始人兼CEO是Meir，他专门在初创公司处于技术危机状况之时介入去“救火” ，明确指出，那些初创公司找到他，常常并非由于他们“烧光了钱”，而是源于他们代码库以及技术栈存在扩展危机，即“产品完全没办法实现规模化，然而却不清楚其中缘由究竟是什么” 。

在这样的情形之下，他发觉，致使走向失败的这种模式，无一遗漏，总会反复呈现出来：

二十四 个月往后 ，现实 将选择 压缩成 两条路径 ：其一 是从零开始 重新书写 ，其二 是眼睁睁 看着系统 以慢动作 的状态 。

那他敢于做出这般概括，缘由在于，于四十七个代码库当中所见到的“地基病”，呈现出高度的同质状态 。

其中最能引人注意的是数据库层面，“差不多有89%完全不存在数据库索引，完全没有。”应用运行缓慢，并非是因为什么离奇的bug导致的，而是每次请求都要在条记录当中进行扫描。资源方面同样很是刺眼，大概76%的公司在云端“购置了八倍数量的机器”，然而平均利用率仅仅只有13%，“你是为一百台机器支付费用，可实际上却仅仅使用了十三台”，每个月平白无故白白耗费三千到一万五千美元。

安全侧同样脆弱，将近七成的系统存在鉴权漏洞，此漏洞之严峻足以让安全工程师“心梗”。至于质量保障呢，最要命的常并非覆盖率数字不佳，而是完全缺失，91% 的团队没有任何自动化测试。如此这般使得每一次上线宛如玩轮盘赌一般，根本没人能够保证“一键确认没把别的地方弄坏”。

要是换算成成本，按照一名工程师年薪十二万美元去估计，相关研究显示，开发人员会花42%的时间处理糟糕代码，这般对于一个4人团队而言，3年内即是60多万美元的浪费。在维护垃圾代码之际，还要加上20至40万美元的重建费用，以及重建期间6至12个月的收入损失，每家公司的总损失达：200至300万美元。

好多创始人呢，一直到第18 - 24个月的时候，才察觉到这一情况。那个时候呀，他们刚刚好是靠着好看的增长曲线完成了A轮融资，然而却并没有意识到“增长马上就要崩溃瓦解”了。

“两周架构，十八个月不崩”

而真正能避免这些的是什么？

其采用的方法颇为质朴，将最具性价比的投资置于第一行代码之前，也就是花费两周时间来构建架构，他坦率地讲：“我深知这会显得乏味，你同样渴望尽快发布版本，然而这两周能够为你免除 18 个月的艰难困苦。”。

于这两周期间，需自起始便维持规模化思路，先询问“到一万用户时会出现何种状况”，并非是“一百个用户能否正常运行”。数据库查询、文件上传、后台作业等关键路径，在第一天就应当拥有承接一百倍的空间。与此同时，自动化测试要从第一天上线。倘若无法一键确认“未对其他地方造成损坏”，那么每次发布都如同在碰运气。技术栈选择“无趣的”更为妥当。存在这样一种情况，React，还有Node，它虽然无趣的很，然而却易于招人，有着Stack答案，可以避免在凌晨2点突然出现让项目无法继续的状况。

外部架构评审，同样得提前至第一周，照他的说法，就是在第一周找个做过这种事的人去审阅你的架构，千万别等到第12个月才去请，因为那时已然太晚了。

之所以要这般早，其原因在于存在一句虽不太中听但相当真实的话语，即“大多数技术联合创始人和首批工程师都颇为擅长编写代码，然而却从未设计过具备可扩展性的架构。这情形犹如你身为一位优秀的厨师，却从未在晚餐高峰时段管理过餐厅厨房那般。”。

那种能够毫不间断地投入大量资金的公司，“Move fast, break.”（快速行动，打破常规）的准则兴许能行得通。然而，在你所创办的处于起始阶段的公司当中，这么做无疑就是自我毁灭。所以呢，每一个从事创业的技术团队都能够先自行检查一番：当达到当前用户数量的 10 倍的时候，系统会在哪个地方出现崩溃的情况呢？有没有自动化测试呢？数据库可不可以承受得住 100 倍的查询数量呢？要是用户数量增长到 10 倍，基础设施方面的成本是不是也会急剧攀升到每月 50,000 美元呢？

若是这些问题当中存在一个答案为“我不知道”的情况，那么你便是在流沙之上建造房子。

同样的问题，一家接一家

纵使，所指出的坑好像听起来特别“低级”呀（也正因为这样从而受到了一些质疑呢），不过，评论区中间不少处于一线的从业者认同其具有普遍性哟。

有读者很直接地讲，自己所从事的工作和，相近，这些所提到的坑，仅仅只是冰山一角，特别是在AI出现爆发式发展之后，原因在于任何能够运用类似Code，这里Code指代AI编码工具的人，都在迅速地推出产品。

看上去显得光鲜亮丽的产品，翻里面去便是存在一大堆没经测试的代码，又没人去负责相关事宜，还声称着“不需要文档”，基本上是不存在架构设计的。他发出感叹，工程当中最具价值的一些东西常常会被忽视掉，“研究与实战都在讲别去逃避测试”，然而不少初创的情况“并不如此去想”。

另一位开发者也给出“我也见过”的现场证词。

他曾亲眼看到公司耗费三年时间去做一个本应六个月就完成的产品，只因初始设计糟糕透顶codejock software，最终成品不得不全部推翻重新再来。他也见识过一个极有大卖潜力的软件项目，然而就是这样一个项目，团队却在即将上线之前按下了停机按钮——并非是市场方面出现了问题，而是架构致使单用户成本过高，“同样的功能，如果架构不佳则需要50倍的服务器”。他对此所做的总结十分现实：

也有人这就是现实本身，并不深奥，归根到底就是自律与基本功。

哟，兄弟，这可是我在这儿的几周之内瞅见的绝无仅有的那种写最透的好文章之一哕哈，是真真切切以认真态度码出的——每一句话都实实在在是那些创始人的伤疤痛处哇，可不是光是嘴上瞎咧咧、纸上谈兵的那样嘢。然而呢，说实在的哟，大部分早期的那些创始人根本就不会去听的啦：他们依旧会去用胶带凑合着粘粘功能，嘴里还念叨着“等以后再去重新构建吧”，接着就在一条仅仅两秒的查询把他们那高达$30k的AWS账单给炸得面目全非的时候才开始痛哭流涕哟！

最为离谱的情况是，明明这压根就不是那种颇具深度的技术方面的建议，而仅仅只是一些基本的技能以及自我约束罢了。比如说，要去编写测试，要把数据库表的名称起得恰当，要给查询语句添加索引，而且不要一味地追逐那些新颖炫酷的框架等等。我曾经见到过这样的人，当用户数量仅仅只有500个的时候，他们竟然还在口口声声地吹嘘“我们遭遇了扩展性方面的问题”，然而实际的情况却是，他们根本就没有运用后台任务队列，也没有使用缓存层。

有人在评论区提出了一个堪称灵魂的问题，那就是：“写得真好。氛围编码在这所有的一切当中扮演了怎样一种角色呢？你当前正在进行审计的代码里面，究竟有多少是由AI所撰写的？”此问题正好戳中了当下的关键所在，AI将“先跑起来”的门槛降低到了从来都未曾有过的低水平位置，并且还把“慢性死亡”的到来时间大幅提前了。模型生成出来的代码常常呈现出“看似能够发挥作用”的状态，可是这种情况却使得技术债的积累速度变得更快，代码质量也更加难于进行判断。

“大语言模型”的创造力跟破坏力是同时存在的，它能够把念头快速地转变为代码，它也有可能把临时搭建的脚手架错误地当作地基，而所付出的代价通常要到第18个月才会集中显现出来。

参考链接：

https://old..com/r/////

如有侵权请联系删除！