写字楼凌晨的灯光里，藏着软件工程开发的真实真相
上周三凌晨一点，我陪朋友去南京建邺区的写字楼拿笔记本，电梯开门的瞬间，半层的灯光劈头盖脸砸过来——全是对着屏幕敲键盘的人。烟味混着咖啡味从门缝飘出来，还有人大声喊“别动库！我刚改完支付！”。
这就是我天天摸的软件工程开发，和校招宣讲会上说的完全不一样。
软件工程混乱项目代码依赖关系图
软件工程开发的本质从来不是写代码，是管理变化。你拼的不是死的积木，是随时要改的活物。需求会变，老板的想法会变，用户量会变，连对接的第三方接口说变就变。教科书上写的需求分析→设计→编码→测试→交付，那是理想状态，现实里你刚编码到一半，需求就改了三分之一，太正常了。
我见过做电商的，一开始说只做本地零售，做了半年要做全国供应链，原来写的库存逻辑完全用不了，只能推倒重写。要是一开始就想着只是搭积木，最后只能把自己埋在积木堆里。
不过话说回来，也不是说要把一百年后的变化都考虑到。过犹不及，这个度没人能教你，只能踩坑踩出来。
软件工程敏捷开发迭代流程示例图
接受不完美，小范围灰度测试，出了问题赶紧修，比硬憋三个月出一个号称“零bug”的版本靠谱多了。市场不等人，等你憋完，风口都没了。对吧？
说实话，我现在面试新人，不问你会多少种语言，不问你懂多少复杂的架构，我就问两个问题：你之前踩过最大的坑是什么？你后来怎么填的？能说清楚的，都是干过活的，那些张口就是各种术语，说自己从来没出过问题的，基本上都是没碰过真实项目的。
软件工程开发的边界，别什么锅都往开发身上甩
现在很多公司，尤其是创业公司，有个特别歪的逻辑：需求定不下来，没关系，开发先做着边做边改；上线延期了，都是开发能力不行；用户量上不去，都是开发写的代码太烂。
这锅，软件工程开发不背。软件工程解决的是“已知的不确定”，解决不了“完全的不确定”。你今天想做生鲜，明天想做社交，后天又想做直播，连核心需求都没定，天天改核心流程，开发就算是神仙也赶不上你的进度啊。
我之前见过一个项目，产品经理每隔两天就改一次需求，两个月改了不下二十次核心流程，最后上线拖了三个月，老板骂开发效率低，太扯了。软件工程是工具，不是魔法，变不出来你想要的东西。
还有最近这些年吹的厉害的低代码无代码，好多人说以后软件工程开发要失业，开发工程师都要没饭吃。其实根本不是这么回事。低代码确实能帮你快速搭出一个基础应用，适合做那种固定流程的内部工具，真碰上新的复杂业务，核心逻辑的梳理，变化的管理，该有的功夫一点都省不了。低代码只是把你从写重复基础代码的活里解放出来，让你把更多时间花在解决真正复杂的问题上，不是替代你。
软件工程开发的边界在哪里？它是帮你把一个模糊的大问题，拆成一个个能解决的小问题，用工程化的方法把这些小问题拼起来，变成一个能用的产品。它解决的是“怎么做”的问题，解决不了“做什么”的问题。“做什么”错了，再好的软件工程也救不了项目。
那天我从写字楼出来，在楼下便利店买水，碰到三个开发出来抽烟，吐槽完产品经理改需求，又凑在一起聊下周怎么重构那个缠成麻的代码，眼睛红的要命，但是亮的很。
其实软件工程开发哪有那么多高大上的说法，就是一群人对着一个烂摊子，一点点理，一点点磨，把不可能变成能用的东西。就像南京这城市，老城墙根下开着新的咖啡馆，百年的巷子里还能长出新的生意，哪有一蹴而就的完美，都是慢慢迭代出来的。你说对不对？
别被教科书骗了，软件工程开发从来不是搭积木
很多没碰过实际项目的人，觉得软件工程就是把需求拆成模块，像搭乐高一样拼起来，粘完刷个漆就能交差。我三年前在南京接了一个创业学生的项目，做校园生鲜配送的，三个小伙子攒了半年学费，找外包做了第一版，三个月就上线。刚上线的时候还沾沾自喜，说十万行代码不到三个月就写完了，效率拉满。 结果开学新生一进校，三千多学生同时挤进来抢优惠券，服务器直接崩了。好不容易重启起来，改个满减规则，结果商品库存显示直接乱了——原来所有模块的代码都缠在一起，改支付牵连着商品，改商品牵连着库存，找bug找了整整两天，最后只能从头梳理依赖关系。软件工程混乱项目代码依赖关系图
软件工程开发的本质从来不是写代码，是管理变化。你拼的不是死的积木，是随时要改的活物。需求会变，老板的想法会变，用户量会变，连对接的第三方接口说变就变。教科书上写的需求分析→设计→编码→测试→交付，那是理想状态，现实里你刚编码到一半，需求就改了三分之一，太正常了。
我见过做电商的，一开始说只做本地零售，做了半年要做全国供应链，原来写的库存逻辑完全用不了，只能推倒重写。要是一开始就想着只是搭积木，最后只能把自己埋在积木堆里。
不过话说回来，也不是说要把一百年后的变化都考虑到。过犹不及，这个度没人能教你，只能踩坑踩出来。
那些没人教你的潜规则，都是踩坑踩出来的
刚入行那会，我总觉得要做就要做最好的架构，要用最火的技术栈，不然就是落伍。后来带了个实习生，给公司做一个内部审批工具，最多也就十个管理员用，愣是拆了五个微服务，本地启动要等十分钟，调试一个接口要重启三次，我问他为啥这么做，他说现在大厂都这么做，这样够规范。 我当时就笑了。够用的架构，远比完美的架构值钱。软件工程开发最反常识的一点就是，你不需要一开始就把所有东西都做对，你只需要先做出来，再慢慢改对。 还有一个误区，绝大多数新人都踩过：写代码比写文档重要，文档可以最后补。我之前在南京高新区的一个项目组，核心开发裸辞，走的时候什么文档都没留，只扔了一个压缩包说代码都在里面。我们对着他三个月前写的代码找一个支付回调的逻辑，找了整整三天，那三天天天吃楼下的黄焖鸡，熬夜到两点，现在想起来喉咙里还能吃出味精味。 代码是给机器看的，文档是给人看的。三个月后你自己都认不出自己写的代码，更何况接手的新人？别省这个功夫，真的。 还有，别执着于上线前干掉所有bug。真的不可能。你永远想不到用户会用什么姿势用你的产品——有人用五年前的安卓机开你的APP，后台挂了二十个应用，能不卡吗？有人填表单能把手机号多输一位，你不做校验能不崩吗？软件工程敏捷开发迭代流程示例图
接受不完美，小范围灰度测试，出了问题赶紧修，比硬憋三个月出一个号称“零bug”的版本靠谱多了。市场不等人，等你憋完，风口都没了。对吧？
说实话，我现在面试新人，不问你会多少种语言，不问你懂多少复杂的架构，我就问两个问题：你之前踩过最大的坑是什么？你后来怎么填的？能说清楚的，都是干过活的，那些张口就是各种术语，说自己从来没出过问题的，基本上都是没碰过真实项目的。
软件工程开发的边界，别什么锅都往开发身上甩
软件工程开发的边界，别什么锅都往开发身上甩
现在很多公司，尤其是创业公司，有个特别歪的逻辑：需求定不下来，没关系，开发先做着边做边改；上线延期了，都是开发能力不行；用户量上不去，都是开发写的代码太烂。
这锅，软件工程开发不背。软件工程解决的是“已知的不确定”，解决不了“完全的不确定”。你今天想做生鲜，明天想做社交，后天又想做直播，连核心需求都没定，天天改核心流程，开发就算是神仙也赶不上你的进度啊。
我之前见过一个项目，产品经理每隔两天就改一次需求，两个月改了不下二十次核心流程，最后上线拖了三个月，老板骂开发效率低，太扯了。软件工程是工具，不是魔法，变不出来你想要的东西。
还有最近这些年吹的厉害的低代码无代码，好多人说以后软件工程开发要失业，开发工程师都要没饭吃。其实根本不是这么回事。低代码确实能帮你快速搭出一个基础应用，适合做那种固定流程的内部工具，真碰上新的复杂业务，核心逻辑的梳理，变化的管理，该有的功夫一点都省不了。低代码只是把你从写重复基础代码的活里解放出来，让你把更多时间花在解决真正复杂的问题上，不是替代你。
软件工程开发的边界在哪里？它是帮你把一个模糊的大问题，拆成一个个能解决的小问题，用工程化的方法把这些小问题拼起来，变成一个能用的产品。它解决的是“怎么做”的问题，解决不了“做什么”的问题。“做什么”错了，再好的软件工程也救不了项目。
那天我从写字楼出来，在楼下便利店买水，碰到三个开发出来抽烟，吐槽完产品经理改需求，又凑在一起聊下周怎么重构那个缠成麻的代码，眼睛红的要命，但是亮的很。
其实软件工程开发哪有那么多高大上的说法，就是一群人对着一个烂摊子，一点点理，一点点磨，把不可能变成能用的东西。就像南京这城市，老城墙根下开着新的咖啡馆，百年的巷子里还能长出新的生意，哪有一蹴而就的完美，都是慢慢迭代出来的。你说对不对？