The Pragmatic Programmer

2.软件的熵(entropy)

• Don't Live with Broken Windows.

3.石头汤与煮青蛙

• 每个人都会护卫他们自己的资源。这叫做“启动杂役”(start-up fatigue)。

• 人们发现，参与正在成功的事情要容易的多。

4.足够好的软件

• 让用户参与权衡

Make Quality a Requirements Issue
使质量成为需求问题

• 知道何时止步

5.你的知识资产

• 它们是有时效的资产(expiring asset)。

每年至少学习一种新语言
每季度阅读一本技术书籍
也要阅读非技术书籍

• 批判的思考

6.交流

• 了解你的听众

What do you want them to learn?
What is their interest in what you'have got to say?
How sophisticated are they?
How much detail do they want?
Whom do you want to own the in formation?
How can you motivate them to listen to you?

• 让文档美观

在今天，已经没有任何借口制作出外观糟糕的打印文档。

7.重复的危害

8.正交性

• 编码

让你的代码保持解耦
避免使用全局数据
避免编写相似的函数

9.可撤销性

如果某个想法是你唯一的想法，再没有什么比这更危险的事情了。

• 可撤销性

与我们开发软件的速度相比，需求、用户以及硬件变的更快。
要把决策视为是写在沙滩上的，而不要把它们刻在石头上。

• 灵活的架构

10.曳光弹

原型制作生成用过就仍的代码。曳光代码虽然简约，但却是完整的，并且构成了最终系统骨架的一部分。

11.原型与便笺

• 应制作原型的事物

原型制作是一种学习经验。其价值并不在于所产生的代码，而在于所学到的经验教训。

• 制作架构原型

主要组件的责任是否得到了良好定义？是否适当？
主要组件间的协作是否得到了良好定义？
耦合是否得以最小化？
你能否确定重复的潜在来源？
接口定义和各项约束是否可接受？
每个模块在执行过程中是否能访问到其所需的数据？是否能在需要时访问？

最后一项往往会产生最令人惊讶和最有价值的结果。

12.领域语言

有了适当的支持，你可以用大大接近应用领域的方法进行编程。你给了自己一个工具，能够让你更靠近他们的领域工作。

• 实现小型语言

易于开发还是易于维护？

14.纯文本的威力

• 杠杆作用

计算世界的每一样工具，从源码管理系统到编译器环境，再到编辑器及独立的过滤器，都能够在纯文本上进行操作。

15.shell游戏

GUI的好处是what you see is what you get。缺点是what you see is all you get。

17.源码控制

你可以运行自动的回归测试，确保当日的源码没有造成任何破坏。构建的自动化保证了一致性——没有手工过程，而你也不需要开发者记住把代码拷贝进特殊的构建区域。

18.调试

这是痛苦的事：
看着你自己的烦恼，并且知道
不是别人，而是你自己一人所致。

第一准则：Don't Panic

19.文本操纵

Learn a Text Manipulation Language.
它们（文本操纵语言）嘈杂、肮脏、而且还有点用“蛮力”。如果使用有误，整个工件都可能毁坏。

20.代码生成器

21.按合约设计

• 语义不变项

一定要把固定的需求、不可违反的法则与那些仅仅是政策（policy）的东西混为一谈。
语义不变项——它必须是事物的确切含义的中西，而不受反复无常的政策的支配。

23.断言式编程

• 让断言开着

即使你确实有性能问题，也只关闭那些真的有很大影响的断言。

27.元程序设计

• 元数据是关于数据的数据

• 元数据是任何对应用进行描述的数据——应用该怎样运行、它应该使用什么资源，等等。在典型情况下，元数据在运行时，而不是编译时被访问和使用。

30.黑板

• 任何规则集的输出都可以张贴到黑板上，并触发更为适用的规则。

• Using Blackboards to Coordinate Workflow 用黑板协调工作流

33.重构

• 与建筑相比，软件更像是园艺——它比混凝土更有机

• 不要对改动犹豫不决

• 不要试图在重构的同时增加功能

34.易于测试的代码

• 测试装备可以处理一些常用操作，比如记录状态、分析输出是否符合预期的结果、以及选择和运行测试。

• 测试应该是可组合的

35.邪恶的向导

• 向导是一条单行道——它们为你制作代码，然后就走了

36.需求之坑

• 需求很少存在与表面之上。通常，它们深深地埋藏在层层假定、误解和政治手段的下面

• 有一种能深入了解用户需求、却未得到足够利用的技术：成为用户

• 好的需求文档会保持抽象。在设计需求的地方，最简单的、能够准确地反映商业需要的陈述是最好的

• 需求不是架构。需求不是设计，也不是用户界面。需求是需要

37.解开不可解开的谜题

• 解开谜题的关键在于确定加给你各种约束，并确定你确实拥有的自由度

• 我们想先确定最为严格的约束，然后再在其中考虑其余的约束

38.等你准备好

• 软件开发仍不是科学，让你的直觉为你的表演做出贡献

• 把构建原型当做调查你的不适的一种方法时，一定要记住你为何这样做。你最不想看到的事情就是，你花了几个星期认真地进行开发，然后才想起来你一开始只是要写一个原型

39.规范陷阱

• 编写程序规范就是把需求归纳到程序员能够接管的程度的过程

• 但你可以确信，一旦他们看到运行的系统，你就会被各种变更要求淹没

• 有些选择常常只有在编码过程中才会显露出来

• 你应该倾向于把需求搜集、设计以及实现视为同一个过程

• 健康的开发过程鼓励把来自实现测试的意见反馈到规范中

40.圆圈与箭头

• 结构化程序设计——拥有长久的生命

• 盲目地采用任何技术，而不把它放进你的开发实践和能力的语境中，这样的处方肯定会让你失望

• Dont't Be a Slave to Formal Methods

• 要记住谁是主人。不要变成方法学的奴隶

41.注重实效的团队

• 质量只可能源于全体团队成员都做出自己的贡献

• 对外界而言，看上去沉默寡言的项目团队是最糟糕的团队

• 花 30 分钟设计一个滑稽的标志，并把它用在你的备忘录和报告上

• 认为项目的各种活动——分析、设计、编码、测试——会孤立地发生，这是一个错误。它们不会孤立发生。它们是看待同一问题的不同方式，人为地分割它们会带来许多麻烦。

• 如果夜间构建能够自动运行各种测试，为什么要手工完成测试表单呢？

• 知道何时停止绘画。抵抗不断画下去的诱惑

42.无处不在的自动化

• 文明通过增加我们不加思索就能完成的重要操作的数目而取得进步

• Don't Use Manual Procedures

• 使用 cron 我们可以自动安排备份、夜间构建、网站维护、以及其它任何可以无人照管地完成的事情

• 要让完全构建（full build）运行所有可用的测试。如果你没有定期运行测试，你可能会发现，应用因为3个月前做出的代码改动而失败。

• 自动化管理

43.无情的测试

• 好的项目拥有的测试代码可能比产品代码还多

• 因为我们不可能编写出完美的软件，所以我们也不可能编写出完美的测试软件。我们需要的对测试进行测试

• Use Saboteurs to Test Your Testing 通过“蓄意破坏”测试你的测试

• Test State Coverage, Not Code Coverage 测试状态覆盖，而不是代码覆盖

• 我们所说的“自动”意味着对测试结果也进行自动解释

• Find Bugs Once 一个bug只抓一次

44.全都是写

• 任何形式的文档都只是快照（snapshot）

• 要在每个网页上放上日期戳或版本号

45.极大的期望

• 在抽象的意义上，应用如果能正确实现其规范，就是成功的。遗憾的是，这只能付抽象的账

• 要设法让你的用户惊讶。请注意，不是惊吓他们，而是要让他们高兴。

46.傲慢与偏见

• Sign Your Work 在你作品上签名