保留尽可能多的可选项

如果想设计一个便于推进各项工作的系统，其策略就是要在设计中尽可能长时间地保留尽可能多的可选项。

这句话是《架构整洁之道》第15章《什么是软件架构》中第一页上重点强调的话，uncle bob一定对这句话非常看重，整本书里无数遍地重复了这个意思。

这是一个说起来容易做起来难的规则，于有架构思维的程序员来说可能还容易，对于普通程序员来说，这句话就成了天书，特别是在项目压力非常大的情况下，在人员流动非常大的项目，几乎没有人会在乎软件的长期发展，要求保留尽可能多的可选项就好比要每个人都做和尚，每天看着酒肉却坚守戒律，在软件设计这么主观和多变的领域，戒律是约等于零的，你看有几个能忍住不喝酒吃肉。例子不太恰当，但意在表达架构守护之难。

去年底今年初的时候主持拆了一个组件，拆的过程很痛苦。这个组件是由两个组件合并来的，后来又决策拆成了两个组件。在合并的这段时间，两个组件逐渐长在了一起，互相调用、频繁访问，导致组件拆分非常困难，这就是违反“保留尽可能多的可选项”的一个典型例子，按照这个原则的话就要求虽然两个组件合并了，但仍要求按两个组件进行设计。

我在学校是做过数据库相关的不少项目的，现在想来当年的设计真的非常简陋，好在都是周期不长的小项目，没有出多大乱子。上周面试了一位学软件工程的同学，在他做过的项目里正好涉及数据库，于是我想看一下学软件的同学是否也像我当年（我学通信的）一样缺乏设计，经过毕业后的几年工作，从业者应该至少想到有一个层把sql语句隔离开，可惜这位同学还停留在软件可用的阶段，没有听到我想要的答案。按照uncle bob的描述，像外设、数据库、Web、服务器、框架、通信协议都应该延迟决策，架构师应该对这类细节进行抽象，把核心业务的、流程的、策略的与细节的脱离关系。以数据库为例，核心业务应该需要的是增查删改的接口，而不关心接口实现的细节，这样可以延后数据库选型。

上面说的组件拆分也好、数据库选型也好都是非常大的决策，软件设计师（TL、SE）可能不关心这一层面的东西。再阐释一下，“保留尽可能多的可选项”就要求尽可能把所有可能发生的事都做好预留，比如某一个实体的规格是1还是2的问题，现在是1，可以预料的将来会有2的需求，系统就需要按2进行架构设计。这不是过度设计，是未雨绸缪，不然2的需求来的时候，就是颠覆性的修改了。再举个例子，部署不同的两个组件由于业务基本相同，代码共用程度很大，随着规格发生变化，组件实际需要的内存一个是另一个的二倍，随着区别越来越大，为了强行共用引入了大量的函数指针进行处理，这都是需要在演进过程不断给后面的可选项进行预先设计的场景。