《程序员修炼之道》读书笔记6

对于两个或多个事物,其中一个的改变不影响其他任何一个,则这些事物是正交的。
非正交系统天生就复杂,难以变更和控制。当系统的组件互相之间高度依赖时,就没有局部修理这回事。
消除不相关事物之间的影响(提示17)
我们希望设计的组件自成一体:独立自主,有单一的清晰定义的意图。当组件彼此隔离时,你知道可以变更其中一个组件,而不必担心影响到其他组件。只要不去改变组件的对外接口,就可以放心,不会发生波及整个系统的问题。
但凡编写正交的系统,就能获得两个主要的收益:提高生产力及降低风险。
获得生产力

  • 将变更限制在局部后,开发时间和测试时间都会减少。
  • 正交的方法同时促进了重用。
  • 组合正交组件能获得相当微妙的生产力提升。

减少风险

  • 代码中病变的部分被隔离开。
  • 这样获得的系统不那么脆弱。
  • 正交系统可能更利于测试,因为为其组件设计和运行测试更加容易。
  • 你不会被特定的供应商、产品或平台紧紧束缚。

设计
分层的实现是设计正交系统的有力途径。因为每一层只使用它下面一层提供的抽象,所以可以在不影响代码的情况下极其灵活地更改底层实现。分层还可以降低模块之间依赖关系失控的风险。
可以用一个简单的方法来测试设计的正交性。当你规划好组件后,问问自己:如一个特别功能背后的需求发生显著改变,有多少模块会受影响?对于一个正交系统,答案应该是“一个”。
还要问问你自己,你的设计与现实世界的变化有多大程度的解耦。不要依赖那些你无法控制的东西。
工具包和程序库
在引入第三方工具包和程序库时,请注意保持系统的正交性。技术选择要明智。
编码
保持代码解耦
编写害羞的代码——模块不会向其他模块透露任何不必要的信息,也不依赖于其他模块的实现。
避免全局数据
只要代码引用全局数据,就会将自己绑定到共享该数据的其他组件上。即使只打算对全局数据进行读操作,也可能引发问题。
避免相似的函数
重复代码是结构问题的症状。
养成不断质疑代码的习惯。只要有机会就重新组织、改善其结构和正交性。这个过程被称为重构。
测试
基于正交性设计和实现的系统更容易测试。由于系统组件之间的交互是形式化的,且交互有限,因此可以在单个模块级别上执行更多的系统测试。
编写单元测试本身就是一个有趣的正交性测试。
修Bug也是评估整个系统的正交性的好时机。
文档
其涉及的两个独立维度是内容和呈现。真正符合正交性的文档,应该能够在不改变内容的情况下显著地改变外观。

你可能感兴趣的:(《程序员修炼之道》读书笔记6)