新人培养，不能只靠“你先看代码”

很多新人进团队，第一句话就是：“你先熟悉一下代码。”

这句话太常见了。

说的人通常也没恶意。团队忙，项目赶，老同事手里都有活，先让新人自己看看，似乎是最自然的安排。

但问题是，一个陌生系统的代码，对新人来说就像一座没地图的城市。

他能看到街道，但不知道哪里是主路，哪里是小巷，哪里以前出过事故，哪里看起来破但不能随便拆。

新人刚进团队时，最怕听到一句话：“你先看代码。”

这句话听起来很正常，但很多系统不是靠看代码就能看懂的。代码里有历史妥协，有业务黑话，有现场特殊规则，还有很多当年没人写下来的判断。

新人看两周代码还不敢动，不一定是他能力差。

可能是团队没有给他一条能走进去的路。

一、看代码不是上手路径

代码当然要看。

但只看代码，很难建立完整理解。

新人需要知道的不只是“这个类做什么”，还包括：

这个系统服务什么业务。
哪些模块是核心链路。
哪些地方历史包袱比较重。
本地环境怎么跑。
提测和上线流程是什么。
出问题时看哪些日志。
团队默认的代码风格和质量标准是什么。

这些东西如果没人讲，新人只能靠猜。

猜得慢，就显得不主动。猜错了，就容易踩坑。

二、第一周最好给一张地图

新人刚来时，我觉得最重要的不是马上产出，而是给他一张地图。

这张地图不一定很正式，但要能帮助他建立方向感。

比如：

第一天：跑通本地环境，了解业务主流程。
第二天：看订单、客户、权限三个核心模块。
第三天：跟一次需求评审和一次代码 Review。
第四天：修一个低风险 bug。
第五天：和负责人过一遍系统问题和疑问。

这种安排比“你先看看”有效很多。

新人知道自己每天要完成什么，也知道遇到问题该问谁。

三、任务要小，但不能假

新人上手任务最好小一点。

但小不代表随便找一个无关紧要的边角任务。

太假的任务没有上下文，新人做完也不理解系统。

我更喜欢给新人安排“低风险、真链路”的任务。

比如一个真实 bug，一个小字段调整，一个后台列表优化，一个接口返回补充。任务不大，但能让他走完整个流程：理解需求、改代码、跑测试、提交 Review、提测、上线。

走完一次闭环，比看一周代码更有用。

四、反馈要及时，不要等试用期结束

新人最怕的是不知道自己做得怎么样。

代码交了没人看，问题问了没人回，任务做完也没人说哪里好哪里不好。时间久了，人会越来越没底。

技术负责人或者带教人要给及时反馈。

反馈不用很重，可以很简单：

这个地方处理得不错。
这里缺少异常判断。
这个命名不太符合团队习惯。
下次提测前先自己跑一下这几个用例。

及时反馈能帮新人调整方向。

等到一个月以后再集中说问题，很多习惯已经形成了。

五、培养新人其实是在整理团队知识

新人问的问题，有时会暴露团队自己的问题。

为什么本地环境这么难跑？为什么接口文档找不到？为什么这个字段没人敢改？为什么上线流程只有某个人知道？

这些不是新人不懂，而是团队知识没有沉淀。

所以培养新人不是单向付出。

它会逼团队把很多“老员工脑子里的东西”写下来、讲清楚、流程化。

从这个角度看，新人上手慢，有时不是新人慢，是团队的知识太散。

六、小结

新人培养不能只靠“你先看代码”。

代码只是系统的一部分。业务背景、模块边界、开发流程、质量标准、反馈机制，这些都要有人带着走一遍。

一个新人能不能尽快进入状态，不只看他个人能力，也看团队有没有给他一条能走的路。

把新人带好，其实也是把团队自己整理清楚。

本系列：