读自《实现模式》
模式，即是针对特定问题的通用解决方案。
每个模式都承载这一点点理论，但实际编程中存在着一些更加深远的影响力，远不是孤立的模式所能概括的。
价值观是编程过程的统一支配性主题，影响在编程中所作的每一个决策。
价值观有普遍的意义，但往往难以直接应用；模式虽然可以直接应用，却针对的是特定情境；原则在价值观和模式之间搭建了桥梁。
价值观 -> 原则 -> 模式
模式描述了要做什么，价值观提供了动机，原则则把动机转化成了实际行动。
在为用哪种方式做事而争论的同时，如果在价值观、原则上存在根本层次分歧，那么首先要从价值观、原则上达成共识，不然就是在浪费时间。
价值观
1. 可读性（沟通）
编写出计算机能运行的代码很简单，编写出让人能很好理解的代码没那么容易。
在编程时，我们很容易从计算机的角度进行思考。但只有一面编程一面思考其他人的感受，才能写出更好的代码。
从经济学来说，软件的绝大部分成本都是在第一次部署以后才产生的。从经验来看，花费在阅读既有代码上的时间要比编写全新的代码长得多。
因此，为了减少阅读代码所带来的开销，就应该让它容易读懂。
2. 简单
代码中的复杂有两种：有些复杂性是内在的，他们准确反映了所要解决的问题的复杂性；另一些复杂性的产生则是因为我们忙着让程序运行起来，未认真考虑，从而造出了多余的复杂。
多余的复杂性降低了软件的价值：一是让软件正确运行的可能性降低，再是将来也很难进行正确的改动。
追求简单推动了软件的进化。
编程过程中如果发现某种简化会使程序难以理解，这时优先考虑可读性。
3. 灵活
同样，因为程序的绝大部分开销都是在第一次部署以后才产生的，所以程序必须容易改动。
灵活是衡量那些低效编码与设计实践的一把标尺。
但同时想象中明天或许会用得上的灵活性，可能与真正修改代码所需要的灵活性不是一回事。
这时候，保持简单性和大规模测试所带来的灵活性比专门设计出来的灵活性更为有效。
灵活性的提高可能以复杂性的提高为代价，因此在设计的度上需要有个权衡。
原则
原则是另一个的通用思想，比价值观更贴近与编程实际，同时又是模式的基础。
原则可以解释模式背后的动机。
1. 局部化影响
减少变化所引起的代价，因此在组织代码结构时，要保证变化只会产生局部化影响，避免连锁反应或者被扩散。
2. 最小化重复
这里的重复，仅先限制在真正意义上的副本性重复 —— 编码中从对应的领域到实现。
重复的来源之一，是复制。复制的越多，变化的代价、需要改动的代价就越大。
最小化重复也有助于局部化影响。
3. 将逻辑与数据绑定
可以理解为，将数据于行为绑定。比如类的封装。
4. 对称性
识别出代码的对称性，把它清晰地表达出来，代码将更容易阅读。
一旦阅读者理解了对称性涵盖地某一半，就能很快理解另一半。
5. 声明式表达
如，能写成一个语义清晰、功能相同的annotation，就绝不将其放在一个通用的工具类或方法中。
6. 变化率
变化率具有时间上的对称性。
把相同变化率的逻辑、数据放在一起，把不同变化率的逻辑和数据分离。
