1.4 职业道德
职业发展是你自己的事。雇主没有义务确保你在职场能够立于不败之地，也没义务培训你，送你参加各种会议或给你买各种书籍充电。这些都是你自己的事。将自己的职业发展寄希望于雇主的软件开发人员将会很惨。
有些雇主愿意为员工买各种书籍或送员工参加各种培训课程和会议。那样挺不错的，说明他们待你不薄。但可千万别就此认为这些是雇主该做的。如果他们不为你做这些，你就该自己想办法去做。
另外，雇主也没义务给你留学习时间。有些雇主会这么做，有些甚至要求你这么做。但是还是那句话，他们待你不薄，你应该适当表示感激。因为这些优待不是你理所当然就该享有的。
雇主出了钱，你必须付出时间和精力。为了说明问题，就用一周工作40小时的美国标准来做参照吧。这40小时应该用来解决雇主的问题，而不是你自己的问题。
你应该计划每周工作60小时。前40小时是给雇主的，后20小时是给自己的。在这剩余的20小时里，你应该看书、练习、学习，或者做其他能提升职业能力的事情。
你肯定会说：“那我的家庭该怎么办？还有我的生活呢？难道我就该为雇主牺牲这些吗？”
在此，我不是说要占用你全部的业余时间。我是指每周额外增加20小时，也就是大约每天3小时。如果你在午饭时间看看书，在通勤路上听听播客，花90分钟学一门新的语言，那么你就都能兼顾到了。
做个简单的计算吧。一周有168小时，给你的雇主40小时，为自己的职业发展留20小时，剩下的108小时再留56小时给睡眠，那么还剩52小时可做其他的事呢。
或许你不愿那么勤勉。没问题。只是那样的话你也不能自视为专业人士了，因为所谓“术业有专攻”那也是需要投入时间去追求的。
或许你会觉得工作就该在上班时完成，不该再带回家中。赞成！那20小时你不用为雇主工作。相反，你该为自己的职业发展工作。
有时这两者并不矛盾，而是一致的。有时你为雇主做的工作让你个人的职业发展受益匪浅，这种情况下，在那20小时里花点时间为雇主工作也是合理的。但别忘了，那20小时是为你自己的。它们将会让你成为更有价值的专业人士。
或许你会觉得这样做只会让人精力枯竭。恰恰相反，这样做其实能让你免于枯竭匮乏。假设你是因为热爱软件而成为软件开发者，渴望成为专业开发者的动力也正是来自对软件的热情，那么在那20小时里，就应该做能够激发、强化你的热情的事。那20小时应该充满乐趣！
1.4.1 了解你的领域
你知道什么是N-S（Nassi-Schneiderman）图表吗？如果不知道，那为什么不了解一下呢？你知道“米利型”（Mealy）和“摩尔型”（Moore）这两种状态机的差别吗？你应该知道的。你能不需查阅算法手册就可写出一个快速排序程序吗？你知道“变换分析”（Transform Analysis）这个术语的意思吗?你知道如何用数据流图进行功能分解吗？你知道“临时传递数据”（Tramp Data）的意思吗？你听说过“耦合性”（Conascence）吗？什么是Parnas表呢？
近50年来，各种观点、实践、技术、工具与术语在我们这一领域层出不穷。你对这些了解多少呢？如果想成为一名专业开发者，那你就得对其中的相当一大部分有所了解，而且要不断扩展这一知识面。
为什么要了解这些呢？这一行业发展迅速，许多旧见解似乎也已经过时了，不是吗？前半句似乎是显而易见的。确实，行业正迅猛发展，而有趣的是，从多个方面来看，这种进展都只是很浅层的。没错，我们不再需要为拿到编译结果苦等上24小时，我们也已经可以写出GB级别的系统，我们置身覆盖全球的网络之中，各种信息唾手可得。但另一方面，我们还是跟50年前一样，写着各种if和while语句。所以，改变说多也多，说少也少。
旧见解过时了这种说法明显是不对的。过去50年中产生的理念，已经过时的其实很少。有一部分理论确实在慢慢淡出，比如说“瀑布式开发”的理论确实不再流行了。但这并不表示我们不需要了解它，不需要知道它的长处和短处。
总的来说，那些在过去50年中来之不易的理念，绝大部分在今天仍像过去一样富有价值，甚至宝贵了。
别忘了桑塔亚纳的诅咒：“不能铭记过去的人，注定要重蹈覆辙。”
下面列出了每个专业软件开发人员必须精通的事项。
设计模式。必须能描述GOF书中的全部24种模式，同时还要有POSA书中的多数模式的实战经验。
设计原则。必须了解SOLID原则，而且要深刻理解组件设计原则。
方法。必须理解XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计等。
实践。必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。
工件。必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图和决策表。
1.4.2 坚持学习
软件行业的飞速改变，意味着软件开发人员必须坚持广泛学习才不至于落伍。不写代码的架构师必然遭殃，他们很快会发现自己跟不上时代了；不学习新语言的程序员同样会遭殃，他们只能眼睁睁看着软件业一路发展，把自己抛在后面；学不会新规矩和新技术的开发人员更可怜，他们只能在日渐沦落的时候看着身边人越发优秀。
你会找那些已经不看医学期刊的医生看病吗？你会聘请那些不了解最新税法和判例的税务律师吗？雇主们干嘛要聘用那些不能与时俱进的开发人员呢？
读书，看相关文章，关注博客和微博，参加技术大会，访问用户群，多参与读书与学习小组。不懂就学，不要畏难。如果你是.NET程序员，就去学学Java；如果你是Java程序员，就去学学Ruby；如果你是C语言程序员，就去学学Lisp；如果你真想练练脑子，就去学学Prolog和Forth吧！
1.4.3 练习
业精于勤。真正的专业人士往往勤学苦干，以求得自身技能的纯熟精炼。只完成日常工作是不足以称为练习的，那只能算是种执行性质的操作，而不是练习。练习，指的是在日常工作之余专门练习技能，以期自我提升。
对软件开发人员来说，有什么可以用以操练的呢？乍一听，这概念显得荒唐。但是再仔细想一会儿，想想音乐家是如何掌握演练技能的。他们靠的不是表演，而是练习。他们又是如何练习的呢？首先，表演之前，都需要经历过特别的训练，音阶、练习曲、不断演奏等。他们一遍又一遍地训练自己的手指和意识，保持技巧纯熟。
那么软件开发者该怎样来不断训练自己呢？本书会用一整章的篇幅来谈论各种练习技巧，所以在此先不赘述了。简单说，我常用的一个技巧是重复做一些简单的练习，如“保龄球游戏”或“素数筛选”，我把这些练习叫作“卡塔”（kata）[3]。卡塔有很多类型。
卡塔的形式往往是一个有待解决的简单编程问题，比如编写计算拆分某个整数的素数因子等。练卡塔的目的不是找出解决方法（你已经知道方法了），而是训练你的手指和大脑。
每天我都会练一两个卡塔，时间往往安排在正式投入工作之前。我可能会选用Java、Ruby、Clojure或其他我希望保持纯熟的语言来练习。我会用卡塔来培养某种专门的技能，比如让我的手指习惯点击快捷键或习惯使用某些重构技法等。
不妨早晚都来个10分钟的卡塔吧，把它当作热身练习或者静心过程。
1.4.4 合作
学习的第二个最佳方法是与他人合作。专业软件开发人员往往会更加努力地尝试与他人一起编程、一起练习、一起设计、一起计划，这样他们可以从彼此身上学到很多东西，而且能在更短的时间内更高质量地完成更多工作。
并不是让你花全部时间一直和别人共事。独处的时间也很重要。虽然我很喜欢和别人一起编程，但是如果不能经常独处，我也一样会发疯。
1.4.5 辅导
俗话说：教学相长。想迅速牢固地掌握某些事实和观念，最好的办法就是与你负责指导的人交流这些内容。这样，传道授业的同时，导师也会从中受益。
同样，让新人融入团队的最好办法是和他们坐到一起，向他们传授工作要诀。专业人士会视辅导新人为己任，他们不会放任未经辅导的新手恣意妄为。
1.4.6 了解业务领域
每位专业软件开发人员都有义务了解自己开发的解决方案所对应的业务领域。如果编写财务系统，你就应该对财务领域有所了解；如果编写旅游应用程序，那么你需要去了解旅游业。你未必需要成为该领域的专家，但你仍需要用功，付出相当的努力来认识业务领域。
开始一个新领域的项目时，应当读一两本该领域相关的书，要就该领域的基础架构与基本知识作客户和用户访谈，还应当花时间和业内专家交流，了解他们的原则与价值观念。
最糟糕、最不专业的做法是，简单按照规格说明来编写代码，但却对为什么那些业务需要那样的规格定义不求甚解。相反，你应该对这一领域有所了解，能辨别、质疑规格说明书中的错误。
1.4.7 与雇主/客户保持一致
雇主的问题就是你的问题。你必须弄明白这些问题，并寻求最佳的解决方案。每次开发系统，都应该站在雇主的角度来思考，确保开发的功能真正能满足雇主的需要。
开发人员之间互相认同是容易的，但把一方换成雇主，人们就容易产生“彼”“此”之分。专业人士会尽全力避免这样的狭隘之见。
1.4.8 谦逊
编程是一种创造性活动。写代码是无中生有的创造过程，我们大胆地从混沌之中创建秩序。我们自信地发布准确无误的指令，稍有差错，机器的错误行为就可能造成无法估量的损失。因此，编程也是极其自负的行为。
专业人士知道自己自负，不会故作谦逊。他们熟知自己的工作，并引以为荣；他们对自己的能力充满自信，并因此勇于承担有把握的风险。专业人士不是胆小鬼。
然而，专业人士也知道自己会摔跟头，自己的风险评估也有出错的时候，自己也有力不从心的时候。这时候，如果他们照照镜子，会看到那个自负的傻瓜正对着自己笑。
因此，在发现自己成为笑柄时，专业人士会第一个发笑。他从不会嘲讽别人，自作自受时他会接受别人的嘲讽。反之，他则会一笑了之。他不会因别人犯错就对之横加贬损，因为他知道，自己有可能就是下一个犯错的人。
专业人士都清楚自己的自负，也知道上天会注意到这种自负，并加以惩戒。如若果真遭遇挫折，最好的办法就是按照霍华德说的——一笑了之吧！