工程师教程

我见过太多工程师把调试器当成测谎仪。工程代码不听话，师教就一行行打日志，工程像审讯犯人一样逼问变量。师教其实大多数bug根本不复杂，工程你只要盯着那行报错，师教往上一路读回去，工程十有八九能看见自己写的师教蠢话。

上个月我修一个内存泄漏，工程排查了整整两天。师教堆栈里全是工程第三方库的调用，看着就像迷宫。师教后来我干脆把那个对象的工程生命周期画在纸上——就一张A4纸，箭头加方框。师教十分钟后真相浮出来：我在回调里注册了一个监听器，工程却忘了在组件销毁时移除它。代码本身没毛病，是我自己把时序搞拧了。那个下午我对着那张纸发笑，调试器再先进，也救不了逻辑上的懒惰。

真正有用的技能，往往是那些没人写进文档里的东西。比如读代码的速度。老工程师扫一眼文件头部，就能猜出后面大概什么风格，变量命名有没有规律，作者是急性子还是强迫症。这跟读小说看文笔一个道理。我招人时总爱让他们讲自己上周写的代码，讲不清的，多半自己也没真懂。能画出来，说明脑子里有结构；只会复述语法，那叫翻译机。

结构这东西，说玄也玄，说白也白。我见过一个新人，把模块拆得比寿司还精细，每个文件就二三十行，接口倒是齐整，可拼起来跑不动，因为数据流在文件之间绕成了毛线团。后来我让他把三个文件合并成一个，删掉一半抽象接口，速度立刻上来了。他委屈地说：“设计模式书上不是这么教的。”我说，书教你用工具，没让你把房子盖成工具展览馆。

另一个极端是那种神人，一个函数写三百行，所有逻辑平铺直叙，像流水账日记。可这种代码居然好维护——因为顺着读就能看懂，不用跳来跳去。我认识一个做金融系统的老哥，他坚持所有核心逻辑必须能在一屏内读完，超过就拆，但不拆成函数，而是拆成流程。他说，屏幕就是人的工作记忆，超过一屏，脑子就开始偷懒了。

说到底，工程师的核心技能不是写代码，是对付自己的大脑。你得知道它什么时候在骗你，什么时候在偷懒，什么时候在假装努力。比如深夜改bug，越改越急，越急越乱，那会儿就该合上电脑去睡觉。第二天早上，往往开机第一眼就看见那个忽略的分号。这不是玄学，是大脑在疲惫时只会做模式匹配，不会做真正的推理。

还有件事，我磨了五年才学会——删代码比写代码更需要勇气。每次看到自己三个月前写的“优雅方案”，都想抽自己一巴掌。那会儿为了炫耀技巧，搞了一堆泛型和回调，现在读起来像在解谜。后来我立了个规矩：任何代码，如果下个月自己读着费劲，就重写。别心疼，那点“聪明”不值钱，值钱的是别人（包括未来的你）能顺利读下去。

工具会变，语言会换，但有些东西不变：把复杂的东西拆简单，把隐藏的东西显出来，把骗人的东西揪出来。这三件事做扎实了，什么框架来了都不慌。那些整天追新技术的，多半是基本功不牢，想靠框架补。可框架是别人的骨头，长不到你身上。你自己的骨架，得靠一次次debug、一次次重写、一次次对着白纸画图，慢慢钙化出来。

很赞哦!（19）