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

文章图片
不知道大家有没有注意到问题：作为一个开关型的配置，当设置成OFF的时候，是一个100%的负反馈，这没有问题，但是问题在设置成ON的时候，这个功能是否启用会依赖优化器的判断，也就是有一定概率MPP功能不会生效，这就像一个房间里有个控制灯的开关，当你关的时候，灯一定不会亮，当你开开关的时候，灯不一定亮（灯觉得房间内的光线足够，没必要亮...），你一定不会觉得这个灯智能，你一定会觉得灯坏了。上面这个配置的一个更好的写法应该是：
这个写法我都不用解释，你也不用看文档，是不是一眼就明白怎么用？好配置应该是自解释的。通常来说，配置项是破坏用户体验的重灾区，后边讲反馈的时候展开讲讲。
UNIX哲学里面有一条「安静原则」，说的是如果程序没什么特别事情要表达，应该保持安静。具体的一个表现就是鼓励命令行程序如果成功执行，不需要输出东西的话，就直接以0作为returncode退出就好了，其实对于这一点我是持保留意见的，用户的行为如果是符合预期的结果，应该用一个明确的正向反馈作为奖励（例如打印一个Success都好），不要忘了人性大师巴普洛夫。
13、反馈：暴露进展，不要暴露内部细节
刚才正好提到了反馈，我觉得将反馈称为好体验中最重要的一环都不为过。学过控制论的朋友的都知道反馈是非常重要的概念，前面提到的Self-Explanatory之所以是个好体验就是因为反馈的及时性。
但是我惊讶的是，很多基础软件在交互反馈部分设计得糟糕得令人发指，举一个我熟悉的例子，某些数据库软件在接收到一个复杂查询的时候，当敲下回车，通常就Hang在那里了，可能确实数据库程序在后边辛苦的检索和扫描数据，然后隔了几分钟直接返回一个结果（或者挂了），过程中并没有反馈扫描了多少数据和预期要扫描多少数据，其实这个体验是很差的，因为这个信息就是进展（这点上ClickHouse做得很好）。反馈是需要精心设计的，我的几个经验是：
1.反馈一定要即时，最好是敲完回车后200ms内一定要有反馈（人的生理反应时间，超过这个时间反馈人就会有卡顿感），顺滑的感觉是靠反馈创造的。
2.反馈进展，不要反馈细节，不要反馈需要上下文才能读懂的细节（除非是DebugMode），这里给出一个我们自己的反例：

文章图片
这个Case坏在哪里呢？很显然，对用户来说， Region是一个TiDB内部概念，一个很自然的问题是：什么是Region（我在前面埋了个伏笔，不知道你注意到没有）？为什么Select数据和Region相关？为什么Regionisunavailable？我该怎么解决这个问题？暴露给用户这个信息是无用的，反而给用户创造了噪音。这个Case的原因是TiKV太忙，无法返回需要的数据，一个更好反馈应该是：具体的哪台TiKV因为哪些数据（用用户能理解的形式，如：哪张表，哪些行）读取不出来是因为TiKV太忙，最好还能告诉用户为什么忙，怎么解决，实在解决不了至少贴个FAQ的链接（我见过有软件直接贴StackOverflow的SearchURL的LOL）。
3.对正反馈设置一些milestone ，例如一个服务器程序开始正常对外提供服务的时候，打印一个AsciiArt ，不同日志级别用一些带颜色Label ，这是给用户一个明确信号，这点redis-server做得很好。
通常对于可交互命令行程序的反馈还是容易设计的，一个非常麻烦的事情是，基础软件通常非常依赖配置文件，配置的问题就是修改配置到确认生效的反馈周期通常很长，一个经常的场景是：修改配置-重启-观察效果，而且通常配置是存储在配置文件里面，这也造成修改文件操作的反馈感是极差的，因为用户也不知道到底这个操作有没有生效，尤其是一些配置的生效并不是太明显，一些比较好的实践如：程序在启动的时候打印一下读取了哪个配置文件以及这个配置文件的内容是什么；设计一个类似print-default-config之类的命令行功能，直接输出模板配置，省得用户自己Google 。