说说我理解的职业开发人员 -- 奋斗 -- IT技术博客大学习 -- 共学习 共进步！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

建议继续学习：