办公室门口那出戏，每个月都在重演。应届生揣着绩点满分的简历推门进来，不出一个月，准能把坑踩出个坑坑洼洼。我见过不少孩子，吭哧吭哧重构了三天底层逻辑，产品经理跑过来一句“需求调整”，全打水漂。代码敲得那叫一个飞起，一上评审会，同事指着屏幕问：“这注释呢？异常兜底呢？”新人心里肯定犯嘀咕：公司流程是不是太磨叽？老员工是不是在挑刺？其实，刚毕业那会儿，谁没觉得自己是天才来着？但《软件工程师培训10讲》这书，没在那儿炫技堆算法。反反复复，就盯着几件小事抠。怎么啃透需求？怎么画设计图？怎么过代码复查？怎么盯缺陷调试？怎么把文档写明白？作者掰开揉碎，就递给你一句话：工程师混出个名堂，真不看你代码写得有多灵光。全看你对“出bug”这事儿有没有敬畏心，对“走流程”能不能老老实实低头。这话听着刺耳吧？在职场里滚过几年，你多半会拍着大腿骂自己，当初怎么就没早点翻两页。
这话咋说呢？学校跟职场的玩法，压根不是一套。卷子上题眼在哪、标准答案长啥样，明明白白摆在那，你只管秀脑子。到了公司呢？需求像泥鳅，抓不住。代码是七八个人拼出来的积木，你交出去的东西，得能扛压，能改，能接着往下长。书里专门腾出好几讲，死磕“怎么听懂需求”和“怎么画设计图”。为啥？就是怕你接了活儿，手指头直接按在键盘上敲。不画草图直接码字，眼瞅着省了两天功夫，实际上是把雷埋进了下周的排期里。我带过实习生，有回没画架构图直接开干，联调那天，前后端接口对不上，俩人大半夜熬到两点，才把数据字段对齐。书里反复念叨“复查调试”“质量保证”，真不是搞挑刺大会。提前把坑填平，不香吗？出个bug不丢人，系统是机器，出岔子太正常。走流程也不是拿绳子捆手脚，是让大家在雾里行路时，手里能攥根绳。不过话说回来，流程这东西，用过了头，也容易把人磨成螺丝钉。
落到地上，多少技术焦虑都是脑子没转过弯闹的。新人要是嫌写文档麻烦，或者把评审会当成公开处刑，不出仨月，就能把自己关进“信息孤岛”。技术债这东西，你不还，它自己利滚利。书里点名的那些“软技能”——怎么跟产品扯皮、怎么挨得住骂听反馈、怎么弄懂业务到底想赚哪份钱——新人往往眼皮都不抬。总以为代码写得像诗一样，就能横着走。现实挺骨感。一段没人看得懂的代码，扔在那儿，跟废纸没两样。工程师这活儿，说白了就是跟未来的自己、跟隔壁工位的兄弟打交道。定规矩、写文档、互相挑错，全是为了别让这通电话打串了号。我有时候也琢磨，现在有些团队连个简单的API文档都懒得维护，全靠口口相传。这哪是软件工程，简直是玄学。但反过来想，要是新人连基础文档都写不利索，指望他哪天能去设计分布式架构，是不是有点太乐观了？
不过，把流程当圣经天天供着，也不是个事儿。团队要是正处在烧钱抢市场的生死局，或者得赶紧跑通一个野路子想法，死磕文档和评审，纯粹是自己绊自己脚。书里这套招数，挑的是那种得长期养着、一堆人接着干、不能随便崩盘的项目。它压根不是要掐死创意，而是给创意画个圈，别跑偏了。真懂行的，都知道在“快跑”和“踩刹车”之间找平衡。光死守规矩，最后活成个填表的机器。光图快不顾死活，早晚得被烂账埋了。我觉得吧，这书适合那些想往中大型互联网或者传统软件转型的人。你要是去那种三天一个版本的创业公司，照搬这套，可能连试用期都过不了。它提供的是底线思维，不是万能钥匙。具体用多少，还得看项目处在什么阶段。
刚翻这本书的时候，我也直嘬牙花子：这也太保守了吧？后来真被线上事故锤过。因为没做异常处理，直接炸了库。或者因为没跟业务对齐，憋了一周代码全推倒重来。这才懂作者为啥死磕“基本功”。软件这行，门槛从来不在你背了多少语法糖。而是扔进一团乱麻的泥潭里，你能不能稳稳当当把东西交出去。从教室到工位，最难翻的那道坎儿，根本不是换套新工具。是把脑子里的弦，重新拨一遍。哪天你不再琢磨怎么写出个挑不出毛病的“艺术品”，转而去靠流程兜底、靠大伙儿补位、靠一次次复盘把坑填平，那张工程师的入场券，才算真正攥到了手里。这事儿大概就是这么个意思。共勉吧。