前天晚上十一点我收到一条消息。不是女朋友发的是领导把代码评审链接甩进项目群配了一句“你自己看看你提交了什么别人怎么看”点开链接我的提交下面挂了二十多条评论。最狠的一条不是批评逻辑而是同事问“这三个变量名是想表达什么意思我猜了半天也没猜出来。”那一下我脸上挂不住翻到评论区末尾果然有人留下沉甸甸的两个字“服了。”这事过去了半个多月我现在回想起来已经不生气了反而挺感激。被骂惨不丢人丢人的是没从被骂里长记性。这篇内容就是聊聊我那次没按编程规范来被当众拆台的完整经过我当时怎么想的、写出了什么玩意、别人怎么看的、之后我又是怎么改的。如果你正在经历代码评审被怼、觉得自己写的代码“反正能跑就行”或者刚接手别人的烂摊子气得想骂人可以参考我这份从挨批到整改的真实经历。1. 我为什么敢不按规范来复盘挨骂前那段时间的心态1.1 “先把功能跑起来再说”的心态是怎么来的我那会刚接手一个跨平台工具模块需求催得特别紧。业务方周一提出要一个批量处理能力周五就要看到效果。我每天打开需求文档都觉得像被人拿鞭子赶着第一反应就是先按照最简单粗暴的方式把流程打通至于代码风格、命名、结构划分全部排到“以后再说”那一栏。这种场景太常见了一旦脑子里只有一个“跑通”的念头规范就会被当成拖后腿的东西。我觉得自己特别有理“业务要得这么急哪有时间抠变量名”但后来回头翻Git历史我才发现真正让我返工的从来不是写规范代码花掉的时间而是因为不写规范代码导致的读代码、改代码时间。前后至少多花了两倍。另一个心态是过度自信。我当时觉得这个模块后续主要是自己在维护别人不太会碰命名随便点无所谓。可事实是代码一旦进了共享仓库性质就变了。评审机制存在的意义就是让其他人在你不在场的时候也能快速理解、安全修改你的代码。“只有我自己看”这种假设几乎必然会被现实击碎。1.2 想到过去被规范“卡住”的旧账给自己找借口我另一个免罪心理是拿过去的体验说事。前东家有个项目规范多到离谱注释要按模板填所有方法上都要挂全角标点说明CI里还对空行数量做了限制。因为那套机制体验很差草率地推出没有任何过渡和解释我潜意识里就把“遵循规范”和“被愚蠢的制度恶心”画了等号于是到了新项目一看到风格文档就直接关闭懒得看。这个转变现在看很滑稽一个规范好不好和你该不该遵守当前的规范根本是两码事。实际情况是任何团队只要定了规范就一定有人觉得某条规矩不合理。你可以不认可但你不能默默违反然后期待代码看起来还像团队的代码。我们都是成年人有意见就提提完未采纳就执行——这在工程里是基本共识。不过我那时确实不懂这个道理觉得“旧账”可以成为我不守规则的理由结果就是我在项目里贡献了一段风格极其突兀、结构混乱的大块逻辑埋下了被骂的全部伏笔。2. 评审现场被一条条拆解的“作品”被骂的重点集中在这四类2.1 命名让人先花十分钟猜谜我的提交里第一个被拎出来说的问题就是命名。在一个交易状态处理模块里我给接口起了个名字叫dealInfoX。当时心里的想法是模块叫dealInfo表示它返回详情加个X是因为这已经是第七版了之前六个名字都被产品需求变化推翻了。问题是我把这种“第几版”标记直接带进了代码同事根本不知道X是什么意思还以为是罗马数字或者某个特定业务代号。更遭的是内部变量。我用了a、b、cur、tmp这些烂大街的名字。业务逻辑本身不太复杂但十分钟没有语义读的人要在四个方法之间来回跳转靠自己脑补“这个a到底代表的a是什么”。有一处获取用户等级的逻辑我写了一行def get_level(u): return 1 if u.attr 100 else 2评审同事问100这个阈值是什么1和2到底是什么等级我当时理直气壮地答“就是vip和普通嘛”他反手回了一句“那你为什么不写进代码”这句话我现在都记得。2.2 一个函数里面塞了三层if嵌套看得人脑壳疼命名问题之后他们又指到了函数逻辑。某段核心处理函数我在里面塞了一个三十多行的逻辑块结构上是“先判断有没有权限再判断参数是否合法然后判断状态是否匹配最后才处理主流程”。每个判断体内部还有一层 if/else再加上我为了赶时间连局部变量都是在分支里现声明现用整个函数读起来像一串藤蔓。最深的问题不是嵌套层数而是每一步判断到底想解决什么问题完全没有说清楚。有经验的工程师都知道你应该把每个独立判断拆成有名字的函数或关卡比如has_permission(user, action)、is_valid_input(payload)、can_transit(current, target)。就算我不拆至少也要用空行和注释把三大块分隔开而不是让所有逻辑像面条一样搅在一起。我自己后来用编辑器数了一下那个函数出现过21个局部变量最长的一行参数列表排到了屏幕边缘被自动折行。一个函数好不好不要把“能跑”作为唯一标尺。真正的标准是过一个月再打开能不能在三十秒内弄清楚它到底做了什么、分哪几步。2.3 魔法数字和三处重复实现魔法数字在这个项目里真的把我坑惨了。我写了好几处if x 5、timeout 3000、retry_count 3。每个数字背后都有业务含义5分钟内的超时3000毫秒的重试间隔3次的失败上限。但代码里完全没有体现。评审同事逐个追问我逐个解释解释到第三个的时候我心里已经发虚了——这些含义我只存在自己脑子里如果下个月我休假了谁来改这段逻辑靠祈祷吗比魔法数字更严重的是三处重复实现。因为最开始没规划公共类我先后三次用不同思路写了一个把接口返回数据结构转换成界面模型的功能。第一处直接调用了第三方库的一个方法第二处手写循环赋值第三处为了省事又复制了第二处的代码然后改了几行。结果评审贴出三处差异对比肉眼可见的相同逻辑不同写法差点没地缝钻进去。程序员最忌讳的就是这种“复制改改”的常规操作你以为省时间实际上三处代码需要同步维护任何一处Bug修复都要改三个位置漏一个都是隐患。2.4 提交信息写得像加密电报这一段被单独提出来是因为它不属于代码本身但杀伤力一点不小。我那两天的 Git 提交信息连写了三个fix bug modify something update我没有一行写清楚“改了哪个模块”“为什么要改”“影响了什么”评审人看变更列表根本无从下手。再加上我一个大功能分成了四次提交第一和第二次之间代码是编译不过的。同事直接说“你把提交记录做成这样我怎么知道该review哪儿要是出了问题怎么回滚到可用状态”那次是我第一次意识到提交信息不是给自己看的是给团队的时间线看的。我当时被骂得最惨的还不是我故意摆烂而是我一开始觉得没啥大不了后来发现每一条都增加了别人理解代码的成本。这个时候我才终于承认规范不是限制我发挥的条条框框而是团队协作的润滑剂。3. 从“代码能跑就行”到“代码能维护才算数”真实的代价和教训3.1 我被骂的最难听的那一刻反而是因为一段“能跑”的代码事情的高潮发生在评审现场。有一个需求的实现我用了全局可变状态来存临时变量功能是能跑而且我一个人调试的时候跑得非常顺。但评审人指着那行代码问如果同一个用户并发操作两次这个全局变量被两个请求同时读写你告诉我会发生什么我脑子瞬间空白然后说“应该不会吧”。然后同事当着所有人的面打开数据测试工具模拟了一下并发场景。结果毫无悬念状态污染数据错了。那一刻已经不是“被骂”的问题是现场被打脸。我写的代码不只是难读它还埋了一个真正的缺陷。这不是运气不好而是我在设计阶段跳过了对共享状态和边界条件的思考——又不写规范注释又不梳理逻辑隐患当然藏得住。这件事让我彻底想明白了不按规范来短期确实能跑得通但它让你避开了每一次本该认真思考的机会。等到问题暴露时就不再是被评论批评两句的事而是线上事故。3.2 接手代码的人不会感谢你的“聪明”被骂完没几天项目里的另一个模块因为修复紧急临时安排我去接手。我一打开那个模块第一眼是佩服——写代码的人用一个全局配置文件加动态反射实现了非常灵活的调度。但紧跟着就是痛苦这个模块没有任何注释配置项没有文档动态调度导致静态搜索失效我花了整整两天才搞懂一条流程是怎么走通的。那一刻我立刻想到自己前几天的行为如果我的某些代码也给别人造成这样的麻烦我不被骂谁被骂我们总以为写出来的代码是给机器执行的其实真正的读者是后面打开文件的那个人。机器的耐心远大于人的耐心。机器无论你写得乱不乱都能慢慢执行但人的耐心有限一旦读不懂就开始重写、绕过或者在心里骂你。所以我现在特别信奉一句话代码是写给人看的只是顺便被机器执行。这也是“按编程规范来”最核心的本质不管理解成命名一致、结构分层还是提交清晰最终都是为了减少人的认知负担。3.3 规范不是教条我分清了“必须遵守”和“可以有弹性”的部分被批评之后我的第一个冲动是“那就把所有规范都背下来以后一句废话都不多说”。但我冷静下来翻了几份团队已有的编程规范文档发现规范其实有不同的约束等级有些是必须的比如所有外部输入必须校验、禁止在循环里拼SQL、禁止全局可变状态有些是可弹性的比如缩进用空格还是Tab、字符串用单引号还是双引号、函数上限多少行。我觉得这是非常关键的一个认知升级。如果你把规范当成一套死规矩你迟早会在某条“不合理”的规定上反弹。但如果你能区分规范里的“硬约束”和“风格偏好”你就会明白风格偏好统一是为了工具链顺畅硬约束是为了不出事两者各司其职。我在整改阶段专门给团队的规范文档画了逻辑分层硬约束用红笔标出来风格偏好放在后面保证自己每次提交前先过红笔部分再顺手过一遍风格部分。4. 从被骂到自救我落地的一套自查清单和工具约束4.1 提交代码前的15分钟自查一份照抄就能用的清单被骂完当天我做了一件我早该做的事——写了一份提交前自查清单。我不再依赖“感觉没问题”而是逐项打勾。这份清单后来也分享给一起被骂的朋友他说救了大命。我把核心部分贴在下面命名是否表达了“做什么而不是怎么做”所有变量名、函数名、类名如果读起来还需要看实现才能懂立刻改。是否有魔法数字所有数值常量必须改成有名字的常量或配置项并在声明处写清楚业务含义。是否存在三层以上的嵌套或超过30行的函数有就拆拆完用函数名重新表达意图。是否注释了“为什么”而不是“是什么”注释只写“为什么要这么做”代码本身能表达的不要重复注释。是否跨过lint/format提交前先跑一遍项目的格式化和静态检查不要等到CI报错。提交信息是否说明模块原因影响形如“feat(order): 增加批量状态同步接口处理超时重试场景”而不是“update”。是否有重复逻辑应该抽出来只要发现任何两段逻辑有相似性至少考虑抽公共方法确认后再决定不动。是否碰了全局状态或共享可变数据只要沾边必须写清并发影响并在评审描述里高亮。这条清单听起来很基础而且很繁琐。但真正执行起来一次也就多花10到15分钟。这15分钟换来的是评审人不再需要从一堆符号里猜意思而是能直接聚焦在业务正确性上。我后来在团队里统计了一下自从严格执行这份清单评审意见里结构性和风格类的问题基本清零真正剩下的都是逻辑和设计层面的讨论。4.2 写代码时的“一道菜做三次”经验先手写草稿再填充细节我过去是打开编辑器就顺着思路往下写边写边想最后代码结构跟着思维走当然会乱。被骂之后我学到的习惯是在写任何超过20行的逻辑前先在Notion上列一个提纲不是伪代码而是“这个函数要做什么事情、分哪三步、每一步输入输出分别是什么”。这个习惯的心理学根据很简单如果你脑子里只有模糊的“做一个批量处理”你写出来的代码一定会天然发散但如果你先梳理出“第一步筛选有效记录第二步映射成目标结构第三步写入存储并返回失败列表”接下来写代码无非是把每个步骤翻译成代码。这就像做菜先备料、定顺序、再开火比边炒边切菜要稳得多。有一次我拿到一个新需求和某个老接口逻辑非常相似。我第一反应还是复制老接口再改但想到“重复实现”被批评的教训于是我花了十分钟梳理老接口的结构发现三段逻辑里有两段是可以直接提取成公共方法的。改完之后新接口十几行就搞定了还顺便修了老接口里一个边界Bug。这次经历算是我第一次感受到“先想后写”带来的正反馈。4.3 用工具强制规范而不是靠意志力靠意志力守规范这件事在熬夜赶项目的时候基本是失效的。所以我后来把能交给工具的事情尽量交给工具形成了一条“工具链防线”编辑器保存时自动格式化统一缩进、引号、尾逗号风格类问题不需要人工参与。项目启用lint和静态检查并在pre-commit阶段挂上钩子代码不合规根本提交不上去逼着你在本地改完。为团队CI增加代码复杂度检查比如圈复杂度超过15直接警告函数体太大建议拆分。提交信息模板化很多Git工具都支持模板我直接把“模块原因影响”做成模板减少随便写的概率。这些工具的目的不是把开发者当贼防而是把规范的检查成本从人脑转移到机器。人容易疲劳、情绪化、双标机器不会。设置完之后我反而轻松了因为我不需要每次拧着自己的性子去“记着规范”而是沉浸在具体的业务逻辑里等提交的时候工具提醒我哪里违反规定我再回头修改。省下来的意志力可以用在真正需要思考的地方。5. 评审不再像批斗把代码评审从找茬变成共建的正确姿势5.1 被骂之后我才明白好的评审应该给“修改建议”而不是“评价结论”那场评审里同事的很多措辞其实挺“毒”的比如“服了”这种。他们说这些话不是恶意而是对我的代码产生了真实的情绪反应。但要是所有评审都是这种风格团队氛围迟早变得人人自危。我们团队在做了一次复盘后决定把评审表达方式统一成“以建议为主、以问题为辅”的框架。具体说就是每一条评论尽量包含三个要素问题在哪、为什么是问题、建议怎么改。比如“这里的魔法数字100代表什么如果是vip阈值建议定义一个VIP_THRESHOLD常量以后调整也方便”。同一个意思这种表达方式就让人听了没那么刺耳而且直接把解决方案给了出来对方能马上行动。这叫把评审从批斗变成共建。当然我也提醒自己对别人提这种建议的前提是对事不对人。我在后来给新同事评审的时候会尽量描述我“读代码时遇到的困难”而不是“你写的东西很糟糕”。比如我会说“我在这个函数里找了十分钟才确认超时是从配置获取的能否把配置来源统一到入口参数”这样对方更容易接受也更清楚改进方向。5.2 我把标准透明化把“我觉得不行”变成“我们商量好的规则”被骂的根源之一是每个人心中都有一套隐含的代码审美但没形成共识。你以为这不算什么他觉得这个是硬伤。后来我们几个人一起草拟了一份轻量级的“团队代码共识”把核心规则压缩到一页纸命名直白优先于简短、函数尽量不超过30行、常量必须有命名、提交信息必须包含模块和影响。遇到规则不明确的场景就拿到周会上讨论讨论完更新共识而不是靠个人喜好现场定夺。这份共识的好处特别大。它把原本一次次重复解释的规矩变成了一份大家共同署名的约定。再评审的时候我可以指着文档说“这是我们统一过的规则”而不是“听我的我觉得这不对”。前者是对事后者是让人感到被拿捏。经过这次整改我最大的收获之一就是让规范成为共识而不是某个人单方面的要求这样团队里每个人才会真的遵守而不是表面附和。5.3 不要在评审里争对错而是在合作里定取舍还有一次评审争议特别大同事认为我的写法在某种极端场景下会有性能风险要我用缓存。但我知道那个极端场景很久才会出现一次如果加缓存反而会让代码复杂度上升。我们两个在评审里差点吵起来。后来我反思到设计取舍的问题和明显违规不同不适合用“规范”一锤定音。我们的处理方法是在代码里加上一段注释说“考虑在极端高并发场景可能性能不足若未来该场景出现的频率上升应引入缓存”然后评审通过、需求合并。这种做法的好处是把权衡的过程显性化了后来人读代码时能知道当时的上下文不会在不知情的情况下踩坑。这个经验让我意识到一件事规范不是用来消灭所有争议的而是用来让争议更快暴露并得到记录。评审里可以保留不同意见只要有形成记录、及时验证的机制就行。这种开放心态也是从被骂中学到的——我挨骂是因为有些规则原本是共享的我却自己悄悄偏离了而被骂之后最好的反击不是我一定要说服所有人而是我学会了在共识的框架里清楚地说出“我为什么这样选择”。6. 把“怕被骂”内化成“不想写烂代码”规范意识的长期养成6.1 关注自己代码的阅读体验把日常练习当成评审预演现在每当我写完一段代码我会先站在“下个月接手这个模块的人”的角度去读一遍这个函数如果只扫一眼能看懂吗变量名传达的信息准确吗提交信息能让人快速定位到这次改动吗这就是一种预演把自己看作评审人。这个方法在养成习惯的初期特别有效。因为人对自己的代码自带光环很难客观。模拟“别人来看”之后突然就发现很多地方其实很迷惑。我现在的操作流程是写完一个功能先自己注释关键词在代码里搜索看能不能快速串联起整个流程如果不能说明结构还不够清晰一定还有下一步优化的空间。这个习惯看起来费时间但实际上把评审环节的返工风险降到了最低。我的评审评论数量在坚持这个习惯一个月后减少了七成。同事私下问我是做了什么东西我说就是“提交之前先自己挑自己毛病能挑出来的毛病就别留给别人挑”。6.2 用“最小知识量”持续复习规范一页纸够用不贪多规范的长期养成最忌讳的就是贪多嚼不烂。我以前总幻想一次性把所有规范背下来结果根本没坚持几天。后来我把团队的核心规范总结成不超过一页纸的“每日切面”放在桌面壁纸旁边。内容只有十条每一条都是之前被点评过、踩过坑或者容易忘的。我一个月会给自己做一次简单复盘翻出自己过去30天的提交记录看看有没有规范相关的评论。如果几乎没有说明这十条已经内化了那就可以挑战下一批规则。这个增量过程让我不再恐惧规范文档反而对“学会一条新规则”有了成就感。规范意识这东西没必要一下拉满关键是别让它断层。6.3 给刚开始改规矩的同行提醒避免从一个极端跑到另一个极端我想了一下如果这篇文章能让还在被批评边缘徘徊的人有所启发那最后一个提醒特别有必要不要从一个极端跑到另一个极端。有些人被骂之后开始走火入魔地追求代码整洁过度抽象、过度注释、为了拆函数而拆函数最后写出一种“看起来很规范但更难读”的代码。规范是手段不是目的。任何规范如果让代码更难理解和维护那说明你用错了。我在整改过程中也有过这个阶段。有一阵子我自己看自己以前的代码觉得哪里都不顺眼重构所有逻辑结果因为过度拆分导致调用关系变得很跳跃评审同事反而问“这个函数为什么只做一件事还要单独拎出来”。后来才明白抽象的粒度要和业务复杂度匹配简单逻辑不硬拆复杂逻辑必须拆这条平衡需要经验去积累。说到经验我最后总结一下自己从那次被骂惨里真正沉淀下来的东西编程规范不是给外人看的门面而是你和未来自己的约定。每一次命名、每一次提交信息、每一次抽取公共方法都是在降低未来某个人很可能还是你自己的认知负担。被骂不是最惨的结果最惨的是被骂了还不知道问题在哪、不知道怎么改、改完又犯。希望这篇复盘对你有点启发哪怕只抄走一份自查清单也算我那个晚上没白熬。