“一个菜鸟程序员拖垮了整个团队。”
最近，某互联网公司技术总监在内部复盘会上的一番话引发热议。他直言，团队里一个背着“三年经验”的程序员，写出的代码不仅逻辑混乱、注释寥寥，更严重的是，每次提交的代码都要耗费整个团队数小时去“擦屁股”。最终，这位程序员被优化。而取代他的，是一位被称为“代码诗人”的高手——他的代码，干净得就像散文诗。
裁员之后，总监把这位高手的代码片段分享出来，在圈内迅速刷屏。不是因为他用了多炫酷的技术栈，而是因为一个看起来简单却被大多数人忽略的习惯——“像我，但更像一个团队”。
这个习惯，本质上是一种“脱敏”式的代码思维，具体表现在三个方面。
第一，变量命名，不只为了自己明白。
菜鸟的代码里，充斥着 data、temp、res、a、b 这类“我懂就行”的命名。团队高手则不同，他习惯用业务语言命名：unpaidOrderList 绝不会写成 list1。更关键的是，他会在变量中体现“意图”，比如 isUserLoggedIn 而不是 flag。看一眼代码，就知道这段程序在“做什么”，而不是“怎么调”。
第二，模块拆分，量小但职责专一。
很多程序员喜欢在一个文件里塞进所有功能，动辄上千行。但高手团队的代码，每个函数小到只有十几行，功能单一到可以用一句话说清。他遵循了“单一职责原则”——不是理论上的背诵，而是一种肌肉记忆。他写的函数就像乐高积木，既可以复用，也方便替换。让代码不仅有“生命”，更有“边界”。
第三，注释，写的是“为什么”而不是“是什么”。
最让团队崩溃的代码，往往是没有注释或者注释纯属多余的代码。比如 i++ // i加1。但那位高手的注释，几乎全在解释“为什么这样做”——为什么这里要用缓存，为什么没有用排序，为什么选这个算法。他理解，代码是写给机器的，注释是写给人的。而一个项目能否活下来，靠的是人的理解，不是机器的执行。
这位总监说了一句话，让很多程序员反思：“你写的每一行代码，其实都是在声明：你愿不愿意让你的同事看懂。”
真正的高手，从不追求“炫技式”的复杂。他们把50%的时间花在可读性上，把30%的时间留给测试，剩下的20%才是真正的逻辑实现。而正是这份写在代码里的“对他人的尊重”，将他们与平庸区分开来。
那个走后，留下的不只是高手的代码，更是团队对代码“共同语言”的重新定义。从此，团队产出的代码风格趋同，逻辑一致，维护成本骤降。不仅是代码本身变好了，连团队氛围也变了——每个人开始考虑：“这样写，我的搭档能看懂吗？”
有时候，裁员不是残忍，而是为团队剔除一颗“毒丸”。而高手不是天生的，他只是比旁人多了这么一个习惯——在写代码的时候，心里永远住着一个陌生的“同行者”。
如果你还在为工作压力大、代码总出Bug而烦恼，不妨从今天开始，把代码当成“写给同事的情书”。因为这段代码，不仅此刻你在看，未来还有无数个“你”在看。
一个习惯的改变，或许就能把你从“裁员名单”拉回到“核心骨干”。高手的代码已经给你看了，剩下的，就看你自己了。