对于两个或多个事物，其中一个的改变不影响其他任何一个，则这些事物是正交的。
非正交系统天生就复杂，难以变更和控制。当系统的组件互相之间高度依赖时，就没有局部修理这回事。
消除不相关事物之间的影响（提示17）
我们希望设计的组件自成一体：独立自主，有单一的清晰定义的意图。当组件彼此隔离时，你知道可以变更其中一个组件，而不必担心影响到其他组件。只要不去改变组件的对外接口，就可以放心，不会发生波及整个系统的问题。
但凡编写正交的系统，就能获得两个主要的收益：提高生产力及降低风险。
获得生产力
- 将变更限制在局部后，开发时间和测试时间都会减少。
- 正交的方法同时促进了重用。
- 组合正交组件能获得相当微妙的生产力提升。
减少风险
- 代码中病变的部分被隔离开。
- 这样获得的系统不那么脆弱。
- 正交系统可能更利于测试，因为为其组件设计和运行测试更加容易。
- 你不会被特定的供应商、产品或平台紧紧束缚。
设计
分层的实现是设计正交系统的有力途径。因为每一层只使用它下面一层提供的抽象，所以可以在不影响代码的情况下极其灵活地更改底层实现。分层还可以降低模块之间依赖关系失控的风险。
可以用一个简单的方法来测试设计的正交性。当你规划好组件后，问问自己：如一个特别功能背后的需求发生显著改变，有多少模块会受影响？对于一个正交系统，答案应该是“一个”。
还要问问你自己，你的设计与现实世界的变化有多大程度的解耦。不要依赖那些你无法控制的东西。
工具包和程序库
在引入第三方工具包和程序库时，请注意保持系统的正交性。技术选择要明智。
编码
保持代码解耦
编写害羞的代码——模块不会向其他模块透露任何不必要的信息，也不依赖于其他模块的实现。
避免全局数据
只要代码引用全局数据，就会将自己绑定到共享该数据的其他组件上。即使只打算对全局数据进行读操作，也可能引发问题。
避免相似的函数
重复代码是结构问题的症状。
养成不断质疑代码的习惯。只要有机会就重新组织、改善其结构和正交性。这个过程被称为重构。
测试
基于正交性设计和实现的系统更容易测试。由于系统组件之间的交互是形式化的，且交互有限，因此可以在单个模块级别上执行更多的系统测试。
编写单元测试本身就是一个有趣的正交性测试。
修Bug也是评估整个系统的正交性的好时机。
文档
其涉及的两个独立维度是内容和呈现。真正符合正交性的文档，应该能够在不改变内容的情况下显著地改变外观。
