2011年前我写过《事关“工程师思维”》，在那篇文章里所谈的“工程师思维”，指的是“一种可以把想法实现出来，一步步的变成现实的思维和实践训练”。两年过去了，工作和生活中的许多经历让我认识到，“工程师思维”不仅仅是一种思维和实践的训练，更是从多个方面体现出来的习惯，以下简单说说我的两点理解。 工程师思维的体现之一，是对于工具的执着。工程师不是赤膊上阵的莽夫，要完成自己的任务，必然离不开工具的支持，所以，优秀的工程师，必然从思想上重视工具。 我刚刚接触Linux下的开发时，是在一家当时国内有名的互联网公司。当时自己学了点vi，开始编写php程序。有天，一位同事从旁边走过，他忽然说：你的vim怎么没有颜色呢？然后不由分说，抢过我的键盘噼啪一顿敲，瞬间编辑器就有了格式和颜色（其实就是加上了syntax语法文件）。当时我只是觉得新奇好玩，过了几天，随着程序不断变复杂，才发现开发效率相比之前已经大大提高；后来让我惊奇的是，原来那天帮我弄出颜色来的同事，正是公司的首席科学家；更让我惊奇的是，他负责的项目，基本是不用加班的，而且交付质量都相当出色。 这件事情我印象一直很深，一方面是因为身为首席科学家，愿意“屈尊”为新入门的同事配置工具（后来我才意识到，他所负责的项目之所以都能高质量的准时交付，离不开一个又一个的细节，对工具的执着就是其中之一）；另一方面，我也发现很多“工程师”并不那么在乎工具，更愿意坚守一些原始粗糙的工具（“粗糙”与“简单”不同，精心配置的vim当然不算粗糙的工具），你建议他们去换用新工具时，他们往往说“没事，我习惯了，再说也查不了多少”为理由拒绝（我认为这更多是思维上的懒惰）。更不幸的是，我见过的有这样习惯的人，基本都算不上优秀的工程师。两厢对比，我越发深刻地认为，“工程师思维”的一个重要方面就是对工具的执着，甚至既要对自己的工具精益求精，更容不下团队里其他人使用粗糙的工具。 工程师思维的体现之二，是对于流程的执着。工程不同于艺术，不需要天马行空的自如，工程的完成离不开严谨周密的步骤，只有执著于流程的工程师，才能够各种工程中贯彻严谨周密的步骤，从而减少变数，保证工程顺利完成。 许多开发人员都遇到过这样的情况：经常需要解决各种重复或者类似的问题，但是每次都需要花不少力气翻找之前的资料。我也曾遇到过这样的问题，直到有一天，发现某位同事有一个巨大的“脚本库”：无论我问他什么问题，他都可以迅速找出一个脚本，我只需要修改几个参数，就一定可以解决这个问题。 回头去想，这些脚本描述的就是解决某类问题的流程，它标明了具体的操作和步骤，保证任何人都可以照章解决某类问题，这种看似“与人无关、缺乏灵气”的方案，其实正是“工程思维”的体现，最大限度地减少了工程中的不可控因素。于是，我也逐渐积累自己的流程文档，更重要的是，在解决一个个问题的“个案”中，尝试从“流程”的角度观察和思考：这个问题是怎么解决的？前后分为几步？哪些步骤是和其它问题相通的？时间久了，既积累丰富了自己的流程文档，又强化了自己的思考能力。如果因为某些任务看似简单，就不去思考背后的流程，想凭“巧劲”手动解决，遇到真正复杂的问题，就没有化繁为简、系统解决的能力，如果问题重复出现，每次仍然需要手动处理，速度只能停在某个很低的水平。这样的表现，当然和“工程师”不挨边了。 如今流行的某种说法认为，中国人的理工科培训，造就了许多人的“工程师思维”。听起来，“工程师思维”似乎是某种不好的习惯，只知做事，不会思考；但在我看来，事实全然不是这样：“工程”是一门讲究实践、思考、经验总结的学问，而我国现行体制里教育出来的人，往往只擅长照章执行，根本谈不上“工程师”；无论是谁，想要具备真正的工程师思维，都离不开持续、专门的学习、思考和训练。
今天金山的刘鑫老师在邮件里谈到了“工程师思维”（工程师的思维能力，就是一种可以把想法实现出来，一步步的变成现实的思维和实践训练），借题发挥一下吧。 我上高中的时候，学校算是本市最好的中学，班主任物理老师也是特级教师，但我一直不是觉得，他讲课说不上多好，无非是循规蹈矩的套路，甚至有点死板——就拿受力分析的题目来说吧，多简单的题目，都要画坐标系，而且就只有那么几个力：重力、摩擦力、牵引力等等，来来去去地分解，真是麻烦，许多题目明明一眼就能看透的嘛。 到我大学快毕业的时候，辅导一个小朋友做高中物理题，忽然就让我改变了之前的看法：那是个很简单的问题，物体在斜面上的受力分析，我问他：这个题目要怎么想呢？出乎我所料的是，他胡乱画出了一堆力：扯力、顶力、拉力… 就在那一瞬间，我明白了，我们的物理老师的做法有多么高明：复杂问题是不能单纯依靠直观思维来解决的，我们往往需要从简单的情况中提炼出章法，再循序渐进，把章法练到纯熟，这样才有能力解决更复杂的问题。物理老师那看似繁琐的重复，其实就是在培养章法，把握问题的核心——做到了这一点，再复杂的问题，都可以一眼看到本质，而不会困扰、迷惑。 可惜的是，这样的思维和习惯，似乎还没有在我们身边扎下根基。我目力所及，看到的很多问题的解决方案，很多教育、探索和反思还只停留在对天赋、才气的吹捧和推崇上，而没有强调练习章法、探究规律、把握本质的工作。可是，才气、天赋等等都是太微妙的因素，难以把握，无法复制，也不易推广，甚至很可能遗失——研究中国古代科技史的李约瑟博士就指出，中国古代的发明有个特点是“重复发明”，前人发明了某件东西，后人不重视，于是失传了，直到许多年后，再由后人发明…… 在这方面，西方似乎比我们做的好得多，他们会有人不满足于直观的思维，努力探究日常生活各种现象背后的原理，总结出不依赖“才气”、“天赋”的章法，再经由一代又一代的人传承、积累，结果知识与生产力就像滚雪球一样，越来越多，能量也越来越大。 再举个例子，小时候我做过不少“智力题”：比如几个人各说了一句话，其中几个人说了真话几个人说了假话，让你判断到底谁说了真话谁说了假话；又比如河上有一条船，河边有狼、羊、人、草等等，一次只能渡两样过去，要怎样安排顺序，才能全部安全渡过去。这样的问题，我有一段时间做起来很快，也尝试总结过一些思路，但还是碰运气、凭感觉的成分居多，而且，这样的习题书，也没有告诉我们应该怎么解这类问题，它的本质是什么。直到后来学了离散数学，我才恍然大悟：第一个题目其实就是真值表，第二个题目其实就是图算法。问题提炼到了这个层面，就有现成的章法（或者说“套路”）解决了，再不需要什么才气、天赋：天赋再高、才气再旺盛，也无法大规模推广，也快不过计算机。于是，普通人也可以解决这类问题，其他人（也包括我们）的精力就不用再耗费摸索这类问题的答案上，而可以探索更加深入、更加新鲜、更有价值的问题。 我们还可以再举一个身边的例子：西方的很多书中，一个简单的道理，往往要翻来覆去地讲，非要把各个细节、各种情况都涉及了，才善罢甘休；许多人觉得很罗嗦、很累赘，他们关心的是“正对我胃口的知识”、“核心的结论”。但是，如果有时间认真研究这些细节，了解了各种情况，往往可以站在一个更高的角度来审视这些“核心的结论”，对它的认识更加全面——不但知道价值在哪里，也知道局限在哪里。 其实，这也是我当年阅读《精通正则表达式》之后的体会，在细细阅读了整本书之后，我不但了解了各种功能，用正则表达式解题的一般套路，也知道了在什么情况下要使用什么功能，更知道了什么情况下不应该使用正则表达式——这样的知识，很多就来自书中那些“繁琐”的内容。 正是因为有了这样的体会，我也奢望为大家提供一些这样的便利：《怎样翻译更地道》系列文章尝试总结一些应对翻译难点的通用套路，希望读者遇到这类问题时，查到对应内容就可以解决；《正则表达式傻瓜书》希望重点讲明白的（也是本书的重点），不但有各种功能的应用场景和选择规则，还有正则表达式解题的思维步骤：归纳一个应用场景的文本特征（转化为对正则表达式的需求）；照这些特征一一写出子表达式，合理组合起来；最后优化整个表达式。掌握了这三步，并有意训练，就可以熟练准确地运用正则表达式，解决各种问题。 希望我可以努力做到。