PingCAP CTO 黄东旭：如何做出让人爱不释手的基础软件( 七 ) 最近有一件事情让我印象特别

文章图片
「控制器」-「被控制对象」是一个在基础软件中非常常见的模式，就像我们在操作电视机的时候，绝大多数时间是通过遥控器一样，所以可以认为用户对电视机的第一和大多数触点其实是遥控器，所以类比到基础软件中，对于控制器的设计其实非常关键，做好控制器，我觉得关键点是：
1.构建统一的交互语言
2.自洽且简洁的概念模型
我稍微用redis-cli作为例子解读一下。使用过redis-cli的朋友都知道，所有的操作都遵循[CMD][ARG1][ARG2]...的模式，在redis-cli没有例外，不管是操作数据，还是修改配置，所有的一切都在一个统一的交互语言下，而且这个语言一目了然，而且这个语言里面有一些很自然的约定，例如命令（CMD）永远是几个不包含符号的字母组成。

文章图片
redis-cli的交互例子
其实这点在刚才提到探索式学习那节MySQL的例子也是一样的， SQL本身就是一个统一的交互语言，只是没有Redis这么直观。
第二点是概念模型， Redis的优势在于它是一个Key-Value数据库，所以概念很简单：一切都是Key-Value ，观察它的cli工具，你仔细品一品就知道，作者在尝试将所有的功能和交互都往这个Key-Value的模型上映射，这个是很自然的，因为我们之所以会使用redis-cli ，首先是我们接受了Redis是一个KV数据库的现实，所以在使用redis-cli的时候的一个自动就成立心智假设就是Key-Value模式，这在使用cli的时候一切的操作都会变得很自然。这一点在很多优秀的数据库软件里面应用的很多，例如Oracle ，理论上可以依赖SQL来对软件本身做所有操作，因为用户只要在使用Oracle就默认应该是知道关系模型和SQL 。
说了正面的例子，我们聊个反例：大家知道TiDB主项目（不包括其他工具，例如cdc、binlog）至少有3个Controller工具：tidb-ctl/tikv-ctl/pd-ctl ，虽然TiDB确实是一个由多个组件组成的分布式系统，但是对于用户来说，多数时候使用对象其实是TiDB作为一个整体（数据库软件），但几个ctl的使用方式都不太一样，比如说pd-ctl是一个可交互式的控制器，而且影响的范围大概是pd本身和tikv ， tikv-ctl的功能上也有一些交集，但是只是针对单个tikv实例使用，这点太令人费解了， tikv明明是一个分布式系统，但是tikv-ctl却是一个针对单点的控制器？那么控制tikv到底应该用的哪个ctl呢？答案：多数时候用pd-ctl（惊不惊喜，意不意外？）。
就像你有一个电视机，但是需要用三个遥控器来控制，而且真正控制电视的那个遥控器叫做：机顶盒，这种问题在日常生活中大家都认为是一个理所应当的设计问题，但是在基础软件领域大家的容忍度怎么似乎突然就变高了？
12、NoSurprise:不怕麻烦，就怕惊喜（惊吓）
我不知道是否是一个普遍现象，基础软件的用户在面对错误（尤其是因为坏交互造成的），通常会先自责和内疚，认为是自己的问题，很少会归因于软件。尤其是当能够比较熟练的操作一些复杂又分裂的软件的时候，很多人会觉得这是一种「技能」，毕竟没有人愿意别人看着自己的笨拙操作。
这背后其实有着很深层次原因（HackerCulture里面多少有点崇尚复杂的倾向），但是我想说：这就是的软件的问题！就像我从不避讳说我就不会用gdb ，不是因为我智商不行而是因为这个东西真是太难用了。
但是我见过很多人真的是以熟练使用命令行gdb作为炫耀的资本，回到前面提到的那个反例，我在一个TiDB的深度用户那边观察他们的操作员做日常的运维，这个操作员非常熟练的在各种ctl之间切换和操作，他不觉得有啥问题，甚至觉得有点厉害，后来我想了下，人的适应性还是很强的，真正让人困扰的事其实并不是麻烦，而是当你在对系统做出一个操作的时候，通常会带着一个下意识的假设，例如一个功能的名字叫「xx开关」的时候，用户在打开开关的时候的预期应该是有一个正反馈，但是如果结果并不是这样的话，用户会非常有挫败感。这里有个真实的故事，我们在TiDB5.0里面引入了一个新功能，叫做MPP(MassivelyParallelProcessing) ，即大规模并行处理，我们有个开关配置叫做：tidb_allow_mpp