软件工程开发：那些教科书没教你的生存真相
上周跟一个做了十年技术的老开发喝茶，他吐了一下午槽。接了个烂尾外包，原来的团队跑了一半，留下一堆没注释的代码，甲方三天两头改需求，所有人都觉得这个项目必死，他接了，三个月，上线了，还赚了一笔。
很多人对软件工程开发的认知，从根上就错了。
软件工程开发需求评审会办公实拍
说实话，真正在推进的软件工程，哪有那么整齐划一。我见过最快活下来的项目，是16年某共享充电宝的早期版本，三个开发挤在民宅客厅打地铺，数据库没做分库分表，前端CSS全堆在一个文件里，连单元测试都没写几行，上线第三天就扛了十万级访问，活下来之后，花了一年慢慢重构整理。
很多人跳出来说这不规范，不对，不符合软件工程的要求。不对吗？活下来才有资格谈规范。死掉的项目，流程再完美，也只是存在硬盘里的文档而已。
就是这么现实。
软件工程开发项目需求变更记录表格
不过话说回来，成熟的开发团队，早就不跟变更对着干了。我之前待过的一个ToB团队，做定制化项目，一开始就给每个需求留了三分之一的缓冲工期，架构故意做得比当前需求大一圈，就是为了应对改需求。人家不追求一次性把事情做对，追求错了改得快。
这才是软件工程开发真正的核心能力。现在很多高校和科研机构的研究方向都转向柔性软件工程了，就是把不确定性当成常态，而不是需要被消灭的敌人。斯坦福去年的一篇研究显示，允许15%范围内需求变更的项目，最终交付成功率比要求零变更的项目高47%。数据不会骗人。
AI时代，软件工程开发的门槛反而变高了
这两年Copilot、GPT类的代码生成工具火得一塌糊涂，很多人喊着开发要失业，软件工程要变天。我看说这话的人，大多没真用这些工具做过完整项目。
去年GitHub官方的开发者调研显示，现在初级开发者写CRUD代码的时间确实减少了三分之一，但花在调试逻辑、整理框架、测试边界条件的时间，反而多了一半。原来一个初级开发写个登录模块要一天，现在十分钟AI就写出八百行代码，剩下的时间全在找AI埋的坑——比如权限判断逻辑错了，比如异常处理没写，比如不同模块的接口对不上，你得一个个调。
说白了，AI替你写了重复的代码，但是把对软件工程能力的要求往上提了一大截。原来你会敲代码就能找工作，现在你得会拆解需求，会排优先级，会整合零散的代码，能对最终的产品负责。这点，从来没变过，只是现在更明显了。
低代码吹了这么多年，说不用写代码就能做软件，我见过好几个项目，用低代码做内部工具没问题，一做对外的核心业务，做到一半业务复杂了，扩展不动，整个推倒重做，钱花了双倍，工期拖了半年。你以为低代码省去了写代码的麻烦，其实该踩的坑一个都绕不开，只是把坑都埋到项目后半段而已。
真的，做了这么多年，我最烦的就是上来就套方法论，什么这个框架那个最佳实践，好像照着做就能成。每个项目的人不一样，资源不一样，业务方向不一样，哪有放之四海而皆准的方法。
软件工程是干出来的，不是背知识点背出来的。你救过一个烂尾项目，比你读十本软件工程教科书都长本事。
昨天刷到一个刚毕业的小孩发帖，说进了项目组全是没注释的老代码，流程乱得一塌糊涂，想辞职。我只想说，能碰到烂项目，是你的福气。
在烂项目里摸爬滚打出来，你才懂什么是真正的软件工程开发。那些完美的大厂流程，都是给稳定成熟的业务准备的，真碰到乱摊子，还是得靠自己摸出来的法子。
对吧？
别迷信完美流程，烂项目活下来全靠灵活应变
现在网上一搜软件工程，全是标准敏捷、DevOps、规范CICD一套一套的，仿佛照着流程走，项目就能成。你去问问身边做过创业项目的朋友，十个死项目，八个流程搭得比代码还完整。 去年我朋友所在的AI初创公司，招了三个大厂出来的架构师，光定开发规范就花了两周，需求评审会开了一个月，核心代码还没写一千行，投资人撤资了，公司直接散伙。软件工程开发需求评审会办公实拍
说实话，真正在推进的软件工程，哪有那么整齐划一。我见过最快活下来的项目，是16年某共享充电宝的早期版本，三个开发挤在民宅客厅打地铺，数据库没做分库分表，前端CSS全堆在一个文件里，连单元测试都没写几行，上线第三天就扛了十万级访问，活下来之后，花了一年慢慢重构整理。
很多人跳出来说这不规范，不对，不符合软件工程的要求。不对吗？活下来才有资格谈规范。死掉的项目，流程再完美，也只是存在硬盘里的文档而已。
就是这么现实。
软件工程开发的核心，从来不是写代码，是管不确定性
前段时间翻ACM最新的行业研究论文，人家统计了过去二十年全球一千多个不同规模的软件项目，得出一个结论：82%的项目失败，不是技术能力不够，是没应对好需求、人员、进度的不确定性。 这话太戳人了。很多刚入行的年轻人，觉得软件工程就是把需求写清楚，排好工期，按部就班写功能，到点交付就行。你做过三个以上项目就懂，哪有不变的需求？ 甲方上周说首页按钮要品牌蓝，下周说红色转化率高改红色，下下周说还是改回蓝色吧，顺便加个三级分销的分享功能，工期不加，上线时间不变。你上哪说理去？软件工程开发项目需求变更记录表格
不过话说回来，成熟的开发团队，早就不跟变更对着干了。我之前待过的一个ToB团队，做定制化项目，一开始就给每个需求留了三分之一的缓冲工期，架构故意做得比当前需求大一圈，就是为了应对改需求。人家不追求一次性把事情做对，追求错了改得快。
这才是软件工程开发真正的核心能力。现在很多高校和科研机构的研究方向都转向柔性软件工程了，就是把不确定性当成常态，而不是需要被消灭的敌人。斯坦福去年的一篇研究显示，允许15%范围内需求变更的项目，最终交付成功率比要求零变更的项目高47%。数据不会骗人。
AI时代，软件工程开发的门槛反而变高了
AI时代，软件工程开发的门槛反而变高了
这两年Copilot、GPT类的代码生成工具火得一塌糊涂，很多人喊着开发要失业，软件工程要变天。我看说这话的人，大多没真用这些工具做过完整项目。
去年GitHub官方的开发者调研显示，现在初级开发者写CRUD代码的时间确实减少了三分之一，但花在调试逻辑、整理框架、测试边界条件的时间，反而多了一半。原来一个初级开发写个登录模块要一天，现在十分钟AI就写出八百行代码，剩下的时间全在找AI埋的坑——比如权限判断逻辑错了，比如异常处理没写，比如不同模块的接口对不上，你得一个个调。
说白了，AI替你写了重复的代码，但是把对软件工程能力的要求往上提了一大截。原来你会敲代码就能找工作，现在你得会拆解需求，会排优先级，会整合零散的代码，能对最终的产品负责。这点，从来没变过，只是现在更明显了。
低代码吹了这么多年，说不用写代码就能做软件，我见过好几个项目，用低代码做内部工具没问题，一做对外的核心业务，做到一半业务复杂了，扩展不动，整个推倒重做，钱花了双倍，工期拖了半年。你以为低代码省去了写代码的麻烦，其实该踩的坑一个都绕不开，只是把坑都埋到项目后半段而已。
真的，做了这么多年，我最烦的就是上来就套方法论，什么这个框架那个最佳实践，好像照着做就能成。每个项目的人不一样，资源不一样，业务方向不一样，哪有放之四海而皆准的方法。
软件工程是干出来的，不是背知识点背出来的。你救过一个烂尾项目，比你读十本软件工程教科书都长本事。
昨天刷到一个刚毕业的小孩发帖，说进了项目组全是没注释的老代码，流程乱得一塌糊涂，想辞职。我只想说，能碰到烂项目，是你的福气。
在烂项目里摸爬滚打出来，你才懂什么是真正的软件工程开发。那些完美的大厂流程，都是给稳定成熟的业务准备的，真碰到乱摊子，还是得靠自己摸出来的法子。
对吧？