前言
为什么要谈易用性呢？其实是因为博主从事软件行业长久以来，另一最烦躁的，也是经常听到身边同事抱怨的一句话就是：我靠！天啦撸！这个API好难用啊！！！
其实难用就是消费方对于提供方所提供资源（服务或能力）的最直观的不满用词。这个时候，你要真想让消费方说哪些地方难用？估计他只会告诉你：哇，你这个参数命名很让我费解啊，完全不知道什么意思，而且还为文档！老规矩，在详细阐述之前，我们尝试定义这个特性（关注点）。
定义
易用性 - 消费方使用系统提供的资源（能力或服务）的便利程度。
消费方
消费方是评价的主体，因此系统提供资源的易用性不能自己说了算。这就和每当年底绩效考核时，你的自评和Leader评价存在差异是一样的道理，是个看问题的角度问题。
便利程度
便利程度首先需要强调不是无限度的让每个消费方都感觉便利，实际上也是做不到的。且不说你实际上是否真正的“便利”，但就每个消费方的对于“便利”的评价标准不是整齐划一的，而且这还是超出你控制之外的因素。这就和生活中，你不可能让人人对你满意是一样的道理。实际上是一个比较模糊的用语，所以我们只需要让绝大部分消费方感到便利即可？
技巧
那么既然易用性的评价标准如此模糊和不统一，我们还怎么提升系统易用性呢？这还是得依靠我们再学习面向编程语言第一天听到的那个特点：抽象。上一篇我们也提到了它，读者应该可以感受到理解基础概念的重要性了吧！实际上通过思考，我们是可以在这些模糊变化的标准中抽象出一些不变的技巧或思路来帮我们提升系统易用性的：
尽可能的把消费方当做“傻子”，不要把消费方想想的很聪明
为什么要这么思考呢？因为你不能保证所有的消费方都很“聪明”，能理解你的设计意图！所谓的“傻子”和聪明其实很多时候与智商无关，仅仅是因为每个人的从业背景和经验差异导致的。简洁清晰的文档
“好记性不如烂笔头”这句老话确实有道理，文档不但可以便于提供方查看，也可以避免消费方频繁询问。尤其现在这么多开源的产品，很多时候如果文档不够清晰明了，提问后等待社区反馈那就时间没法保证了。说道这，不得不说下我们国内的开源产品一贯的不重视文档的习惯了，所以基本上不太敢用，当然做的好的也有，比如阿里巴巴开源的分布式RPC框架Dubbo，文档很全，不过略显杂乱。博主之前看Kafka、RabbitMQ等国外开源产品文档，都惊叹于对方简洁清晰的文档。方法和参数命名
提供出去的每一个API的方法签名，最好都是能望文生义，消费方看到这个方法签名就大概知道怎么用了，这样是最好的。高级接口
高级接口其实一点也不“高级”，就是我们在大话系统架构决策 - 灵活性中提到过的组合接口。提供高级接口不但会提升系统的易用性，其在新系统推广时，起着极其重要的作用。
实例一：某消息中间件SDK提供高级Push/Pull接口
SDK是提供给消费端用于桶消息中间件交互的，其本身也是为了提升消息中间件的易用性，降低消费端的开发难度。那么在设计SDK的暴露给消费端的API时，正常情况下只要包括简单的Push/Pull接口即可。但是很多时候，其实这样的封装还是不够的，比如一般情况下，消费方都是要写一个线程池来定时拉取消息消费的。那么这个时候，其实提供了一个封装了线程池拉取的接口，就会大大提升易用性，提升消费方的接入意愿。