软件工程开发：那些课本没教你的行业真相
上周跟干了十五年的老架构师喝茶，他吐了一肚子苦水。说现在年轻人把软件工程玩成了凑KPI的走秀，流程走得滴水不漏，交付的东西全是坑。
我深以为然。
互联网公司敏捷开发站会现场实拍
说实话，真的离谱。
去年帮一个创业公司做项目复盘，六个人的团队，SOP写了三十七页，一个改按钮位置的需求要过三次评审，结果上线三个月，核心的支付bug拖了一个月没修好，老板还拍桌子说「我们流程很规范，肯定是开发偷懒」。
流程是兜底的，不是用来挡锅的。
软件工程开发从诞生那天起，所有流程方法的核心，都是帮你更快更好地解决问题，不是给你找个免责金牌。老架构师说他当年做淘宝早期，哪有这么多规矩？需求来了两三个人蹲会议室，撸三天代码直接上线测，不对就回滚，出问题一起扛，也没见公司垮掉。
现在倒好，一个需求改个文字，都要三个leader签字，层层审批下来，一周过去了，用户早就跑了。
程序员使用Copilot辅助编程工位实拍
不过话说回来，我一开始也觉得，大模型会把行业洗牌，淘汰大半初级开发者。后来跟业内做AI编程的朋友聊完才醒过来。
大模型写得好代码片段，写不好软件工程。
你要做一个面向C端的生鲜配送订单系统，AI能给你写出完美的CRUD，能给你拼出完整的接口文档，但是它不知道你公司现阶段库存和订单要不要解耦，不知道你要支持的是十万级还是千万级并发，不知道你们团队总共只有三个人，维护不了太复杂的分布式架构，更不知道老板要求三个月必须上线，容不得你慢慢搭框架。
这些决策，AI做不了。
大模型是提效的生产力工具，不是替你背锅做决策的老板。
现在行业吹得太邪乎，说什么以后产品经理自己就能写代码，不需要开发了。真上过手就知道，AI给的代码，跑起来全是藏在边角的bug，业务逻辑的坑，全得你自己踩自己填。软件工程的核心从来不是写代码，是拆分需求、梳理逻辑、踩坑填坑，这些活，AI学十年也未必能搞定。
好的软件工程，是「留余」不是「完美」
我见过太多新人，刚入行被各种大厂架构白皮书洗脑，张嘴就是微服务分布式，闭口就是高可用可扩展，上来不管项目多大，先把架构搭得花里胡哨，结果老板钱烧完了，核心产品还没上线。
前两年听过最离谱的事，一个做本地生活的创业项目，总共才不到一万活跃用户，技术负责人上来拆了八个微服务，光做服务治理和监控就花了两个多月，等到要做核心业务的时候，投资款花完了，项目直接黄了。
何苦呢？
好的软件工程开发，从来不是追求一步到位的完美，是给未来留够余地。你一开始创业，用户量才几千，一个单体应用足够，把代码边界理清楚，每个模块留好扩展点，等用户涨到几十万了，再拆微服务不行吗？干嘛上来就给自己加戏，把简单问题复杂化。
我见过最舒服的项目，是一个退休老程序员带的小团队，做一个给线下门店用的进销存系统，一开始就只写满足当前需求的代码，每个改点都写清楚注释，哪里可能要扩展标得明明白白，三年迭代了十几个版本，从来没有推倒重构过，团队三个人维护得轻轻松松，赚的钱全落袋了。
很多人说重构是程序员的美德，我看不必要的重构，就是纯粹的浪费钱。大厂的最佳实践，是给千万级并发准备的，你一个小公司几十个人，凑什么热闹？适合自己当前阶段的，才是对的。
前几天刷到一个讨论，问软件工程到底是科学还是艺术。我觉得都不是，它就是戴着枷锁跳舞，你要懂基本的原则，但是别死磕教条。别把流程当护身符，别把工具当目的，别为了所谓的完美浪费没必要的钱。
能把事办成，少踩坑多赚钱，就是好的软件工程开发。
别把「流程正确」当成「结果正确」
不知道从什么时候开始，国内大部分公司做软件工程，把流程看得比天还大。 敏捷开发变成了每日站会打卡，燃尽图画得比产品UI还漂亮，需求评审开三个小时，没人真的关心这个需求到底能不能解决用户问题。出了bug第一反应不是排期修，是查你当初有没有走签字流程，有没有留文档。互联网公司敏捷开发站会现场实拍
说实话，真的离谱。
去年帮一个创业公司做项目复盘，六个人的团队，SOP写了三十七页，一个改按钮位置的需求要过三次评审，结果上线三个月，核心的支付bug拖了一个月没修好，老板还拍桌子说「我们流程很规范，肯定是开发偷懒」。
流程是兜底的，不是用来挡锅的。
软件工程开发从诞生那天起，所有流程方法的核心，都是帮你更快更好地解决问题，不是给你找个免责金牌。老架构师说他当年做淘宝早期，哪有这么多规矩？需求来了两三个人蹲会议室，撸三天代码直接上线测，不对就回滚，出问题一起扛，也没见公司垮掉。
现在倒好，一个需求改个文字，都要三个leader签字，层层审批下来，一周过去了，用户早就跑了。
大模型来了，软件工程开发真的变天了？
最近半年圈里最火的话题，就是AI Coding，到处都在吹「初级程序员要消失了」「零代码时代来了」。 上个月帮本地一所高校做行业调研，翻了几十个计算机学生的作业，九十多份作业的代码全是Copilot生成的，连变量命名都没改，问他for循环的边界条件为什么这么写，他说不知道，Copilot就是这么给的。程序员使用Copilot辅助编程工位实拍
不过话说回来，我一开始也觉得，大模型会把行业洗牌，淘汰大半初级开发者。后来跟业内做AI编程的朋友聊完才醒过来。
大模型写得好代码片段，写不好软件工程。
你要做一个面向C端的生鲜配送订单系统，AI能给你写出完美的CRUD，能给你拼出完整的接口文档，但是它不知道你公司现阶段库存和订单要不要解耦，不知道你要支持的是十万级还是千万级并发，不知道你们团队总共只有三个人，维护不了太复杂的分布式架构，更不知道老板要求三个月必须上线，容不得你慢慢搭框架。
这些决策，AI做不了。
大模型是提效的生产力工具，不是替你背锅做决策的老板。
现在行业吹得太邪乎，说什么以后产品经理自己就能写代码，不需要开发了。真上过手就知道，AI给的代码，跑起来全是藏在边角的bug，业务逻辑的坑，全得你自己踩自己填。软件工程的核心从来不是写代码，是拆分需求、梳理逻辑、踩坑填坑，这些活，AI学十年也未必能搞定。
好的软件工程，是「留余」不是「完美」
好的软件工程，是「留余」不是「完美」
我见过太多新人，刚入行被各种大厂架构白皮书洗脑，张嘴就是微服务分布式，闭口就是高可用可扩展，上来不管项目多大，先把架构搭得花里胡哨，结果老板钱烧完了，核心产品还没上线。
前两年听过最离谱的事，一个做本地生活的创业项目，总共才不到一万活跃用户，技术负责人上来拆了八个微服务，光做服务治理和监控就花了两个多月，等到要做核心业务的时候，投资款花完了，项目直接黄了。
何苦呢？
好的软件工程开发，从来不是追求一步到位的完美，是给未来留够余地。你一开始创业，用户量才几千，一个单体应用足够，把代码边界理清楚，每个模块留好扩展点，等用户涨到几十万了，再拆微服务不行吗？干嘛上来就给自己加戏，把简单问题复杂化。
我见过最舒服的项目，是一个退休老程序员带的小团队，做一个给线下门店用的进销存系统，一开始就只写满足当前需求的代码，每个改点都写清楚注释，哪里可能要扩展标得明明白白，三年迭代了十几个版本，从来没有推倒重构过，团队三个人维护得轻轻松松，赚的钱全落袋了。
很多人说重构是程序员的美德，我看不必要的重构，就是纯粹的浪费钱。大厂的最佳实践，是给千万级并发准备的，你一个小公司几十个人，凑什么热闹？适合自己当前阶段的，才是对的。
前几天刷到一个讨论，问软件工程到底是科学还是艺术。我觉得都不是，它就是戴着枷锁跳舞，你要懂基本的原则，但是别死磕教条。别把流程当护身符，别把工具当目的，别为了所谓的完美浪费没必要的钱。
能把事办成，少踩坑多赚钱，就是好的软件工程开发。