第1章 注重实效的哲学
4. 足够好的软件
欲求更好，常把好事变糟
—— 李尔王
这句话放到自己身上，真的是一点没错。本以为是只有自己有些完美偏执性，原来都有这个毛病呢。我总想把事情做完美，可总是不如意，要么时间就拖沓得过长，要么，弄出来的东西还是不满意。项目组打算实现一套基于IEEE802.15.4标准的低功耗侦听协议栈，所采用的硬件以前就有一套可用的协议栈，但是我们在使用的时候却没有重用已有模块，比如UART和RF模块，无非是觉得别人写得不符合自己的风格，觉得不完美。因此很长的项目时间都是在重写这部分代码，同时还要去重新调试验证，对于现在我们实验性质的项目而言，开发周期确实不那么重要，但是如果开发周期有限制的时候呢，我们可以很快的开始利用现有条件吗，除了要克服自己心理那么一点偏执性，应该还有很多其它的问题要去面对。
解决的关键在于知道何时止步。不要因为过度修饰和过于求精而毁损完好的程序。继续前进，让代码凭着自己的质量站立一会儿。它也许不完美，但不用担心：它不可能完美。
第2章 注重实效的途径
7. 重复的危害
DRY法则告诉我们，要把低级的知识放在代码中，它属于哪里；把注释保留给其他的高级说明。
提示11：不要重复你自己（DRY法则）
11. 原型与便笺
原型制作是一种学习经验。其价值并不在于所产生的代码，而在于所学到的经验教训。那才是原型制作的要点所在。
提示16：为了学习而制作原型
第3章 基本工具
18. 调试
提示24：要修正问题，而不是发出指责。
bug是你的过错还是别人的过错，并不是真的很有关系。它仍然是你的问题。
调试的思维方式
提示25：不要恐慌
在调试小心“近视”。要地址之修正你看到的症状的急迫愿望：更有可能的情况是，实际的故障离你正在管擦的地方可能还有几步远。并且可能设计许多其他的相关事物。要总是设法找出问题的根源，而不只是问题的特定表现。
19. 文本操纵
提示28：学习一种文本操作语言
推荐Perl。
20. 代码生成器
提示29：编写能编写代码的代码
第5章 弯曲，或折断
26. 解耦和得墨耳法则
使耦合减至最少
当我们要求某个对象完成特定服务时，我们想要它替我们完成该服务。我们不希望这个对象给我们一个第三方对象、我们必须对其加以处理才能获得所需服务。
组合爆炸：如果n个对象全都互相了解，那么对一个对象的改动就可能导致其他n-1个对象都需要改动。
提示36：使模块之间的耦合减至最少
函数的得墨耳法则
第6章 当你编码时
31. 靠巧合编程
提示44：不要靠巧合编程
怎样深思熟虑地编程
不要只是测试你的代码，还要测试你的假定。不要猜测；要实际尝试它。编写断言测试你的假定。
33. 重构
重写、重做和重新架构代码合起来，称为重构（refactoring）。
你应在何时进行重构
无论代码具有下面的哪些特征，你都应该考虑重构代码：
重复。
非正交的设计。
过时的知识。
性能。
提示47：早重构，常重构
怎样进行重构
但如果你无节制地撕毁大量代码，你可能会发现自己处在比一开始更糟的位置上。
1. 不要试图在重构的同时增加功能。
2. 在开始重构之前，确保你拥有良好的测试。尽可能经常运行这些测试。这样，如果你的改动破坏了任何东西，你就能很快知道。
3. 采取短小、深思熟虑的步骤：
34. 易于测试的代码
软件IC是人们在讨论可复用性和基于组件的开发时喜欢使用的比喻。意思是软件组件应该就像集成电路芯片一样进行组合。这只有在你使用的组件已知是可靠的时才能行之有效。
单元测试
硬件的芯片级测试大致等价与软件中的单元测试——在隔离的状态下对每个模块进行测试，目的是检验其行为。
针对合约进行测试
首先测试模块的子组件。一旦子模块得到了检验，就可以测试模块自身。
这一技术是减少调试工作的极好途径：我们可以很快专注于上层模块的问题源，而不用把事件浪费非在重新检查其子组件上。
提示48：为测试而设计
编写单元测试
通过使测试代码易于找到，你实在给使用你代码的开发者提供两样无价的资源：
1. 一些例子，说明怎样使用你的模块的所有功能。（就现有的项目经历来看，这真的很重要的！作为芯片模块的使用者，往往能从拿到的用户手册中找到测试代码是最让人惬意的事情。相信作为模块的提供者而言，编写测试代码也会给以后给使用者提供的技术支持减少了很多负荷。）
2. 用以构建回归测试、以验证未来对代码的任何改动是否正确的一种手段。
在C++中，通过使用#ifdef有选择地编译单元测试。
使用测试装备
可以实现为makefile和Perl脚本的组合。
构建测试窗口
与电路板或芯片不同，在软件中我们没有测试管脚，但我们可以提供模块的内部状态的各种视图，而不使用调试器。
含有跟踪消息的日志文件就是这样一种机制。日志消息的格式应该正规、一致。你也许想要自动解析它们，以推断程序所用的处理事件或逻辑路径。
35. 邪恶的向导
第8章 注重时效的项目
44. 全都是写
提示67：把英语当作又一种编程语言。
为项目制作的文档基本上有两种：内部文档和外部文档。内部文档包括源码注释，设计和测试文档，等等。外部文档是发运（？）或发布到外界的任何东西，比如用户手册。所有的文档都是代码的反应。如果有歧义，代码才是最要紧——无论好坏。
提示68：把文档建在里面，不要栓在外面。
代码中的注释
一般而言，注释应该讨论为何要做某事，它的目的和目标。代码已经说明了它是怎样完成的，所以再为此加上注释是多余的——而且违反了DRY原则。
注释源码给你了完美的机会，让你去把项目的哪些难以描述、容易忘记，却又不能记载在别的任何地方的东西记载下来：工程上的权衡、为何要做出某些决策、放弃了哪些替代方案，等等。
你可以为参数建立文档，但问问你自己，这是否子啊所有情况下都真的有必要。JavaDoc工具提倡的注释程度似乎是合适的：
