第五章 弯曲或折断
26 解耦与得墨忒耳法则
尽可能写羞怯的代码，意思是不要让代码轻易暴露自己，不与太多人打交道。
得墨忒耳法则：方法只能调用（1）它自身 （2）传入的参数 （3）方法内创建的对象 （4）直接持有的类的对象。
27 元程序设计(metadata)
metadata的意思是关联数据，也就是一些细节数据。比如一些配置信息，调节参数，用户偏好之类的数据。使用Metadata的设计可以极大的增强设计的灵活性。
把抽象放进代码，细节放进元数据，要配置，不要集成在代码中。
28 时间耦合
程序应该为并发做好准备。分析工作流，改善并发性。
在编程的时候，要容许并发，考虑任何时间和次序上的依赖。分析出完成合理的工作流有助于规避时间耦合。
29 它只是视图
发布订阅模式：发布者持续发布数据，订阅者只订阅自己感兴趣的发布者，并遵循发布者的协议聆听数据。
MVC：不用多说了吧。
30 黑板
黑板方式的编程之前没有听说过。我的理解感觉这个模式很像redis之类的缓存系统，并且被多个client以同一的接口(键值对的读写)的形式访问。
黑板上有形形色色的各式各样的信息，但是是能以一种方式来获得，就是『看黑板』（单一接口）。
第六章 当你编码时
31 靠巧合编程
当你写代码时，首先明确你懂得你要写的东西，而不要『写写试试』。有可能你写出的程序只在某些场景下运行正确，但是在一些corner case中会失败，这就是靠巧合编程了。写代码难就难在对付corner case，有时不得不做出一些妥协。
32 算法速率
这里介绍很少，仅仅只是算法世界的沧海一粟。首先要会衡量程序的算法复杂度O，懂得几种常用算法的O是多少，懂得O(N2), O(log n), O(n)等等算法速率的区别。
33 重构
读Martin Fowler的《重构》吧。重构应该是随时随刻的。
34 易于测试的代码
别废话，多写测试。写测试也是一个程序自省的过程，不容易写测试的程序往往是设计很差的程序。
35 邪恶的向导
知其然，知其所以然。
第七章 在项目开始前
36 需求之坑
挖掘需求，建立需求文档，需求文档不能太细致，要保留合理程度的抽象
37 解开不可能解开的迷题
有时候问题的解决需要跳出常规的思维。或者简单一点，用另外一种方法，而不是钻牛角尖。
38 等你准备好
不打无准备的仗。没什么好说的。
39 规范陷阱
不要等万事具备才开始，因为不可能万事具备，用户总是在变。这一点契合敏捷的思想，快速做一个圆形，然后分期快速迭代。
40 圆圈与箭头
工具是拿来帮助加快开发，而不是束缚开发的。不需要被各式各样的UML规则搞得束手束脚，只需要画简单易懂即可。
第八章 注重实效的项目
41 注重实效的团队
软件的熵：对团队来说，保持一致的高质量十分重要，因为如果没有质量约定，软件的熵会持续膨胀，破窗户会到处都是。
煮青蛙：团队都是由一个不好的习惯而一点一点腐烂的，由于大家身处居中，很难察觉。
交流：敏捷的核心就是交流，just do the talking!
不要重复你自己：换言之，注意在碰到问题的时候看看文档，看看是不是已经有人记录过类似的坑。
正交性：按照合约，解耦，正交性的软件开发原则来分配团队职责。
42 无处不在的自动化
凡是有人参与的过程，肯定会产生错误。为了省事，也是为了减少错误发生的几率。单元测试，自动构建，集成测试，自动化测试
43 无情的测试
测试是为了保障代码的质量。所以越是仔细，全面的测试，越是有助于系统的健壮，不负责任的程序员或者测试，总是拿着可以正常运行的数据来进行着测试。有条件还是需要专职的测试，合格的测试，而不是那种连代码都看不懂的刚毕业的小姑娘。
44 全都是写
文档和注释。没什么好说的，我一直认为写作能力是程序员的第二能力。
45 极大的期望
达到客户的期望，才是软件真正的成功。问题是怎么抓住客户的期望。除了多交流以外，能在保证基本功能实现后，添加一些用户友好的功能，会很加分。比如快捷键，漂亮的UI，自动化安装等等。
46 傲慢与偏激
以傲慢的名义，留下自己的足迹。换言之，自己的锅自己扛。