前言
爲什麼要談易用性呢？其實是因爲博主從事軟件行業長久以來，另一最煩躁的，也是經常聽到身邊同事抱怨的一句話就是：我靠！天啦擼！這個API好難用啊！！！
其實難用就是消費方對於提供方所提供資源（服務或能力）的最直觀的不滿用詞。這個時候，你要真想讓消費方說哪些地方難用？估計他只會告訴你：哇，你這個參數命名很讓我費解啊，完全不知道什麼意思，而且還爲文檔！老規矩，在詳細闡述之前，我們嘗試定義這個特性（關注點）。
定義
易用性 - 消費方使用系統提供的資源（能力或服務）的便利程度。
消費方
消費方是評價的主體，因此係統提供資源的易用性不能自己說了算。這就和每當年底績效考覈時，你的自評和Leader評價存在差異是一樣的道理，是個看問題的角度問題。
便利程度
便利程度首先需要強調不是無限度的讓每個消費方都感覺便利，實際上也是做不到的。且不說你實際上是否真正的“便利”，但就每個消費方的對於“便利”的評價標準不是整齊劃一的，而且這還是超出你控制之外的因素。這就和生活中，你不可能讓人人對你滿意是一樣的道理。實際上是一個比較模糊的用語，所以我們只需要讓絕大部分消費方感到便利即可？
技巧
那麼既然易用性的評價標準如此模糊和不統一，我們還怎麼提升系統易用性呢？這還是得依靠我們再學習面向編程語言第一天聽到的那個特點：抽象。上一篇我們也提到了它，讀者應該可以感受到理解基礎概念的重要性了吧！實際上通過思考，我們是可以在這些模糊變化的標準中抽象出一些不變的技巧或思路來幫我們提升系統易用性的：
儘可能的把消費方當做“傻子”，不要把消費方想想的很聰明
爲什麼要這麼思考呢？因爲你不能保證所有的消費方都很“聰明”，能理解你的設計意圖！所謂的“傻子”和聰明其實很多時候與智商無關，僅僅是因爲每個人的從業背景和經驗差異導致的。簡潔清晰的文檔
“好記性不如爛筆頭”這句老話確實有道理，文檔不但可以便於提供方查看，也可以避免消費方頻繁詢問。尤其現在這麼多開源的產品，很多時候如果文檔不夠清晰明瞭，提問後等待社區反饋那就時間沒法保證了。說道這，不得不說下我們國內的開源產品一貫的不重視文檔的習慣了，所以基本上不太敢用，當然做的好的也有，比如阿里巴巴開源的分佈式RPC框架Dubbo，文檔很全，不過略顯雜亂。博主之前看Kafka、RabbitMQ等國外開源產品文檔，都驚歎於對方簡潔清晰的文檔。方法和參數命名
提供出去的每一個API的方法簽名，最好都是能望文生義，消費方看到這個方法簽名就大概知道怎麼用了，這樣是最好的。高級接口
高級接口其實一點也不“高級”，就是我們在大話系統架構決策 - 靈活性中提到過的組合接口。提供高級接口不但會提升系統的易用性，其在新系統推廣時，起着極其重要的作用。
實例一：某消息中間件SDK提供高級Push/Pull接口
SDK是提供給消費端用於桶消息中間件交互的，其本身也是爲了提升消息中間件的易用性，降低消費端的開發難度。那麼在設計SDK的暴露給消費端的API時，正常情況下只要包括簡單的Push/Pull接口即可。但是很多時候，其實這樣的封裝還是不夠的，比如一般情況下，消費方都是要寫一個線程池來定時拉取消息消費的。那麼這個時候，其實提供了一個封裝了線程池拉取的接口，就會大大提升易用性，提升消費方的接入意願。