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

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

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

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

按:前段时间与章显洲共同参与了图灵出版公司Clean Coder中文版的翻译,这是我的译者序。

我在招聘时常问的一个问题是:在你过去的工作中,遭遇过哪些印象深刻的困难,最后是怎么解决的?依我的经验,简历写得再漂亮的人,如果这个问题答不好,大都可以直接忽略。为什么会有这种结论?因为我们需要招聘的不是“经历丰富”的人,而是“有职业素养的人”。你遇到的问题可能很容易也可能很难,但我看重的并不是问题的难度,而是解决问题的方式、步骤,以及反思的深度。拿恢复误删数据来说,这可能算非常简单的任务,我更感兴趣的是怎样分析问题,找了怎样的资料,采取了怎样的步骤,此后做了哪些措施来避免这种错误再次出现。在我看来,相比问题本身的难度,解决问题的方式和步骤,以及反思的深度,都体现出一个人的职业素养。

是的,上面我两次提到了“职业素养“。相比起“专业主义”、“职业化”等说法,我更喜欢用它来翻译Professionalism,因为素养强调的并不是天赋的神秘,也不是技艺的高深,而是持续积淀的结晶:一方面,它体现了能力和素质,另一方面,它又强调了持续的积累和养成。甚为职业开发人员,基本技能不够熟练,当然谈不上职业素养;但是能迅速地编写代码,却不关心代码背后的意义,不能迅速判断、解决程序运行中的各种问题,自信满满地为自己交付的程序承担责任,同样是与职业素养绝缘的——许多所谓的”高手“,其实正是缺乏职业素养的典型。

当然,这只是我对于“职业素养”的理解。由个体经验总结的“职业素养”,多有一鳞半爪的嫌疑,所以即便你觉得上面说的有道理,难免感觉只见树木,不见森林。其实真正的”职业素养“绝不限于上述几方面,而是要广阔得多,深刻得多。要想一窥技术人员“职业素养”的全貌,已经有很多现成的资料可以参考,Bob大叔的Clean Coder就是其中的佼佼者。

作为一本技术类书籍,Clean Coder中有相当的内容,是介绍纯技艺的方面,比如测试驱动开发等等,自认已经算“职业开发人员”的人,大概对此并不感冒(不过,我仍然建议你认真看看)。但其它的内容,绝对值得你感冒,比如:什么情况下应该对业务部门说“是”,说“是”意味着什么。如果你没有想过这些问题,或者没有明确的答案,不妨看看Bob大叔是怎么说的:

(说“是”时)你对自己将会做某件事做了清晰的事实陈述,而且还明确说明了完成期限(do with a clean end time)。那不是指别人,而是说的自己。你谈的是自己会去(will)做的一项行动(action),而且,你不是“可能(possibly)”去做,或是“可能做到(might get to it)”,而是“会(will)”做到。

就我所见,技术人员往往太容易说”是“,往往在没有明确目标和期限的情况下,就草率给出了确认的答复,而且并不将其视为自己的一种承诺。屡见不鲜的项目延期,有相当原因就是在这种不负责任的情况下说“是”所致。但是我们想想,似乎没有哪一个正经行业,会把不能完成任务的人视为“有职业素养的人”,软件行业也不能例外。

如果你觉得自己已经足够负责,懂得“是”背后所蕴含的意义和责任,也不过如此,我们不妨更进一步,看看关于说“否”。在第2章,Bob大叔介绍了两个项目搞砸的经过,他并没有像常见的所谓专家那样故作聪明地指出实施过程中出现了哪些问题,导致了失败,而是一针见血地指出:这两个项目之所以会搞砸,因为开发人员没有坚决抵制各种不专业的需求(比如一些无关紧要但成本巨大的需求),抵制各种不专业的行为(比如为了赶工期而降低对程序质量的要求),最终只好喝下自己酿出的苦酒。对此,Bob大叔总结道:

有时候,获取正确决策的唯一途径,便是勇敢无畏地说出“不”字……我们要明白,委屈专业原则以求全,并非问题的解决之道。舍弃这些原则,只会制造出更多的麻烦……

对我来说,这真是振聋发聩的号角。而且,这种思维,这种视角,其实是许多技术人员所不屑或者不愿面对的——最初我也这么认为,但尝试在工作中主动说了几次“不”之后,我逐渐发现:花三分的力气去抵制无理的需求,可以节省十分甚至二十分的开发时间;相反,自欺欺人地说服自己凑合接受了无理需求,往往会非常被动乃至无法脱身,到最后,项目就落得著名的IBM
OS/360操作系统的下场,越挣扎,巨兽就越深地陷入泥潭。

要学习这样的道理,当然也可以参加培训班,听取授课或者阅读讲义,但那未免太显正经而缺乏亲和力。Bob大叔的特别之处在于,他总是可以通过浅显易懂的故事,清晰而敏锐地揭示了问题的核心所在。其中许多故事正是他自己亲身经历的,阅读过程中常会会心一笑,因为遇到了开发人员都懂的妙趣,比如费尽全力也是徒劳,无法让其他人理解“编辑程序的程序”;笑过之后,又会认识到许多道理——无法让其他人理解“编辑程序的程序”并不是真正的原因,真正的原因是:“客户……对功能的设想,其实经不起电脑前真刀真枪的考验……问题在于,东西画在纸上与真正做出来,是不一样的。业务方看到真正的运行情况时就会意识到,自己想要的根本不是这样。一看到已经满足的需求,关于到底要什么,他们就会冒出更好的想法——通常并不是他们当时看到的样子……真正的解决办法,是约定共同认可的验收测试标准,并在开发过程中保持沟通”。至少就我的经验,这一点是说的非常之对的。我曾经尝试在与业务部门确定目标原型之后,要求对方指派一个负责人,在IT部坐班,负责协商、跟进整个开发流程,确认每一点修改,这样既保证最终结果符合业务部门的需求,又提高了开发人员的工作效率,综合来看,成效相当可观。

类似的例子还有很多,在阅读这本书时,我经常会惋惜:如果早一点读到这本书,或许我之前就不会犯这样那样的错误,就能更早更好地积累自己的职业素养,另一方面,能有妙趣横生的书讲述看似枯燥的“职业素养”,对读者来说,又是一种幸运。德国作家托玛斯·曼曾经津津乐道于“斜躺在沙发上整天阅读叔本华”的美妙感觉,那是因为叔本华的文笔优美、流畅,可以把哲学变为惬意的享受。作为同时读过叔本华和Bob大叔的人,我想说,斜躺在沙发上整天阅读Clean Coder,认识和了解开发人员的职业素养,同样是相当惬意的享受。

应人民邮电出版社图灵公司的邀请,我有幸参与了Bob大叔所著Clean Coder(不是Clean Code)的翻译。

与前作Clean Code不同,这本书着重讲述的是开发人员的“职业素养”,也即职业开发人员应当如何做事。在阅读中,我时常会忍俊不禁,也会拍案叫绝,感叹Bob大叔把深刻的道理讲得这样通透。我虽然没有Bob大叔那样好的文笔,不过对“开发人员的职业素养”这个话题,也有很多话想说,索性分几个方面写下来。

学习

开发人员在工作之前,一般都已经经过大学阶段的专业学习。众所周知,大学的很多课程已经相当落后,教材也非常保守,所以我见过的好开发人员,不少都是自学成才。但是,这些问题并不能否认通过专业课程学习知识的意义,职业开发人员理解的“学习”,应当明确地区分知识、课程、教材:知识是重要的、稳定的,课程和教材是不那么重要的、变化的。

可以非常肯定地说,数据结构、编译原理、操作系统这类知识,是整个计算机世界的基石,是任何时候也不会过时的。即便毕业后不从事专门的科研,这类知识也会从你接触到的各种现象中体现出来。我在大学时基本抛弃了学校指定的课程和教材,但自己反复啃过影印版的《现代操作系统》,反复做过北大屈婉玲老师的三本《离散数学习题集》,后来在工作中受益匪浅——调优程序的性能,很可能需要理解调度、死锁、用户空间与系统空间等知识;重构复杂的布尔逻辑,很可能要依赖数理逻辑中的定律。如果当时没有反复的研习,没有深入理解这背后的原理,并且没有领悟到这些原理和各种现象之间的联系,遇到很多问题我很可能就会两眼抓瞎,充其量凭经验试错,无论如何,其效率远不及知识体系指导下的实践。

据我观察,大学生之所以对课程不感冒,除去学校和教师的原因,另一个因素是,几乎很少有教材能把看起来乏味的原理,和生活中遇到的问题讲清楚。学习图算法时,你是否想过“人、狼、羊、草过河”的问题可以直接由它来解决?学习内存管理时,你是否想过为什么Windows 95、Windows 98都那么容易蓝屏,到了Windows XP才有了长足的进步?我相信,如果能把原理与这类例子对应起来,你的理解就会深刻许多,印象也会深刻许多。不幸的是,这类“打通/联系”的工作,在国内教材基本是一片空白,国外教材也只有部分涉及。其结果就是,不少“有经验”的开发人员面对“32位机为什么只能支持4G内存”、“进程间通讯有哪几种方式,各有什么优劣”、“浮点数是怎么表示的,为什么是不准的”之类基本问题一脸茫然,不要小看了这些问题,不懂它们,你开发出来的程序只能凑合用,因为根子上就欠考虑,所以后期遇到问题要重构和调优,就会难比登天,最终搞到自己疲惫不堪。

对此,我的建议是:如果你现在还在学校,不妨仔细想清楚知识、课程、教材之间的关系,确定重要的知识,选择好的教材,自己安排自己的课程。如果你已经离开学校,而且感觉自己的基础并不牢靠,不妨从手头的工作开始,想想它用到了哪些原理,对应哪些知识,逐步、有针对性地补习。这其实并不难——我的朋友张东亮(@zhasm),之前几乎没有任何计算机基础知识,只是因为对正则表达式的爱好,找到了一份开发人员的工作,一年之后,他已经开始啃编译原理的书籍,而且确实学进去了。

以上说的主要是“专门”的学习,如果是工作之后的学习,会有很大的不同。

首先,工作之后的学习更多依靠自觉,没有几家公司会付出代价让员工像学生那样“学习”,所以更多时候,你只能花自己的时间、自己的金钱来学习。很多人一想到要花自己的时间,自己的金钱,心里就打了退堂鼓。要明确的是,公司没有老师那样强烈的责任培养员工“成长”,如果你找不到好的、薪水高的工作,很难责怪上一家公司没提供好的培训。所以,担心金钱和时间而放弃学习,最终的结果是自己的停滞,逐渐丧失竞争优势。相反,投入时间和金钱来学习,不但可以保持甚至扩大你的竞争优势,如果这种行为可以坚持、内化到生活中,也有助于保持健康、饱满的精神状态。

其次,工作以后的学习,需要努力摆脱工作环境的限制。我见过不少开发人员,因为工作限定在某个平台,某种语言,业余时间的学习便全部投入到这种平台、这种语言上,而没有思考自己是否合适做这些平台和语言,这些平台和语言是否处于没落期。在学校里,考分或许往往是唯一的度量,但在工作中,行将没落的语言和平台,你运用得再熟练,也于事无补。况且,过于专精于一门语言、一个平台,反而会限制你的思维和视野,影响迅速学习陌生知识的能力——要在短时间内熟悉陌生平台和语言的例子,在我们工作中并不少见,在整个IT业界中更是家常便饭。为了让它真的成为“便饭”,平时还是应当有意识地摆脱工作环境的限制,挑战自己的思维惯性。

责任

我曾经见过很多的简历,在“工作经历”里,项目描述写得天花乱坠,如何先进,如何复杂,采用了多少新技术,但是具体到个人责任,或者语焉不详,或者极其潦草。这样简历,体现的是责任感的缺失——对于自身责任没有明确的认知,也就没有足够的担当;这样的人,通常不用面试,就可以知道并不是合格的“职业开发人员”。

另一方面,我在面试时,经常会问两个问题,其中很重要的一个是:在你的工作经历中,收获最大或者印象最深的事件是什么。一般来说,如果能回答得有条理、有依据,大多可以判定为合格的职业开发人员。因为,有责任感的开发人员,大多不会把程序看成身外之物,更多地会把程序与自己的道德、声誉等等联系起来,甚至把程序看成自己的孩子;所以,必然会投入时间精力去总结、反思、完善、改进,就像照顾自己的孩子那样。其实,就我的经验看,真正的职业开发人员,不但能很好地回答这个问题,而且说起自己做过的事情,多有种充沛的自信感:XX项目是我做的,其特点是什么,我是如何如何做的,遇到什么问题,是如何解决的……涉及的技术不必很先进,开发的系统也不必很复杂,只要能够这么自信满满地一条条历数下来,你的职业素养就是无可厚非的。

业务

软件开发中,需求变化是无可避免的。虽然敏捷开发、极限编程宣称要“拥抱变化”,但真正做到拥抱变化,却是难上加难。原因在于:一方面,不少开发人员对变化本身就持怀疑甚至抵触态度;另一方面,许多需求完全是无规则、无理由地变化,不但造成极大的浪费,也严重影响开发人员的情绪。

这个问题非常普遍,也很严重。我思考了很久,发现比较合适的解决办法是进行角色的互换,尤其是开发方(包括开发人员),不能局限于“按照规程实现功能”的角色,而应当深入思考和理解业务。

不少开发人员最“理想”的工作环境就是:根本不关心自己的工作成果给谁用,怎么用,会产生什么结果,他们更喜欢这样的描述:什么类型的数据从哪里来,怎样处理之后,最后交给哪里。在架构清晰、流程完备的大公司里,或许你只需要安心填格子即可,但是拥有这样工作环境的开发人员,占总数的多少呢?更多的人面对的还是变化不定的需求,甚至连业务部门自己都不清楚自己要的是什么,这种情况下,只关心“数据从哪里来,怎样处理,交给哪里”之类的问题,无异于盲人骑瞎马,无异于挖坑埋葬自己。

相反,如果你清楚某个实现方案的缘由,知道它是基于何种应用场景,如何设计出来的,就可以在相当程度上把握它的价值和所需的工作量。如果更主动一些,可以和业务部门谈,这么做,将来会遇到什么问题,如果将来要改,哪些环节是可以改的,哪些环节是不能改的——如果你设身处地地为对方考虑,给出的建议一定比技术味道浓厚的“做不出来”更有说服力。如果做不到这么主动,你也可以预估,哪些业务是稳定不变的,哪些业务是一定会遇到问题需要改变的,然后可以合理分配工作量:对那些明显没什么前途的项目,可以适当保留资源,以免将来竹篮打水;对那些目前业务部门认为不重要,其实又相当有价值的项目,可以适当多投入精力,以免将来措手不及——要知道,业务部门提的“紧急”需求,多半不会考虑开发的工作量。

需要补充的是,做到上面这点,其实有相当的难度:一方面,你的技术功底必须足够扎实,在满足需求时,不仅仅是“模仿”现实,而应当知道这种现实,在数字世界里应当如何表达,如何重构,受到哪些条件和规则的限制(比如同一个抽象操作的不同实现,到底是选择Switch语句还是多态,其实是有章可循的,必须根据实际情况选择);另一方面,又要能跳开技术的局限,从更全面的视角理解、把握业务。不过,这是非常值得花功夫的——从某种意义上可以说,当前热门的“领域驱动开发(Domain Driven Development)”,说的大抵就是这回事。

时间

在软件开发中,时间绝对是一个非常重要的因素。在这方面,已经有无数的巨著,无数的案例,无数的先烈,但是时间,仍然是一个值得讨论的话题。

总的来说,人月是一个神话,我们不可能绝对精确地把握开发时间,但是这并不意味着,我们不能从某种程度上把握时间。我个人的经验是,计划是在现实参照下的不断调整和修正中逐渐准确的。最重要的,并不是确定远大的目标,然后限定多长时间必须完成;而是可以把大的项目拆分为不同的模块,把整个开发流程划分为不同的阶段。如果你的模块划分得足够细致,就可以以每个模块的工作量,相对准确地得知整个项目的耗时;如果你的流程划分得足够合理,就可以在各个阶段拿出看得见、用得着的结果,供业务方使用。这样,一方面避免了“到最后一起推出,却发现与业务方想象大相径庭”的尴尬;另一方面,在开发过程中,每个阶段结束,就可以提供一个阶段的生产力,作为开发方,在面对质疑时,有足够的资本和底气。

从个人方面,我注意到,职业开发人员还有另一个特点:就是可以相当精确地估计某个“小活”的工作量。以我自己和我的一些朋友为例,面对一些细致而且明确的需求,我们经常可以精确估计到工作量,时间精确到以半小时计。在紧密协作的“背靠背”编程中,我会说:现在是几点,所以我会在几点之前,给你提供怎样的功能,其行为是怎样的,接口是怎样的(行为和接口可以事先约定)。这样的自信,既要求对所需技术、会遇到难题的把握,也要求在头脑里对任务有完整清晰的模型。虽然难度不小,但能做到这一点,确实是职业素养的典型体现。

« Previous Page