今天总结第五第六章的阅读心得
第五章 弯曲，或折断
26 解耦与得墨忒耳法则
使耦合减至最少
得墨忒耳法则
某个对象的任何方法都应该只调用属于以下情况的方法：
1）这个对象自己拥有的方法；
2）传入该方法的参数的方法；
3）该方法创建的对象的方法；
4）该对象直接拥有的对象的方法；
27 元程序设计
高度可配置，不需要重新编译，用纯文本来表示配置元数据可能是一种好的选择。
改变了配置，最好别让用户重启系统。
28 时间耦合
要提前考虑到程序的并发性。
29 它只是视图
发布/订阅模式
经典的MVC
30 黑板
黑板模式是一种常用的架构模式，应用中的多种不同数据处理逻辑相互影响和协同来完成数据分析处理。就好像多位不同的专家在同一黑板上交流思想，每个专家都可以获得别的专家写在黑板上的信息，同时也可以用自己的分析去更新黑板上的信息，从而影响其它专家。黑板模式的应用场景是要解决的任务可以分为多个子任务
第六章 当你编码时
31 靠巧合编程
软件开发者，每天就像工作在雷区，有成百的陷阱等着抓住我们。
多余的或不必要的代码可能这次能够正常运行，但换个环境可能就会崩溃，另外会使代码变慢，或引入新的bug。总之，不要靠巧合编程。
要想着尽可能在开发周期的早期抓住并修正错误，道理很简单，但在项目进度压力大的时候，把这句话忘在脑后。
为编码工作划定优先级，把时间花在重要的上面，经常也是最难的部分。但如果基础设施不正确，再花哨的界面或装饰也没有什么用。
32 算法速率
没有什么可说的，就是o()表示法。
33 重构
现在的IDE中的重构功能已经相当强大，真是太方便了。如果IDE里不支持重命名的重构，我会疯掉的。
如果发现了这些情况，说明需要重构了：重复、非正交的设计、过时的知识、性能。
1）不要试图在重构的同时加入新功能。
2）在开始重构前，确保你拥有良好的测试。
3）采用短小、深思熟虑的步骤，每一步都执行一遍你的单元测试代码。
34 易于测试的代码
编写单元测试会给别人（甚至是将来的自己）提供代码调用的例子，例于重构时的回归测试。
要使用xUnit之类的测试工具。
可以设置某种热键，让软件开发人员看到程序内部的错误日志。
35 邪恶的向导
不要使用你不理解的向导代码。
向导代码确实给你生成了一大堆代码，而且功能也很强大。但它们为你创建了代码，然后就走了。如果你不真正理解它们，将来就会给你带来麻烦。