2011年前我写过《事关“工程师思维”》,在那篇文章里所谈的“工程师思维”,指的是“一种可以把想法实现出来,一步步的变成现实的思维和实践训练”。两年过去了,工作和生活中的许多经历让我认识到,“工程师思维”不仅仅是一种思维和实践的训练,更是从多个方面体现出来的习惯,以下简单说说我的两点理解。

工程师思维的体现之一,是对于工具的执着。工程师不是赤膊上阵的莽夫,要完成自己的任务,必然离不开工具的支持,所以,优秀的工程师,必然从思想上重视工具。
我刚刚接触Linux下的开发时,是在一家当时国内有名的互联网公司。当时自己学了点vi,开始编写php程序。有天,一位同事从旁边走过,他忽然说:你的vim怎么没有颜色呢?然后不由分说,抢过我的键盘噼啪一顿敲,瞬间编辑器就有了格式和颜色(其实就是加上了syntax语法文件)。当时我只是觉得新奇好玩,过了几天,随着程序不断变复杂,才发现开发效率相比之前已经大大提高;后来让我惊奇的是,原来那天帮我弄出颜色来的同事,正是公司的首席科学家;更让我惊奇的是,他负责的项目,基本是不用加班的,而且交付质量都相当出色。
这件事情我印象一直很深,一方面是因为身为首席科学家,愿意“屈尊”为新入门的同事配置工具(后来我才意识到,他所负责的项目之所以都能高质量的准时交付,离不开一个又一个的细节,对工具的执着就是其中之一);另一方面,我也发现很多“工程师”并不那么在乎工具,更愿意坚守一些原始粗糙的工具(“粗糙”与“简单”不同,精心配置的vim当然不算粗糙的工具),你建议他们去换用新工具时,他们往往说“没事,我习惯了,再说也查不了多少”为理由拒绝(我认为这更多是思维上的懒惰)。更不幸的是,我见过的有这样习惯的人,基本都算不上优秀的工程师。两厢对比,我越发深刻地认为,“工程师思维”的一个重要方面就是对工具的执着,甚至既要对自己的工具精益求精,更容不下团队里其他人使用粗糙的工具。

工程师思维的体现之二,是对于流程的执着。工程不同于艺术,不需要天马行空的自如,工程的完成离不开严谨周密的步骤,只有执著于流程的工程师,才能够各种工程中贯彻严谨周密的步骤,从而减少变数,保证工程顺利完成。
许多开发人员都遇到过这样的情况:经常需要解决各种重复或者类似的问题,但是每次都需要花不少力气翻找之前的资料。我也曾遇到过这样的问题,直到有一天,发现某位同事有一个巨大的“脚本库”:无论我问他什么问题,他都可以迅速找出一个脚本,我只需要修改几个参数,就一定可以解决这个问题。
回头去想,这些脚本描述的就是解决某类问题的流程,它标明了具体的操作和步骤,保证任何人都可以照章解决某类问题,这种看似“与人无关、缺乏灵气”的方案,其实正是“工程思维”的体现,最大限度地减少了工程中的不可控因素。于是,我也逐渐积累自己的流程文档,更重要的是,在解决一个个问题的“个案”中,尝试从“流程”的角度观察和思考:这个问题是怎么解决的?前后分为几步?哪些步骤是和其它问题相通的?时间久了,既积累丰富了自己的流程文档,又强化了自己的思考能力。如果因为某些任务看似简单,就不去思考背后的流程,想凭“巧劲”手动解决,遇到真正复杂的问题,就没有化繁为简、系统解决的能力,如果问题重复出现,每次仍然需要手动处理,速度只能停在某个很低的水平。这样的表现,当然和“工程师”不挨边了。

如今流行的某种说法认为,中国人的理工科培训,造就了许多人的“工程师思维”。听起来,“工程师思维”似乎是某种不好的习惯,只知做事,不会思考;但在我看来,事实全然不是这样:“工程”是一门讲究实践、思考、经验总结的学问,而我国现行体制里教育出来的人,往往只擅长照章执行,根本谈不上“工程师”;无论是谁,想要具备真正的工程师思维,都离不开持续、专门的学习、思考和训练。

今天金山的刘鑫老师在邮件里谈到了“工程师思维”(工程师的思维能力,就是一种可以把想法实现出来,一步步的变成现实的思维和实践训练),借题发挥一下吧。

我上高中的时候,学校算是本市最好的中学,班主任物理老师也是特级教师,但我一直不是觉得,他讲课说不上多好,无非是循规蹈矩的套路,甚至有点死板——就拿受力分析的题目来说吧,多简单的题目,都要画坐标系,而且就只有那么几个力:重力、摩擦力、牵引力等等,来来去去地分解,真是麻烦,许多题目明明一眼就能看透的嘛。
到我大学快毕业的时候,辅导一个小朋友做高中物理题,忽然就让我改变了之前的看法:那是个很简单的问题,物体在斜面上的受力分析,我问他:这个题目要怎么想呢?出乎我所料的是,他胡乱画出了一堆力:扯力、顶力、拉力…
就在那一瞬间,我明白了,我们的物理老师的做法有多么高明:复杂问题是不能单纯依靠直观思维来解决的,我们往往需要从简单的情况中提炼出章法,再循序渐进,把章法练到纯熟,这样才有能力解决更复杂的问题。物理老师那看似繁琐的重复,其实就是在培养章法,把握问题的核心——做到了这一点,再复杂的问题,都可以一眼看到本质,而不会困扰、迷惑。

可惜的是,这样的思维和习惯,似乎还没有在我们身边扎下根基。我目力所及,看到的很多问题的解决方案,很多教育、探索和反思还只停留在对天赋、才气的吹捧和推崇上,而没有强调练习章法、探究规律、把握本质的工作。可是,才气、天赋等等都是太微妙的因素,难以把握,无法复制,也不易推广,甚至很可能遗失——研究中国古代科技史的李约瑟博士就指出,中国古代的发明有个特点是“重复发明”,前人发明了某件东西,后人不重视,于是失传了,直到许多年后,再由后人发明……
在这方面,西方似乎比我们做的好得多,他们会有人不满足于直观的思维,努力探究日常生活各种现象背后的原理,总结出不依赖“才气”、“天赋”的章法,再经由一代又一代的人传承、积累,结果知识与生产力就像滚雪球一样,越来越多,能量也越来越大。
再举个例子,小时候我做过不少“智力题”:比如几个人各说了一句话,其中几个人说了真话几个人说了假话,让你判断到底谁说了真话谁说了假话;又比如河上有一条船,河边有狼、羊、人、草等等,一次只能渡两样过去,要怎样安排顺序,才能全部安全渡过去。这样的问题,我有一段时间做起来很快,也尝试总结过一些思路,但还是碰运气、凭感觉的成分居多,而且,这样的习题书,也没有告诉我们应该怎么解这类问题,它的本质是什么。直到后来学了离散数学,我才恍然大悟:第一个题目其实就是真值表,第二个题目其实就是图算法。问题提炼到了这个层面,就有现成的章法(或者说“套路”)解决了,再不需要什么才气、天赋:天赋再高、才气再旺盛,也无法大规模推广,也快不过计算机。于是,普通人也可以解决这类问题,其他人(也包括我们)的精力就不用再耗费摸索这类问题的答案上,而可以探索更加深入、更加新鲜、更有价值的问题。

我们还可以再举一个身边的例子:西方的很多书中,一个简单的道理,往往要翻来覆去地讲,非要把各个细节、各种情况都涉及了,才善罢甘休;许多人觉得很罗嗦、很累赘,他们关心的是“正对我胃口的知识”、“核心的结论”。但是,如果有时间认真研究这些细节,了解了各种情况,往往可以站在一个更高的角度来审视这些“核心的结论”,对它的认识更加全面——不但知道价值在哪里,也知道局限在哪里。
其实,这也是我当年阅读《精通正则表达式》之后的体会,在细细阅读了整本书之后,我不但了解了各种功能,用正则表达式解题的一般套路,也知道了在什么情况下要使用什么功能,更知道了什么情况下不应该使用正则表达式——这样的知识,很多就来自书中那些“繁琐”的内容。

正是因为有了这样的体会,我也奢望为大家提供一些这样的便利:《怎样翻译更地道》系列文章尝试总结一些应对翻译难点的通用套路,希望读者遇到这类问题时,查到对应内容就可以解决;《正则表达式傻瓜书》希望重点讲明白的(也是本书的重点),不但有各种功能的应用场景和选择规则,还有正则表达式解题的思维步骤:归纳一个应用场景的文本特征(转化为对正则表达式的需求);照这些特征一一写出子表达式,合理组合起来;最后优化整个表达式。掌握了这三步,并有意训练,就可以熟练准确地运用正则表达式,解决各种问题。

希望我可以努力做到。