Brian Jenney 见过太多"自学成才"的陷阱。他创办的 Parsity 训练营里，有学员花了两年刷 LeetCode，面试时却被一道系统设计题打回原形——不是算法不会，是从来没见过生产环境里的代码是怎么腐烂的。
他算过一笔账：纯靠网课自学的工程师，平均要踩 18 个月的坑才能理解"为什么这段代码去年能跑，今年就成了定时炸弹"。而有资深工程师带的人，这个周期能压缩到 4 个月。差距不在智商，在反馈密度。
老工程师的代码审查，是最高效的纠错系统
Jenney 观察到一个反直觉的现象：很多新手害怕代码审查（Code Review），觉得是被挑刺。但 Parsity 的数据追踪显示，每周接受两次以上深度审查的学员，三个月后独立交付功能的成功率比对照组高出 67%。
关键不是审查次数，是审查者的经验厚度。一个经历过三次生产事故的老工程师，能在你的异常处理里嗅出隐患——这种嗅觉无法通过文档传递，只能在具体场景中被点破。
有个典型案例。某学员写了个用户注册接口，自测通过，单元测试覆盖 90%。资深工程师扫了一眼，只问了一个问题："如果第三方短信服务商超时 30 秒，你的数据库连接池会是什么状态？"学员愣住。两天后压测，连接池耗尽，服务雪崩。这个坑，文档里不会写，网课不会教，只有被坑过的人才会条件反射式地检查。
Jenney 把这类反馈称为"创伤后应激式指导"——老工程师的敏感点，全是伤疤。
模仿是第一步，但多数人模仿错了对象
新手常犯的一个错误：盯着开源项目的代码风格学。GitHub 上星标 10k 的仓库确实漂亮，但 Jenney 认为那是"博物馆展品"——经过多轮重构、注释完善、边界情况处理。新手直接模仿，就像学画画只临摹完成稿，永远不知道起草时的犹豫和修改痕迹。
他建议学员观察老工程师的"草稿状态"：需求刚下来时的第一反应、遇到阻塞时的调试路径、发现方案有坑时的回滚决策。这些实时决策的噪音，比最终提交的 clean code 有价值十倍。
Parsity 设计了一套"影子跟随"机制：学员不是接任务写代码，而是先看资深工程师怎么处理同类任务，记录对方在哪些节点停顿、搜索什么关键词、向谁发起询问。三周后，学员再独立执行相似任务，错误模式显著减少。
有个数据很有意思：跟随阶段记录的"停顿点"数量，和后续独立任务的完成质量呈正相关。停顿越多，说明工程师在隐性风险评估上越谨慎——这种谨慎是可以传染的。
反馈的时效性，比反馈的内容更重要
Jenney 对比过两种培养模式。A 组：学员写代码，周末统一提交，导师下周一给批注。B 组：学员写代码，两小时内必须有人看，有问题当场指出来。六周后，B 组的代码可维护性评分比 A 组高出 41%。
延迟反馈的问题在于，新手已经形成了错误的心理模型。周末提交的代码，学员可能早就忘了当时为什么那样写，导师的批注变成了"事后诸葛亮"的指责。而即时反馈时，学员的思维上下文还在，能立刻理解"这里如果换个写法，后面能省多少麻烦"。
Parsity 的导师响应时间被硬性规定在 90 分钟内。不是导师闲，是 Jenney 发现超过这个窗口，学员的纠错成本指数级上升。这个数值来自对 200 多名学员的追踪：90 分钟内获得反馈的问题，同类型错误复发率 12%；延迟到第二天的，复发率 38%。
有个学员在复盘里写："以前我觉得导师回太快是监控我，现在我知道，那是趁我还没把错误焊死在肌肉记忆里。"
资深工程师的"废话"，往往是压缩过的经验包
Jenney 注意到一个沟通断层。老工程师说"这个实现有点重"，新手听到的可能是风格偏好；老工程师说"先别优化"，新手可能理解为偷懒。实际上，"有点重"可能指"这个查询在数据量过百万时会触发全表扫描"，"先别优化"可能指"需求下周就变，现在写抽象层是给自己挖坑"。
他训练导师做"翻译"：把压缩过的判断展开成可理解的因果链。不是"这样不好"，而是"这样不好，因为去年我们类似的做法在促销时把数据库打挂了，当时用了三天才回滚"。
这种展开消耗时间，但 Jenney 认为值得。 Parsity 的导师每周花在"解释为什么"上的时间，平均是代码审查本身的两倍。效果是：学员在第三期项目时，已经能预判导师会挑什么刺，提前自我审查。
有个学员毕业两年后回来说，现在他自己带新人，终于理解当年导师为什么对某些"小问题"揪着不放——那些都是血换来的条件反射。
Jenney 最近在追踪一组对比数据：Parsity 毕业学员中，持续与资深工程师保持每周至少一次技术交流的人，三年内晋升到技术负责人岗位的比例是 34%；毕业后就"单飞"的人，这个比例是 11%。他还没想明白这到底是因果关系还是筛选效应，但他在下一期课程里加了一个环节：毕业半年后强制回访，检查学员是否还"蹭得到"老工程师的时间。
你的代码最近一次被资深工程师挑刺，是什么时候？
热门跟贴