专业主义

承担责任

不要破坏软件功能

软件开发很复杂，不可能没有bug，所有这不意味着追求完美，但这并不意味着你不用对它们负责；没人能写出完美的软件，但这并不表示你不用对不完美负责。

所谓专业人士，就是能对自己犯下的错误负责的人，哪怕那些错误实际上在所难免。所以，你要练习的第一件事就是“道歉”。道歉是必要的，但还不够。你不能一而再、再而三地犯相同的错误。职业经验多了之后，你的失误率应该快速减少，甚至渐近于零。失误率永远不可能等于零，但你有责任让它无限接近零。

1. 让QA找不出任何问题 因此，发布软件时，你应该确保QA找不出任何问题。故意发送明知有缺陷的代码，这种做法是极其不专业的。什么样的代码是有缺陷的呢？那些你没把握的代码都是！QA会发现bug吗？可能会吧，所以，准备好道歉吧，然后反思那些bug是怎么逃过你的注意的，想办法防止它再次出现。每次QA找出问题时，更糟糕的是用户找出问题时，你都该震惊羞愧，并决心以此为戒。
2. 要确信代码能正常运行 测试！一遍遍地测，翻来覆去、颠来倒去地测，使出浑身解数来测！实行自动化测试。写一些随时都能运行的单元测试，然后尽可能多地执行这些测试。我是在建议进行百分百测试覆盖吗？不，我不是在建议，我是在要求！你写的每一行代码都要测试。但是有代码不是很难测试吗？是的，但之所以很难测试，是因为设计时就没考虑如何测试。唯一的解决办法就是要设计易于测试的代码，最好是先写测试，再写要测的代码（测试驱动开发TDD）。

不要破坏结构

遵循软件设计原则和模式。成熟的专业开发人员知道，聪明人不会为了发布新功能而破坏结构。结构良好的代码更灵活。以牺牲结构为代价，得不偿失，将来必追悔莫及。所有软件项目的根本指导原则是，软件要易于修改。如果违背这条原则搭建僵化的结构，就破坏了构筑整个行业的经济模型。

如果你希望自己的软件灵活可变，那就应该时常修改它！要想证明软件易于修改，唯一办法就是做些实际的修改。如果发现这些改动并不像你预想的那样简单，你便应该改进设计，使后续修改变简单。

该在什么时候做这些简单的小修改呢？随时！关注哪个模块，就对它做点简单的修改来改进结构。每次通读代码的时候，也可以不时调整一下结构。这一策略有时也叫 “无情重构”：对每个模块，每检入一次代码，就要让它比上次检出时变得更为简洁。每次读代码，都别忘了进行点滴的改善。

这完全与大多数人对软件的理解相反。他们认为对可工作软件不断地做一系列修改是危险的。错！让软件保持固定不变才是危险的！如果一直不重构代码，等到最后不得不重构时，你就会发现代码已经 “僵化了“。

为什么大多数开发人员不敢不断修改他的代码呢？因为他们害怕会改坏代码！为什么会有这样的担心呢？因为他们没做过测试。话题又回到测试上来了。如果你有一套覆盖了全部代码的自动化测试，如果那套测试可以随时快速执行，那么你根本不会害怕修改代码。怎样才能证明你不怕修改代码呢？那就是，你一直在改。

专业开发人员对自己的代码和测试极有把握，他们会极其疯狂随意地做各种修改。他们敢于随心所欲修改类的名称。在通读代码时，如果发现一个冗长的方法，他们肯定会将它拆分，重新组织。他们还会把switch语句改为多态结构，或者将继承层次重构成一条“命令链”。简单地说，他们对待代码，就如同雕塑家对待泥巴那样，要对它进行不断的变形与塑造。

职业道德

必须精通的事项

• 设计模式。必须能描述 GOF 书中的全部 24种模式，同时还要有 POSA 书中的多数模式的实战经验。
• 设计原则 必须了解SOLID原则，而且要深刻理解组件设计原则。
• 方法。必须理解 ：XP、 Scrum、精益、看板、瀑布、结构化分析及结构化设计等。
• 实践 必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。
• 工件。必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图和决策表。

持续学习

读书，看相关文章，关注博客和微博，参加技术大会，访问用户群，多参与读书与学习小组。不懂就学，不要畏难。如果你是.NET 程序员，就去学学 Java; 如果你是 Java 程序员，就去学学 Ruby; 如果你是 C语言程序员，就去学学 Lisp; 如果你真想练练脑子，就去学学 Prolog 和 Forth吧！

了解业务领域

每位专业软件开发人员都有义务了解自己开发的解决方案所对应的业务领域。如果编写财务系统，你就应该对财务领域有所了解；如果编写旅游应用程序，那么你需要去了解旅游业。你未必需要成为该领域的专家，但你仍需要勤勉，付出相当的努力来认识业务领域。

开始一个新领域的项目时，应当读一两本该领域相关的书，要就该领域的基础架构与基本知识作客户和用户访谈，还应当花时间和业内专家交流，了解他们的原则与价值观念。

最糟糕、最不专业的做法是，简单按照规格说明来编写代码，但却对为什么那些业务需要那样的规格定义不求甚解。相反，你应该对这一领域有所了解，能辨别、质疑规格说明书中的错误。