软件工程开发：被行业忽略的三个反常识真相
前阵子跟老东家的技术总监喝茶，他掏出来一份内部效率统计，给我吓了一跳。国内八成互联网团队的软件工程交付效率，居然比十年前还低了近三成。
我一开始也不信。
现在工具比十年前好一万倍，有各种脚手架，有云服务器，有AI辅助写代码，怎么效率反而降了？坐下来掰扯了一下午，才发现很多坑，都是大家主动往里跳的。
互联网团队敏捷开发站会实景
为什么会这样？很多公司老板对敏捷的理解，就是“不用做需求评审，不用写设计文档，边做边改，省下来的时间多赶几个版本”。
把原来三个月要干完的活，拆成六个两周迭代，本质还是赶活，核心问题一点没解决。需求乱改的毛病没改，团队沟通不畅的问题没动，连给开发留重构代码的时间都砍了，怎么可能效率高？
我之前待过一个创业团队，为了赶融资，连续八个迭代不给重构时间，最后代码屎山堆到什么程度？改一个按钮的颜色要动三个底层模块，每次上线都要烧香。
离谱吗？现在绝大多数团队，都是这么干的。
Google软件工程代码量缺陷率关系统计图
不过话说回来，减代码可比加代码难多了。
加代码只要对着需求堆功能就行，减代码你得懂业务，得知道哪些功能用户真的在用，哪些根本没人碰；你得懂架构，敢动前人留的屎山，还要能保证改完不出问题；你还要敢跟产品经理撕，把那些没必要加的功能挡回去。
我见过太多产品，做需求上来就是“我要加个XX功能”，从来不说“我们能不能把XX功能删掉”。现在很多热门的SaaS产品，打开首页密密麻麻几十按钮，90%的用户一年都点不了一次，不仅占资源，还把真正有用的功能藏起来，给开发留了无数坑。
对吧？你代码越写越多，复杂度越来越高，最后整个项目就拖死了。
AI时代，软件工程开发的底层逻辑变了吗？
最近一年AI代码助手火遍全网，到处都在说“以后初级程序员要失业了”。
我倒是觉得，这反而是给软件工程正本清源了。
原来开发一天花八成时间写重复的CRUD，搜报错，复制粘贴代码，现在AI几分钟就给你写完了，那开发要干嘛？原来你只要会写代码就能混饭吃，现在AI写的比你快比你错的少，你就得往上走，去管需求，去控复杂度，去做架构设计。
上个月跟字节的一个朋友聊天，他说他们团队用Copilot半年了，现在新人上手速度快了一倍，但是淘汰率也涨了一倍——那些只会写重复代码，不会想整体设计的开发，现在根本混不下去。
很多团队现在踩了新坑：AI生成的代码直接合并，不加评审，不做重构，不到三个月，代码库就变成了AI屎山，谁都看不懂，改一个地方牵出一堆bug。
说白了，软件工程从始至终，解决的都不是“怎么写出代码”的问题，是“怎么控制复杂度”的问题。工具变了，这个核心没变。
你不管用敏捷还是瀑布，用AI还是手写，核心都是把复杂的问题拆成能搞定的小块，把错误挡在上线之前，把冗余的东西及时清理掉，让团队能一直跑下去，不会被自己堆的屎山压死。
现在行业就爱卷新概念，一会儿DevOps，一会儿低代码，一会儿AI原生，吹得玄乎其玄，其实剥开看，都是换了包装的老道理。把基础的事情做对，别搞花活，比什么都强。
别迷信敏捷，大部分团队练的都是“假敏捷”
敏捷开发刚出来的时候，所有人都叫好，说终于不用搞瀑布那种半年不上线的蠢东西了。 现在呢？大部分公司把敏捷念成了歪经。 每天固定站会，十五分钟起步，每个人对着看板念流水账，我昨天做了A，今天要做B，遇到卡壳的问题全藏着不说——怕被Leader说能力不行，怕背锅。两周一个迭代，每到迭代尾期就集体熬夜改bug，上线前一天还在改需求，美其名曰“快速响应变化”。 说实话，这哪是敏捷，这是“散装加班”。 去年GitHub官方发布的全球开发者调研，明明白白写着：68%深度落地敏捷开发的团队，交付周期反而从预期的2周拉长到了4周，线上缺陷率比采用传统瀑布模型的团队还高出21%。互联网团队敏捷开发站会实景
为什么会这样？很多公司老板对敏捷的理解，就是“不用做需求评审，不用写设计文档，边做边改，省下来的时间多赶几个版本”。
把原来三个月要干完的活，拆成六个两周迭代，本质还是赶活，核心问题一点没解决。需求乱改的毛病没改，团队沟通不畅的问题没动，连给开发留重构代码的时间都砍了，怎么可能效率高？
我之前待过一个创业团队，为了赶融资，连续八个迭代不给重构时间，最后代码屎山堆到什么程度？改一个按钮的颜色要动三个底层模块，每次上线都要烧香。
离谱吗？现在绝大多数团队，都是这么干的。
软件工程开发的核心，从来不是写代码，是减代码
我刚入行的时候， leader 跟我说了一句话，我记到现在。 好的软件工程，是做减法，不是做加法。 那时候年轻，觉得写代码越多越牛，我一个月写一万行，肯定比写三千行的产出高。直到后来跟着架构师重构老项目，原来十万行代码的交易系统，硬生生砍到三万多行，性能翻了三倍，线上bug直接减少了八成。 我当时直接看傻了。 原来一大半代码都是冗余的，要么是重复造轮子，要么是已经下线的需求留的垃圾代码，要么是为了“未来扩展性”提前写的无用功能，放那好几年，谁都不敢动，就怕出问题。 2023年Google软件工程研究院发了一篇顶会论文，结论非常狠：项目缺陷率随代码行数增加呈指数级上涨，每多一千行冗余代码，整体维护成本会上涨15%以上。Google软件工程代码量缺陷率关系统计图
不过话说回来，减代码可比加代码难多了。
加代码只要对着需求堆功能就行，减代码你得懂业务，得知道哪些功能用户真的在用，哪些根本没人碰；你得懂架构，敢动前人留的屎山，还要能保证改完不出问题；你还要敢跟产品经理撕，把那些没必要加的功能挡回去。
我见过太多产品，做需求上来就是“我要加个XX功能”，从来不说“我们能不能把XX功能删掉”。现在很多热门的SaaS产品，打开首页密密麻麻几十按钮，90%的用户一年都点不了一次，不仅占资源，还把真正有用的功能藏起来，给开发留了无数坑。
对吧？你代码越写越多，复杂度越来越高，最后整个项目就拖死了。
AI时代，软件工程开发的底层逻辑变了吗？
AI时代，软件工程开发的底层逻辑变了吗？
最近一年AI代码助手火遍全网，到处都在说“以后初级程序员要失业了”。
我倒是觉得，这反而是给软件工程正本清源了。
原来开发一天花八成时间写重复的CRUD，搜报错，复制粘贴代码，现在AI几分钟就给你写完了，那开发要干嘛？原来你只要会写代码就能混饭吃，现在AI写的比你快比你错的少，你就得往上走，去管需求，去控复杂度，去做架构设计。
上个月跟字节的一个朋友聊天，他说他们团队用Copilot半年了，现在新人上手速度快了一倍，但是淘汰率也涨了一倍——那些只会写重复代码，不会想整体设计的开发，现在根本混不下去。
很多团队现在踩了新坑：AI生成的代码直接合并，不加评审，不做重构，不到三个月，代码库就变成了AI屎山，谁都看不懂，改一个地方牵出一堆bug。
说白了，软件工程从始至终，解决的都不是“怎么写出代码”的问题，是“怎么控制复杂度”的问题。工具变了，这个核心没变。
你不管用敏捷还是瀑布，用AI还是手写，核心都是把复杂的问题拆成能搞定的小块，把错误挡在上线之前，把冗余的东西及时清理掉，让团队能一直跑下去，不会被自己堆的屎山压死。
现在行业就爱卷新概念，一会儿DevOps，一会儿低代码，一会儿AI原生，吹得玄乎其玄，其实剥开看，都是换了包装的老道理。把基础的事情做对，别搞花活，比什么都强。