软件工程开发：我见过90%团队都踩过的隐形坑
上周跟一个创业公司技术负责人喝酒，他说他们三十多人的技术团队，三个月改不完一个支付模块。上线就崩，改完又出幺蛾子。累到裁员一半还是卡。很多人听到这儿第一反应是，技术不行？招人不对？其实真不是。就是从第一天开始，软件工程开发的根就歪了。
软件工程系统依赖熵增可视化图
什么是熵？说白了就是混乱度。你加一个功能，舍不得删旧代码，留着'万一以后用呢'。改一个接口，为了不影响老用户，直接加个新接口，旧的扔那儿不管。不出半年，整个系统就变成了一团乱麻，牵一发而动全身。我之前待过一个传统企业的内部系统项目，翻代码翻出来十年前的注释，写着'2014年双11临时补丁，节后删除'。现在2024年了，那段代码还安安稳稳躺在主干分支里。你敢删吗？没人敢。鬼知道哪个角落的老业务还在调用这个接口。
很多团队天天喊着我们用敏捷，我们搞Scrum，每天准点开站会，燃尽图画得漂漂亮亮。结果呢？技术债堆得比办公楼还高，没人敢碰。说实话，敏捷根本不是让你天天赶需求堆功能，是让你每个迭代都清一点点混乱，把熵控住。好的软件工程开发，从来不是追求零熵——那不可能，只要有人参与写代码，就一定会产生混乱。但是你得把它控在安全线以内，不能让它炸了。
2024大模型辅助软件工程开发渗透率统计图
很多人喊着大模型要取代开发者，我看根本扯谈。大模型把最基础的搬砖活干了，反而把软件工程的核心矛盾给摆到台面上了——你根本不知道大模型随手生成的代码，嵌到你的系统里，会带出多少额外的混乱。上个月我一个做外包的朋友接了个小项目，用GPT生成整个用户中心，三天写完，本地测试全过，功能一点问题没有。结果上线一周，数据库直接炸了。三个人查了整整三天，最后发现GPT生成的登录接口，每次用户登录都会生成一个永不释放的数据库连接。小流量测试看不出来，真实流量一上来，连接数直接打满，可不就炸了吗。你说坑不坑！
现在全球科研圈已经在追新方向了，叫大语言模型软件工程（LLMSE），CMU去年下半年发的顶会论文就说了，未来软件工程开发的核心能力，已经从'写代码'慢慢转向'审核大模型代码+管控大模型输出的熵'。我最近面试高级开发，上来第一个问题就问：拿到大模型生成的一段功能完整的代码，你第一会做什么？一半的面试者说跑一遍单元测试，过了就合分支。只有不到三分之一的人会说，先看它加了什么额外依赖，有没有留无用的全局变量，有没有破坏原来的接口约定。这不就是摸到新赛道的门了吗？
不过话说回来，大模型也真的给软件工程省了好多事。以前梳理十年老系统的依赖关系，三个工程师干三个月，还理不全。现在大模型几天就能给你画出完整的依赖图，准确率能到八成以上，这种脏活累活，以前没人愿意干，现在大模型包了，这不就是天大的好事吗。
小团队做软件工程开发，别瞎抄大厂作业
我见过太多小团队，刚起步三五个人，上来就照搬大厂那套流程。写PRD要五十页起，代码CR要三个审批人，搞七八个监控大屏，每天光走流程都要半天。结果呢？需求还没做完，融资的钱烧完了，直接死掉。去年北大软件所做过一个针对国内创业团队的调研，一百五十个百人以下的创业技术团队，统计出来流程复杂度和项目成功率的相关性是-0.67——越追求复杂规范的流程，死得越快。
那小团队该怎么搞？核心就是八个字：最小可用，及时还债。什么意思？先做出来能跑能用的版本，别上来就搞微服务、搞分布式、搞高可用架构，先把需求验证了再说。但是你要把欠下的技术债记下来，每个迭代抽10%到20%的时间还债，别攒着，攒到还不起那天就完了。
我认识一个五个人的创业团队，做垂直领域的toB SaaS，第一年就是一个简单的单体应用，什么高大上的架构都没搞，每个月固定抽一周时间重构还债，现在三年过去了，业务涨了二十倍，系统还跑得好好的，一点不卡。反而那些一开始就拆分十几个微服务，招了一堆架构师的团队，一半都没熬到盈利，自己把自己拖死了。
很多人觉得软件工程开发就是堆流程堆规范，没错，但是规范永远是服务于人的，不是反过来把人捆死。我见过有的团队，变量名少打一个下划线，CI直接打回，必须改完才能合并，这不是纯纯的形式主义吗？只要逻辑对，能跑，稍微不规范后面抽时间改不行吗？当然核心业务的核心规范不能松，但是别搞一刀切，没必要。
说实话，软件工程这么多年，从来就没有银弹。不管是过去的瀑布模型，还是现在的敏捷开发，还是未来的AI全辅助开发，核心永远是一件事：帮一群人，一起把一个复杂的东西做出来，还能一直改下去。所有脱离这个核心的流程、方法、规范，都是耍流氓。现在好多人焦虑，说大模型来了，开发是不是要失业了？其实你换个角度想，软件工程开发，从古到今玩的就是管控复杂性，AI把写代码的简单活干了，你只要把管控混乱、控熵的本事练出来，永远有你的位置。反正我见过活下来还活得舒服的团队，都是早早把这件事想明白的。
没人教你的：软件工程开发，核心不是写代码是治熵
现在很多新人入行，甚至工作三五年，都觉得软件工程就是接需求、写代码、上线改bug。对吗？不对。MIT软件工程实验室2023年最新调研结果显示，82%的线上生产故障，根源都不是某一行代码写错了，是整个系统的依赖熵超过了安全阈值。软件工程系统依赖熵增可视化图
什么是熵？说白了就是混乱度。你加一个功能，舍不得删旧代码，留着'万一以后用呢'。改一个接口，为了不影响老用户，直接加个新接口，旧的扔那儿不管。不出半年，整个系统就变成了一团乱麻，牵一发而动全身。我之前待过一个传统企业的内部系统项目，翻代码翻出来十年前的注释，写着'2014年双11临时补丁，节后删除'。现在2024年了，那段代码还安安稳稳躺在主干分支里。你敢删吗？没人敢。鬼知道哪个角落的老业务还在调用这个接口。
很多团队天天喊着我们用敏捷，我们搞Scrum，每天准点开站会，燃尽图画得漂漂亮亮。结果呢？技术债堆得比办公楼还高，没人敢碰。说实话，敏捷根本不是让你天天赶需求堆功能，是让你每个迭代都清一点点混乱，把熵控住。好的软件工程开发，从来不是追求零熵——那不可能，只要有人参与写代码，就一定会产生混乱。但是你得把它控在安全线以内，不能让它炸了。
大模型时代，软件工程开发正在悄悄换赛道
今年GitHub刚发布的《2024全球开发者状态报告》，你看了吗？68%的开发者已经日常用Copilot这类大模型工具写业务代码，其中超过30%的生产级代码，直接来自大模型生成。这个渗透率，放在两年前想都不敢想。2024大模型辅助软件工程开发渗透率统计图
很多人喊着大模型要取代开发者，我看根本扯谈。大模型把最基础的搬砖活干了，反而把软件工程的核心矛盾给摆到台面上了——你根本不知道大模型随手生成的代码，嵌到你的系统里，会带出多少额外的混乱。上个月我一个做外包的朋友接了个小项目，用GPT生成整个用户中心，三天写完，本地测试全过，功能一点问题没有。结果上线一周，数据库直接炸了。三个人查了整整三天，最后发现GPT生成的登录接口，每次用户登录都会生成一个永不释放的数据库连接。小流量测试看不出来，真实流量一上来，连接数直接打满，可不就炸了吗。你说坑不坑！
现在全球科研圈已经在追新方向了，叫大语言模型软件工程（LLMSE），CMU去年下半年发的顶会论文就说了，未来软件工程开发的核心能力，已经从'写代码'慢慢转向'审核大模型代码+管控大模型输出的熵'。我最近面试高级开发，上来第一个问题就问：拿到大模型生成的一段功能完整的代码，你第一会做什么？一半的面试者说跑一遍单元测试，过了就合分支。只有不到三分之一的人会说，先看它加了什么额外依赖，有没有留无用的全局变量，有没有破坏原来的接口约定。这不就是摸到新赛道的门了吗？
不过话说回来，大模型也真的给软件工程省了好多事。以前梳理十年老系统的依赖关系，三个工程师干三个月，还理不全。现在大模型几天就能给你画出完整的依赖图，准确率能到八成以上，这种脏活累活，以前没人愿意干，现在大模型包了，这不就是天大的好事吗。
小团队做软件工程开发，别瞎抄大厂作业
小团队做软件工程开发，别瞎抄大厂作业
我见过太多小团队，刚起步三五个人，上来就照搬大厂那套流程。写PRD要五十页起，代码CR要三个审批人，搞七八个监控大屏，每天光走流程都要半天。结果呢？需求还没做完，融资的钱烧完了，直接死掉。去年北大软件所做过一个针对国内创业团队的调研，一百五十个百人以下的创业技术团队，统计出来流程复杂度和项目成功率的相关性是-0.67——越追求复杂规范的流程，死得越快。
那小团队该怎么搞？核心就是八个字：最小可用，及时还债。什么意思？先做出来能跑能用的版本，别上来就搞微服务、搞分布式、搞高可用架构，先把需求验证了再说。但是你要把欠下的技术债记下来，每个迭代抽10%到20%的时间还债，别攒着，攒到还不起那天就完了。
我认识一个五个人的创业团队，做垂直领域的toB SaaS，第一年就是一个简单的单体应用，什么高大上的架构都没搞，每个月固定抽一周时间重构还债，现在三年过去了，业务涨了二十倍，系统还跑得好好的，一点不卡。反而那些一开始就拆分十几个微服务，招了一堆架构师的团队，一半都没熬到盈利，自己把自己拖死了。
很多人觉得软件工程开发就是堆流程堆规范，没错，但是规范永远是服务于人的，不是反过来把人捆死。我见过有的团队，变量名少打一个下划线，CI直接打回，必须改完才能合并，这不是纯纯的形式主义吗？只要逻辑对，能跑，稍微不规范后面抽时间改不行吗？当然核心业务的核心规范不能松，但是别搞一刀切，没必要。
说实话，软件工程这么多年，从来就没有银弹。不管是过去的瀑布模型，还是现在的敏捷开发，还是未来的AI全辅助开发，核心永远是一件事：帮一群人，一起把一个复杂的东西做出来，还能一直改下去。所有脱离这个核心的流程、方法、规范，都是耍流氓。现在好多人焦虑，说大模型来了，开发是不是要失业了？其实你换个角度想，软件工程开发，从古到今玩的就是管控复杂性，AI把写代码的简单活干了，你只要把管控混乱、控熵的本事练出来，永远有你的位置。反正我见过活下来还活得舒服的团队，都是早早把这件事想明白的。