软件工程开发：被很多创业者忽略的“慢”道理

前几天跟一个创业公司的技术负责人喝酒，他拍着桌子吐槽，说老板给三个月时间要做全品类电商平台，上线半年就推到重构，现在整个团队天天给原来的烂代码擦屁股，连改个满减规则都要提心吊胆测三天。 这种事，我听了没有一百也有八十了。

软件工程开发不是“搭积木”，是“种房子”

绝大多数外行，甚至不少刚入行的开发，都觉得软件工程就是把一个个功能模块拼起来，像搭乐高一样，人多手快就能出活。 真不是这么回事。 前段时间翻CMU计算机学院最新的行业调研报告，里面统计了全球近千个互联网项目的失败原因，超过72%的延期、重构项目，根源都是一开始就把软件工程开发当成了可批量复制的机械组装，完全没考虑代码的“生长性”——业务会变，需求会加，用户规模会涨，你的代码得跟着一起长，而不是一开始就焊死成一块没法动的铁疙瘩。 软件工程开发需求迭代遗留代码示意图 我前东家去年接的那个外包电商项目就是最好的例子。老板拍胸脯给客户保证两个月上线，说找八个熟手改一改开源框架的代码就行，省成本还快。结果改到第三个礼拜，整个团队都卡壳了：原来开源版本的支付模块和库存模块是硬耦合的，客户要加一个分销分账的功能，动支付就得改库存，改库存就得动商品模块，环环相坑，最后硬生生拖了四个月，预算超了两倍，连客户都不好意思说我们慢，只问原来的代码是不是真的烂成这样。 真是笑死人。一群人天天把敏捷挂在嘴边，最后敏成了瞎扑腾，连最基本的预留扩展性都做不到。

软件工程开发的核心，是对抗持续熵增

去年MIT CSAIL出了一篇挺有意思的论文，专门研究长期维护项目的代码混乱度变化，结论说：没有主动投入重构的软件项目，熵增速度大概是每年12%，也就是说，每七年，整个项目的代码混乱度就会翻一倍，最后变成没人敢碰的“屎山”。 很多人看到这会说，我用最新的微服务架构，用最火的开发框架，不就能解决熵增了？ 哪有这么简单。框架只是工具，挡不住人乱改代码。为了赶进度打个补丁，为了省十分钟加一行硬编码，为了应付需求加一个不该加的全局变量……一次两次看不出来，时间一长，整个项目的混乱度就蹭蹭往上涨，等到你发现改不动的时候，已经晚了。 说实话，我见过至少五家创业公司，不是死在产品没流量，不是死在融不到钱，就是死在代码改不动——老板要加一个新功能抢占市场，开发说最少要三个月，老板等不起，直接就没然后了。 软件工程代码熵增变化趋势对比图 不过话说回来，也不是所有公司都糊涂。去年我接触过一个做跨境SAAS的团队，他们每个版本都留了四分之一的时间专门做重构，不发新功能，就优化现有代码结构。一开始创始人也心疼，说这不浪费时间吗？做了两年之后，他们加新功能的速度比同赛道快一倍，别人要一个月，他们一个礼拜就能上线测试，就是因为代码干净，没有历史包袱。 去年中科院软件所的国内行业调研数据也印证了这件事：重视软件工程基础建设，定期投入重构成本的项目，长期维护成本平均比不做的低47%，整体上线速度反而快28%。这个数字真的超出很多人的预期吧？大家都觉得慢就是浪费，没想到慢反而更快。

大模型时代，软件工程开发的本事更值钱了

大模型时代，软件工程开发的本事更值钱了 这两年大模型火了之后，到处都是“AI会写代码，程序员要失业”的论调，连很多行内人都在说，以后软件工程开发就是给AI提需求，拼拼凑凑就能出项目。 真的是这样吗？我上个月听腾讯的一个技术专家分享，他们内部做过测试，让GPT-4生成一个中等规模的后端项目，功能跑通没问题，但是放到生产环境，一万个用户就扛不住了，到处都是内存泄漏，到处都是不必要的资源占用，最后还是资深的软件工程团队花了两周时间重构，才正常上线。 为什么？因为大模型只能根据你提的当下需求生成代码，它不会帮你考虑未来一年业务要涨十倍怎么扩展，不会帮你控制代码熵增，不会帮你理清模块之间的耦合关系——这些恰恰是软件工程开发最核心的价值。 大模型把写基础代码的门槛拉低了，但是把对工程能力的要求拉高了。现在你随便找个毕业生，让大模型写点CRUD就能跑，但是能把一个项目从0带到100万用户，还能让代码一直保持可维护性的人，少之又少，也越来越值钱。 很多人说，互联网进入下半场了，软件工程开发不香了？不对，恰恰是下半场，大家都从抢流量变成练内功，软件工程开发的本事才是真正的护城河。你代码烂，加功能慢，成本降不下来，慢慢就被对手甩没影了。 别总想着抄近道，软件工程开发这回事，走得慢，才能走得远。