哪里遇到问题了，就找个地方加个开关、加个检查、加个条件判断来处理掉。这导致不够系统化，引入了局部的分支点，会造成多流程的耦合交叉，扩展容易遗漏。

现象

我们的代码这种情况非常的多。

就是哪里遇到问题了，好，我们按照这个问题找个地方加一个开关，或加一个检查，或加一个条件判断来处理掉。

这导致的问题，就是不够系统化，引入了局部的分支点，但是对于整体的影响没有分析。

这个分叉会造成后续扩展的问题，扩展的时候压根不会注意到有这个分叉。而且类似的问题可能还会继续分叉。

不够系统化，这样会造成多流程的耦合交叉，扩展容易遗漏。

例子

比如我们关机对于资源的可见性的管理（主要是 image），没有统一的约束和要求。

克隆的时候发现路径不在，报错了，然后加一个 open 修复一下，其他流程也是一样。

哇，这完全是黑盒，完全没法分析和预判，就等错误暴露了修复。

比如 drbd 发现脑裂了，直接操作了 --discard-my-data，这样很有问题，这样上层还在正常的创建资源。

实际需要给 node 抽象状态，当然我们有个 failed 状态，但是这是完全不可用的状态，相当于是宕机状态。

那么你没有准备好的状态，需要独立抽象的。发现了脑裂，其实是需要修复的，标记为未准备好的状态，那么其他流程都根据这个状态决定自己的操作。这是一个解耦的操作。

反常识的组合

包括下面的检查，开启了灾难检查，又开了一个 flag 的情况下跳过检查，很奇怪。

为什么不直接统一为关闭灾难检查呢，或者就统一的 flag 文件。

两个组合在一起，还是相反意思的，非常反常识，非常不结构化、不系统化。

小结

  • 打补丁要面向对象，而不是针对流程打补丁；
  • 哪里遇到问题就加开关、加检查、加条件判断，会导致不够系统化；
  • 不够系统化会造成多流程的耦合交叉，扩展容易遗漏；
  • 给 node 抽象状态，其他流程根据状态决定自己的操作，是解耦的操作；
  • 两个相反意思的 flag 组合在一起，非常反常识、不系统化。