《程序员修炼之道 从小工到专家》读书笔记5

第27节 元程序设计

1、元数据是关于数据的数据，即对应用进行描述的数据。典型情况，元数据在运行时，而不是编译时被访问和使用。

2、我们想要让我们的系统变得高度可配置，像是屏幕颜色，提示文本等，这些应该作为配置项而不是作为代码集成到项目中。

3、以声明方式思考（规定要做什么，而不是怎么做），并创建高度灵活的可适应的程序。结合元数据就是，将抽象放进代码，细节放进元数据。

4、Enterprise Java Beans 是一个用于简化分布式、基于事务的环境中的编程框架。它处理了不同机器、在不同数据库供应商之间，不同线程及复杂平衡的事务。它的使用只需我们编写一个 bean，并将其放到 bean container 中。

5、更好的协作式配置是让应用自身适应其环境，进行动态配置。

第28节 时间耦合

1、时间耦合就是关于时间的各种事项。

2、软件设计中，时间的角色通常有两方面对我们来说很重要：并发（事情同一时间发生）、次序（事情在时间中的相对位置）。我们期望的是要容许并发，并考虑解除任何时间次序上的依赖。

3、可以选择使用 UML 活动图进行工作流分析，以改善其并发性。

4、在设计架构时，用服务进行设计而不是组件。饥饿的消费者模型是在多个消费者进程间进行快速而粗糙的负载平衡的一种有效途径。

5、编写线性代码，我们很容易做出一些假定，把我们引向不整洁的编程。但并发会迫使你更仔细的对事情进行思考。

6、尽可能使用线程安全的类，开发时也应尽可能设计线程安全的类。

第29节 它只是视图

1、我们都知道应该将程序分而治之，划分成不同模块。这里模块（或类）的定义是，具有单一的定义良好的责任。那如何在不同模块之间进行通信，处理事件呢？有以下两种方式。

2、发布/订阅模式，又叫 Observer（观察者）模式。它的工作模式是，由订阅者 Subscriber 向发布者 Publisher 进行注册，注册之后，Publisher 的事件会通知到 Subscriber。未注册和解除注册将不会收到之后的事件通知。

3、Model-View-Controller 是一种将模型与表示模型的 GUI 分离的架构模型，它能有效降低数据和视图之间的相互影响。

第30节 黑板

1、设想侦探破案的过程，他借助于一块黑板，把不同线索写出来；其他侦探也可以写下自己的推断和已掌握的案情细节。所有这一切串联起来将共同帮助案件侦破，但不同的线索之间是可以独立进行的。

2、这里的黑板可以抽象为一种处理事件的模型。不同于原始的工作流需要考虑各种状况，不同组合，先后顺序等，黑板系统只管写入，读取，查询，通知等基础功能，任意符合条件的事件都可以进入这个系统。

3、黑板模型也是一种解耦形式。

第31节 靠巧合编程

从本节开始进入书目的第6章，本章主要讲在编码时应该注意的各类事项。传统智慧认为，项目一旦进入编码阶段，工作主要就是机械的把设计转换成可执行语句。我们认为，这种态度是许多程序丑陋、结构糟糕、不可维护的最大一个原因。编码不是机械工作，要想让程序长久无误的运行，每一分钟都需要做出决策，且需要对这些决策进行仔细的思考和判断。

1、靠巧合编程即代码正好是可运行的，至于为什么能够正常运行，却不清楚。这是我们应该极力避免的。

2、在打算重构某个看起来有问题的代码时，我们会面临这样的疑惑，是否有必要冒着把能工作的东西弄糟的风险呢？这时我们可以考虑一下几个理由：

• 它也许不是真的能工作，只是看起来能工作。
  
  
• 你依靠的边界条件也许只是一个巧合。
  
  
• 多余和没必要的调用会让你的代码变慢并增加新 bug 的风险。
  
  

3、如何深思熟虑的编程，有以下建议：

• 总是意识到你在做什么。
• 按照计划（设计）行事。
• 依靠可靠的事物而非假设。
• 不要只是测试你的代码，还要测试你的假定。
• 不要让已经做完的事情限制你的下一步，做好重构的准备。

第32节 算法效率

1、注重实效的程序员几乎每天都要使用估算，估算的资源包括：时间、处理器、内存等等。

2、估算算法即是我们熟知的时间复杂度，用O()表示，它有以下几种常见类型。

• O(1)，常量时间，不随数据的多少变化
• O(n)，线性时间，简单的循环
• O(m*n)，嵌套循环
• O(log(n))，二分法，平衡二叉树的查询
• O(nlog(n))，分而治之，快排
• O(2^n)，指数级，斐波那契数列

3、不同的时间复杂度在达到一定数量级的时候将相差很多，所以某些情况我们要想方设法优化算法的效率。我们主要需要关注的是是复杂度的阶。在确认了算法之后，还需要对其进行测试。

4、最好的并非总是最好的，是否使用最优算法，还需要根据我们遇到的实际情况。有时数据量很小的情况，算法的效率是可以忽略不计的。