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

另一个特别好的例子是Telegram的Botfather ，我相信给Telegram写过机器人的朋友一定会对Botfather的好用程度印象深刻，我放一张图你就懂了：

文章图片
用Telegram的botfather创建聊天机器人的过程
Telegram是一个聊天软件， Botfather巧妙的利用了IM的交互模式应用到了一个相对枯燥的bot开发流程里面，而不是冷冰冰的丢给用户一个URL ，让用户自己研究去。
这一节最后一句话想送给大家，有一个无从考究的都市传说是这么说的：鱼的记忆时间只有7s ，我想说，人也一样。祝你做出一个“鱼”都能用好的软件。
10、帮用户多想一步，告诉用户半步，让用户自己走半步
我很喜欢看科幻小说，很多科幻小说探索的一个终极哲学话题：我们是否真的有自我意识？尽管我们认为我们有，但是在软件输出UnknownError的时候，你肯定希望有一个声音告诉你接下来该怎么办，对吧？
一个优秀的基础软件，在输出负向反馈的时候，最好的做法就是建议开发者接下来该干嘛。我举一个很经典的例子，所有的Rust开发者都有过被编译器调教的日子，但是这个过程严格来说其实并不痛苦，比如，看下面的截图：

文章图片
之所以不痛苦是因为编译器明确告诉了你哪里有问题、原因，以及下一步应该干嘛，普通编译器可能打印一个cannotborrowasmutable就仁至义尽了，但是一个好体验的编译器会多帮你想一步。
回到自我意识的问题，我之前听过一个段子：一个测试工程师走进一家酒吧，要了NaN杯Null ，一个测试工程师化装成老板走进一家酒吧，要了500杯啤酒并且不付钱，一万个测试工程师在酒吧门外呼啸而过，一个测试工程师走进一家酒吧，要了一杯啤酒'；DROPTABLE ，最后测试工程师们满意地离开了酒吧，然后一名顾客点了一份炒饭，酒吧炸了LOL 。
这个故事告诉我们，作为软件设计者，你永远没有办法穷举使用者的想法，与其让用户放飞想象力，不如你自己设计好故事线，一步步让用户跟着你的思路走。但是为什么还要留半步？我的答案：
1.「参与感」会带来幸福感，人有时候挺矛盾的，一边希望机器自动干完所有的事，一边还期待自己有主动权。有时候即软件已经知道下一步一定是做某些事情，但是留下临门一脚让操作者完成相当于把成就感都赋予了操作者。
2.选择的权利交给操作者，尤其在面对一些单向门的决定时， goorno-go还是应该交给人。
对于这点，我还有几个小建议：
1.对于一些操作可能会引发多个连续操作的模式（例如terraform的部署脚本，或者集群变更之类的功能），提供一个DryRun模式是必要的，只输出操作，不执行操作。
2.对于上面这种批处理型的操作，尽可能设计savepoint ，不用每次都重新来（类似断点续传），体验会好很多。
3.遇到真的UnknownError要输出各种帮助Debug的上下文信息，最后在错误日志里提示用户到哪个链接提GithubIssue ，然后最好在URLLink里帮用户把IssueTitle填好（让用户自己决定是不是发Issue）
这节最后分享一个react-create-app的例子：react-create-app的例子（这个例子也是后面提到的关于正确反馈的好例子）。
11、统一语言：控制器和控制对象
我访谈过很多系统工程师，我有个必问的问题：你心中最好用的（数据库）cli工具是哪个？绝大多数几乎下意识的回答redis-cli 。其实我自己也会给出同样的答案，后来我想这是为什么呢？