第五章 弯曲或折断
解耦与得墨忒（tei）耳法则
1、把你的代码组织成最小单位（模块），并限制他们之间的交互。如果随后必须替换某个模块，其他模块仍能够继续工作。
2、应使耦合减至最少。对象间直接的横贯关系，有可能很快带来依赖关系的组合爆炸。比如对某个模块的“简单”改动会传遍系统中的一些无关模块。
3、函数的得墨忒耳法则，它规定了某个对象的任何方式都应该只调用属于以下情形的方法：它自身传入该方法的任何参数，它创建的任何对象，任何直接持有的组件对象。
4、得墨忒耳法则的好处是它使得代码的适用性更好，更健壮，但这也有一定的代价。如果某些解耦的操作很复杂，或者解耦带来某些时间和空间的重大开销，这时就需要根据实际情况考虑，可以暂时舍弃该法则。
元程序设计
1、元数据是关于数据的数据，即对应用进行描述的数据。典型情况，元数据在运行时，而不是编译时被访问和使用。
2、我们想要让我们的系统变得高度可配置，像是屏幕颜色，提示文本等，这些应该作为配置项而不是作为代码集成到项目中。
3、以声明方式思考（规定要做什么，而不是怎么做），并创建高度灵活的可适应的程序。结合元数据就是，将抽象放进代码，细节放进元数据。
4、Enterprise Java Beans 是一个用于简化分布式、基于事务的环境中的编程框架。它处理了不同机器、在不同数据库供应商之间，不同线程及复杂平衡的事务。它的使用只需我们编写一个 bean，并将其放到 bean container 中。
5、更好的协作式配置是让应用自身适应其环境，进行动态配置。
时间耦合
1、时间耦合就是关于时间的各种事项。
2、软件设计中，时间的角色通常有两方面对我们来说很重要：并发（事情同一时间发生）、次序（事情在时间中的相对位置）。我们期望的是要容许并发，并考虑解除任何时间次序上的依赖。
3、可以选择使用 UML 活动图进行工作流分析，以改善其并发性。
4、在设计架构时，用服务进行设计而不是组件。饥饿的消费者模型是在多个消费者进程间进行快速而粗糙的负载平衡的一种有效途径。
5、编写线性代码，我们很容易做出一些假定，把我们引向不整洁的编程。但并发会迫使你更仔细的对事情进行思考。
6、尽可能使用线程安全的类，开发时也应尽可能设计线程安全的类。
它只是视图
1、我们都知道应该将程序分而治之，划分成不同模块。这里模块（或类）的定义是，具有单一的定义良好的责任。那如何在不同模块之间进行通信，处理事件呢？有以下两种方式。
2、发布/订阅模式，又叫 Observer（观察者）模式。它的工作模式是，由订阅者 Subscriber 向发布者 Publisher 进行注册，注册之后，Publisher 的事件会通知到 Subscriber。未注册和解除注册将不会收到之后的事件通知。
黑板
1、设想侦探破案的过程，他借助于一块黑板，把不同线索写出来；其他侦探也可以写下自己的推断和已掌握的案情细节。所有这一切串联起来将共同帮助案件侦破，但不同的线索之间是可以独立进行的。
2、这里的黑板可以抽象为一种处理事件的模型。不同于原始的工作流需要考虑各种状况，不同组合，先后顺序等，黑板系统只管写入，读取，查询，通知等基础功能，任意符合条件的事件都可以进入这个系统。
3、黑板模型也是一种解耦形式。
靠巧合编程
传统智慧认为，项目一旦进入编码阶段，工作主要就是机械的把设计转换成可执行语句。我们认为，这种态度是许多程序丑陋、结构糟糕、不可维护的最大一个原因。编码不是机械工作，要想让程序长久无误的运行，每一分钟都需要做出决策，且需要对这些决策进行仔细的思考和判断。
1、靠巧合编程即代码正好是可运行的，至于为什么能够正常运行，却不清楚。这是我们应该极力避免的。
2、在打算重构某个看起来有问题的代码时，我们会面临这样的疑惑，是否有必要冒着把能工作的东西弄糟的风险呢？这时我们可以考虑一下几个理由：
它也许不是真的能工作，只是看起来能工作。你依靠的边界条件也许只是一个巧合。多余和没必要的调用会让你的代码变慢并增加新 bug 的风险。
算法效率
1、注重实效的程序员几乎每天都要使用估算，估算的资源包括：时间、处理器、内存等等。
2、估算算法即是我们熟知的时间复杂度，用O()表示，它有以下几种常见类型。
O(1)，常量时间，不随数据的多少变化
O(n)，线性时间，简单的循环
O(m*n)，嵌套循环
O(log(n))，二分法，平衡二叉树的查询
O(nlog(n))，分而治之，快排
O(2^n)，指数级，斐波那契数列
3、不同的时间复杂度在达到一定数量级的时候将相差很多，所以某些情况我们要想方设法优化算法的效率。我们主要需要关注的是是复杂度的阶。在确认了算法之后，还需要对其进行测试。
4、最好的并非总是最好的，是否使用最优算法，还需要根据我们遇到的实际情况。有时数据量很小的情况，算法的效率是可以忽略不计的。
重构
1、重写、重做和重新架构代码合起来，称为重构。
2、当代码出现以下特征，就应该考虑重构了：
出现重复内容，违反DRY原则。
非正交的设计。
知识过时了，或者你对某部分的了解更深一步。
对性能造成了影响。
3、重构的原则：早重构、常重构。重构面临的敌人通常都是时间，但这个借口并不成立，因为之后由此引发的时间额外消耗很可能更多。
易于测试的代码
1、软件 IC 是人们在讨论可复用性和基于组件的开发时喜欢使用的比喻。意思是集成电路芯片可以很容易的进行组合，我们希望软件开发也能达到这个效果。芯片的设计有完善的测试，同样的软件开发也可以做同样的事情。
2、针对合约进行测试及为测试而设计，即 TDD 测试驱动开发。
3、编写单元测试，对比较大的项目，将每个测试都放进一个子目录。
4、使用测试装备。构建一套完善的测试体系，它能够记录测试状态，分析输出结果是否符合预期，以及选择和运行测试。
5、推进测试文化，尽可能完善地测试你的软件，否则你的用户就得替你测试。
邪恶的向导
1、为什么称向导（wizard）是邪恶的呢，这是因为通过工具生成的代码，很容易被我们忽略，在这种情况下你编写的过程更倾向于靠巧合编程。
2、这里不是抵制向导代码，而是在强调，不要使用你不理解的向导代码。如果使用，一定要清楚它的机制。
3、开发每天都在使用不完全理解的事物，比如用于调度的算法、各种系统库的工作机制等。需要注意的是，这些属于底层依赖，他们也是向导，但不是应用本身的一部分，我们可以对这部分有所了解，但他们不属于邪恶的向导。
标签：重构,模块,读书笔记,小工,我们,程序员,算法,测试,代码 From： https://www.cnblogs.com/syhxx/p/16883480.html