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