极客时间-10x程序员工作法 学习笔记（八）设计

1. SOLID原则： 提到软件设计，大部分程序员都知道一个说法“高内聚、低耦合”，但这个说法如同“期待世界和平”一样，虽然没错，但并不能很好地指导我们的具体工作。人们尝试着用各种方法拆解这个高远的目标，而比较能落地的一种做法就是 Robert Martin 提出的面向对象设计原则：SOLID，这其实是五个设计原则的缩写，分别是

   • 单一职责原则（Single responsibility principle，SRP）

   • 开放封闭原则（Open–closed principle，OCP）

   • Liskov 替换原则（Liskov substitution principle，LSP）

   • 接口隔离原则（Interface segregation principle，ISP）

   • 依赖倒置原则（Dependency inversion principle，DIP）

2. 如果说设计模式是“术”，设计原则才是“道”。设计模式背后的设计原则更重要更本质，是道，而设计模式只是设计原则在具体场景下的派生，是术。设计模式并不能帮你建立起知识体系，而设计原则可以。想要写出符合某个设计模式的代码，在道和术上下足功夫：在“术”上下过功夫，才会知道“道”的价值，“道”可以帮你建立更完整的知识体系，不必在“术”的低层次上不断徘徊。

3. 单一职责原则： “一个模块应该仅对一类 actor 负责”，这里的 actor 可以理解为对系统有共同需求的人。

   1. 一个工资管理系统：有个 Employee 类，它里面有三个方法：

      • calculatePay()，计算工资，这是财务部门关心的。

      • reportHours()，统计工作时长，这是人力部门关心的。

      • save()，保存数据，这是技术部门关心的。

      之所以三个方法在一个类里面，因为它们的某些行为是类似的，比如计算工资和统计工作时长都需要计算正常工作时间，为了避免重复，团队引入了新的方法：regularHours()。接下来，财务部门要修改正常工作时间的统计方法，但人力部门不需要修改。负责修改的程序员只看到了 calculatePay() 调用了 regularHours()，他完成了他的工作，财务部门验收通过。但上线运行之后，人力部门产生了错误的报表。这是一个真实的案例，最终因为这个错误，给公司造成了数百万的损失。

   2. 上述问题解决方案，就是按照不同的 actor（财务部门、人力部门、技术部门） 将类分解。（单一职责原则就是给了你一个指导原则，可以按照不同的 actor 分解代码。）

4. 分层：分层并不是一个特别符合直觉的做法，符合直觉的做法应该是直接写在一起。从jsp到前后端分离，前后端又各自分了好几层，那为什么要分层呢？原因很简单，当代码复杂到一定程度，人们维护代码的难度就急剧上升。一旦出现任何问题，在所有一切都混在一起的代码中定位问题，本质上就是一个“大海捞针”的活。其实就是任务分解：人们擅长解决的是小问题，大问题怎么办？拆小了就好。（分而治之） 一道很难的数学题，需要一步一步拆解计算，每一小步都是很简单的计算，难题就迎刃而解了。

5. 分层真正的价值：构建一个良好的抽象。 比如：1.网络模型的分层架构实现得太好了，好到你作为上层的使用者几乎可以忽略底层。2.我作为一个程序员，每天写着在 CPU 上运行的代码，但是我根本不知道计算机底层是怎么运行的，是因为已经有编译器做好了分层，让我可以只用它们构建出的“抽象”——编程语言去思考问题。3.Node.js 的出现让 JavaScript 成为了一个更好的抽象。有了分层抽象，人们才能更好地在抽象的基础上构建更复杂的东西。构建抽象，最核心的一步是构建出你的核心模型。什么是核心模型呢？就是表达你业务的那部分代码，换句话说，别的东西都可以变，但这部分不能变。

6. 用简单技术解决问题，直到问题变复杂： 普通电商系统跟淘宝的本质区别是什么呢？不同的业务量：淘宝最初也是从别人那买的一个垃圾小系统，但是每次随着业务量的增长，原有技术无法满足需求，就需要用新的技术去解决这个问题。从业务上来说，这些系统都是一样的，但是从技术上来说，这些系统根本不是一个系统，因为他们面对的业务量根本不是一个量级。 只要业务在不断地发展，问题就会不断出现，系统就需要不断地翻新。一个很形象的比喻：把奥拓开成奥迪。 淘宝的工程师之所以要改进系统，真实的驱动力不是技术，而是不断攀升的业务量带来的问题复杂度。 所以，评估系统当前所处的阶段，采用恰当的技术解决，是我们最应该考虑的问题。为了技术而技术的程序员不在少数，过度使用技术造成的结果就是引入不必要的复杂度，甚至难以维护。即便用了牛刀杀鸡，因为缺乏真实场景检验，也不可能得到真实反馈，对技术理解的深度也只能停留在很表面的程度上。