工程师教学

我教了十五年编程，工程最怕的师教不是学生写不出代码，而是工程他们太会写代码了。那种“会”，师教是工程照着模板敲出来的熟练，像复读机一样精准，师教却听不见自己的工程声音。

上周三的师教课上，我让学员调试一段内存泄漏的工程C程序。有个小伙子盯着屏幕二十分钟，师教最后举手说：“老师，工程我把它重写了一遍，师教用智能指针，工程问题就没了。师教”他确实解决了问题，工程但我问他：“原来的代码为什么泄漏？泄漏点在哪一行？”他愣住了。他根本没看那代码，他只是条件反射般地“修复”了它。

这就是问题所在。工程师教学，教的不是“怎么把代码跑通”，而是“怎么读懂代码为什么没跑通”。前者是操作工，后者才是工程师。操作工按按钮，工程师拆机器。

我见过太多人沉迷于框架的便利，却对底层原理一无所知。他们能用Spring Boot三天搭出一个网站，但问及HTTP请求如何被容器解析、Servlet线程模型如何工作，就支支吾吾。这就像开了一辈子自动挡汽车，却从不知道离合器长什么样——可一旦车子在陡坡上失灵，自动挡的电脑也会犯错，那时候你连挂一档自救的能力都没有。

真正的教学，得让学生“笨”下来。我有个习惯，每学期第一节课都让他们用纯C语言写一个链表。不许用STL，不许用现成库。有人抱怨这太原始了，浪费时间。但两周后，当他们能自己画出内存里的指针指向图，能手动释放每一个malloc的节点时，再回去看那些高级语言的容器，眼神完全不一样了——他们看得见那层包装纸下面的东西。

另一个关键，是教他们“错误的价值”。现在的教育太追求“一次通过”了。学生交作业，恨不得编译器一个warning都不要有。可真实世界的代码，哪个不是从一堆红叉里爬出来的？我故意在演示代码里留几个bug，让他们来找。找到的人，我会表扬；找不到的人，我会带着他们一步步踩进坑里，再爬出来。这个过程很慢，但记忆深刻。就像学骑自行车，摔的那几跤比任何理论讲解都管用。

还有一点，是我近几年才想明白的——得允许学生用“笨办法”解决问题。有个女生做图像识别作业，别人都用现成的卷积神经网络，她偏要自己写边缘检测算子。结果准确率低得可怜，但她跑来跟我讨论时，眼睛里闪着光。她告诉我，她终于理解了高斯模糊为什么是那个公式，而不是只会调库函数。那一刻我意识到，教学的终极目标不是让他们成为工具的使用者，而是成为工具的理解者。哪怕理解得慢一点，哪怕走得弯路多一点，那都是他们自己的路。

说到底，工程师这行当，拼的不是谁记得的API多，而是谁在毫无头绪时，敢不敢打开那个报错的堆栈，一行一行地读下去。这种勇气和耐心，不是看教程看来的，是被一个严格的老师逼着，或者被一个固执的自己逼着，在一次次debug中磨出来的。

所以我的课上，从来没有“简单题”。每个问题都值得被拆开揉碎。代码是死的，但理解是活的。当你不再害怕那个红色的报错信息，而是把它当作一封来自机器的信，认真读、仔细回，你才算真正入了这行的门。至于那些快捷键、那些炫技的写法，都是后话。