序言：
当看到书本序言的时候，潜意识中，觉得这就是我想要的。序言中，行业人事强烈推荐的书籍，有一句话“这本书应该放在床头，不易外界，时刻翻阅”。书中全部都是经验之谈，正像《程序员的九堂课》中，给人的感觉是是曾相识的感觉。虽然只有一年工作经验的我，遇到了一个好的团队，遇到一个按规范行事领导者，书中的方法及经验，几乎都有涉及。很庆幸自己还能保持。
当然，书中的经验之谈，常用的方法，常谈的单元测试，特别是加粗的字体：注重实效的程序员。一直都在强调注重效率，不论是程序员、领导者。一加一往往可以大于二。书本的有总结书中的关键点，但是还是需要将原文看了一遍，在通过后面的关键点进行回顾。我觉得后面的就足以概括，所以记下来，提醒自己，让自己在正道走，追随前者区域的脚步。
1. 关心你的技艺
如果你不在乎能否漂亮的开发出软件，你又为何要消耗生命去开发软件呢？
2. 思考！你的工作
关掉自动驾驶仪，接管操作。不断的批评和评估你的工作。
3. 提供各种选择，不要找蹩脚的借口
要提供各种选择，而不是找借口。不要说事情做不到；说明能够做什么。
4. 不要容忍破窗户
当你看到糟糕的设计、错误的决策和糟糕的代码时，修正它们。
5. 做变化的催化剂
你不能强迫人们改变。相反，要想他们展示未来可能会怎样，并帮助他们参与对未来的创造。
6. 记住大图景
不要太过于专注细节，以致忘了查看周围正在发生什么。
7. 使质量成为需求问题
让你的用户确定项目真正的质量需求。
8. 定期为你的知识资产投资
让学习成为习惯
9. 批判的分析你读到的和听到的
不要被供应商、媒体炒作、或教条左右。要依照你自己的看法和你的项目的情况去对信息进行分析。
10. 你说什么和你怎么说同样重要
如果你不能有效的向别人传达你了不起的想法，这些想法就好糊用处。
11. 不要重复你自己
系统中的每一项知识都有事必须具有单一、无歧义、权威的表示。
12. 让复用变得容易
如果复用很容易，人们就会去复用。创造一个支持复用的环境。
13. 消除无关事物之间的影响
涉及自足、独立、并具有单一、良好定义的目的的组件
14. 不存在最终决策
没有决策是浇筑在石头上的。相反，要把每项决策都视为是写在沙滩上的，并为变化做好计划。
15. 用曳光弹找到目标
曳光弹能通过试验各种事物并检查它们离目标多远来让你追踪目标。
16. 为了学习而制作原型
原型制作是一种学习经验。其价值并不在于产生所谓的代码，而是在于所学到的经验教训。
17. 靠近问题领域编程
用你的用户的语言进行设计和编码。
18. 估算，以避免意外发生
在着手之前进行评估。你将提前发现潜在的问题。
19. 通过代码对进度条进行迭代
用你在进行实现时获得的经验提炼项目的时间标度。
20. 用纯文本保存知识
纯文本不会过时。它能够帮助你有效的利用你的工作，并简化调试和测试。
21. 利用命令shell的力量
当图形界面无能为力时使用shell。
22. 用一种好的编辑器
编辑器应该是你的手的延伸；确保你的编辑器是可配置、可拓展和可编程的。
23. 总是使用源码控制
源码控制是你工作的时间机器--你能够回到过去。
24. 要修正问题，而不是发出指责
Bug是你的过错还是别人的过错，并不是真的很有关系--它仍然是你的问题，它任然需要修正。不要恐慌做一次深呼吸，思考什么可能是bug的原因。
25. 不要恐慌
做一次深呼吸，思考什么可能是bug的原因
26. “Select”没有问题
在OS或者编译器、甚或是第三方产品或库中很少发现bug。bug很可能在应用中。
27. 不要假定，要证明
在实际环境中--使用真正的数据和边界条件--证明你的假定。
28. 学习一种文本操纵语言
你用每天的很大一部分的时间处理文本，为什么不让计算机替你完成部分工作呢？
29. 编写能编写代码的代码
代码生成器能提高你的生产率，并有助于避免重复。
30. 你不可能写出完美的软件
软件不可能完美。保护你的代码和用户，使它们免于能遇见的错误。
31. 通过合约进行设计
使用合约建立文档，并检验代码所做的事情正好是它声明要做的。
32. 早崩溃
死程序造成的危害通常比有问题的程序要小得多。
33. 使用断言避免不可能发生的事情
断言验证你的各种假定。在一个不确定的世界里，用断言保护你的代码。
34. 将异常用于异常的问题
异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折磨。将异常保留给异常的事物。
35. 要有始有终
只要有可能，分配某资源的例程或对象也应该负责解除其分配。
36. 使模块之间的耦合减至最少
通过编写“羞怯的”代码并应用得墨忒耳法则来避免耦合。
37. 要配置，不要集成
要将应用的各种技术选择实现为配置选项，而不是通过集成或工程方法实现。
38. 将抽象放进代码，细节放进元数据
为一般情况编程，将细节放在被编译的代码库之外。
39. 分析工作流，以改善并发性
利用你的用户的工作流中的并发性。
40. 用服务进行设计
根据服务--独立的、在良好定义、一致的接口之后的并发对象--进行设计。
41. 总是为并发进行设计
容许并发，你将会设计出更整洁、具有更少假定的接口。
42. 使视图与模型分离
要根据模型个视图设计你的应用，从而以低廉的代码获取灵活性。
43. 用黑板协调工作流
用黑板斜边完全不同的事实和因素，同时又使各参与方保持独立和隔离。
44. 不要靠技巧编程
只依靠可靠的事物。注意偶发的复杂性，不要把幸运的巧合与有目的的计划混为一体。
45. 估算你的算法的阶
在你编写代码之前，先大致估算事情需要多长时间。
46. 测试你的估算
对算法的数学分析并不会告诉你每一件事情，在你的代码的目标环境中测定它的速度。
47. 早重构，常重构
就和你会在花园里除草、并重新布置一样，在需要时对代码进行重写、重做和重新架构。要铲除问题的根源。
48. 为测试而设计
在你还没有编写代码时就要思考测试问题。
49. 测试你的软件，否则你的用户就得测试
无情的测试。不要让你的用户为你查找bug。
50. 不要使用你不理解的向导代码
向导代码生成大量代码。在你把它们合并进你的项目之前，确保你理解全部这些代码。
51. 不要搜集需求--挖掘它们
需求很少存在与表面上。它们深深的埋在层层假定、误解个政治手段下面。
52. 与用户同一工作，以像用户一样思考
要了解系统实际上将如何被使用，这是最好的方法。
53. 抽象比细节活得更长久
“投资”于抽象 ，而不是实现。抽象能在来自不同实现和新技术的变化的“攻击”之下存活下去。
54. 使用项目词汇表
创建并维护项目中使用的专业术语和词汇的单一信息源。
55. 不要在盒子外面思考--要找到盒子
在遇到不可能解决的问题的时候，要确定真正的约束。问问你自己：“它必须要以这种方式完成吗？它真的必须完成吗？”
56. 等你准备好再开始
你的一生都在积累经验。不要忽略反复出现的疑虑。
57. 对有些事情“做”胜于“描述”
不要掉进规范的螺旋--在某个时刻，你需要开始编码。
58. 不要做形式方法的奴隶
如果你没有把某项技术放进你的开发实践和能力的语境中，不要盲目的采用它。
59. 昂贵的工具不一定能制作出更好的设计
小心供应商的炒作，行业教条、以及价格标签的诱惑。要根据工具的价值判断它们。
60. 围绕功能组织团队
不要把设计师和程序员分开，也不要把测试员和数据建模员分开。按照你的构建代码的方式构建团队。
61. 不要使用手工流程
Shell脚本或批文件会一次次的以同一顺序执行同样的指令。
62. 早测试，常测试，自动测试
与呆在书架上的测试计划相比，每次构建时运行的测试要有效得多。
63. 要到通过全部测试，编码才算完成
就是这样的。
64. 通过“蓄意破坏”测试你的测试
在单独的软件副本上故意引入bug，以检验测试能够抓住它们。
65. 测试状态覆盖，而不是代码覆盖
确定并测试重要的程序状态。只是测试代码行是不够的。
66. 一个bug只抓一次
一旦测试员找到一个bug，这应该是测试员最后一次找到它。此后自动测试应该对其进行检查。
67. 英语就是一种编程语言
像你编写代码一样编写文档：遵守DRY原则、使用元数据、MVC、自动生成，等等。
68. 把文档建在里面，不要栓在外面
与代码分离的文档不太可能被修正和更新。
69. 温和地超出用户的期望
要理解你的用户的期望，然后给他们的东西要多那么一点。
70. 在你的作品上签名
过去时代的手艺人为能在他们的作品上签字而自豪。你也应该如此。
检查清单
1. 怎样维持正交性
- 设计独立、良好定义的组件
- 使你的代码保持解耦
- 避免相似的函数
- 重构相似的函数
2. 应制作原型的事物
- 架构
- 已有系统中的新功能
- 第三方工具或组件
- 性能问题
- 用户界面设计
3. 架构问题
- 责任是否得到了良好的定义
- 写作是否得到了良好的定义
- 耦合是否得以最小化
- 你能否确定潜在的重复
- 接口定义和各项约束是否可以接受
- 模块能否在需要时访问所需数据
4. 调试检查清单
- 正在报告的问题是底层bug的直接结果，还是只是症状
- Bug真的在编译器里？在OS里？或者是在你的代码里？
- 如果你向同事详细解释这个问题，你会说什么？
- 如果可疑代码通过了单元测试，测试是否足够完整？如果你用该数据运行单元测试，会发生什么？
- 造成这个bug的条件是否存在于系统中的其他任务地方？
5. 函数的得墨忒尔法则
某个对象的方法应该只调用属于以下情形：
- 它自身
- 传入的任务参数
- 它创建的对象
- 组件对象
6. 怎样深思熟虑的编程
- 总是意识到你在做什么
- 不要盲目地编程
- 按照计划行事
- 依靠可靠的事物
- 不要只是测试你的代码，还要测试你的假定
- 为你的工作划分优先级
- 不要做历史的奴隶
7. 何时进行重构
- 你发现了对DRY原则的违反
- 你发现事物可以更为正交
- 你的只是拓展了
- 需求演变了
- 你需要改善性能
8. 劈开戈尔迪死结
在解决不可能解决的问题时，问问你自己：
- 有更容易的方法吗？
- 我是在解决正确的问题吗？
- 这件事为什么是一个问题？
- 是什么使它如此难以解决？
- 它必须以这种方式完成吗？
- 它真的必须完成吗？
9. 测试各个方面
- 单元测试
- 集成测试
- 验证和校验
- 资源耗尽、错误及恢复
- 性能测试
- 可用性测试
- 对测试自身进行测试