API(Application Program Interface)應用程式介面；看似簡單的名詞，卻代表著重要的架構設計。從架構設計的角度來看(所謂的組成論)，軟體系統就是模塊和介面。模塊(層次/組件)決定分工，介面決定交互(interactive)。API就是介面的定義。模塊間並不需要關心其它模塊的實現，只需要了解如何進行協作即可(請參考設計api時的第一個抉擇)。這樣將複雜度分散到各個模塊之中，使得整體系統更為可控。而API的本質，就是提供給模塊開發者使用的介面，是給人(Programmer)用的。API設計任務的核心就是保證使用者以較低的成本, 正確的使用介面來驅動模塊以完成他們的任務。而對於Public API而言，最大的設計挑戰則是如何把API一次就做對!或是退而求其次，如何設計的讓異動的時候損失最少。
Be careful of your thoughts, for your thoughts become your words; Be careful of your words, for your words become your deeds; Be careful of your deeds, for your deeds become your habits; Be careful of your habits; for your habits become your character; Be careful of your character, for your character becomes your destiny. (註1.)
Be careful of your thoughts, for your thoughts become your words; Be careful of your words, for your words become your deeds; Be careful of your deeds, for your deeds become your habits; Be careful of your habits; for your habits become your character; Be careful of your character, for your character becomes your destiny.
其中看板方法可能是我們日常用的最多的一個。如果你的團隊有在使用看板，但卻從來沒有去設定半成品數(WIP,work in progress)或是設定了WIP的值，但總覺得有設跟沒設都差不多，那就是因為你沒有具體的去做假設，要在更改 WIP值的時候先做好假設，才能夠具體的看出成效。舉例來說: 你在”測試”的欄位裡將WIP值設定成1，也就是在這個欄位裡內同時只允許有一張工作單，後面的流程便都會卡住進不來一直到他被完成移出去以後流程才可以繼續。目的明顯的是你要追求好的測試品質，因此你假設了只要有一個BUG還沒解決，開發工作就不能繼續下去。會有什麼結果，歡迎讀者自己去試試看了。
DevOps的三步工作法的第三步
這是由Gene Kim 所創的實踐DevOps的三步工作法，其中的第三步、持續學習與實驗的具體實踐。意思是在開發運維的工作中運用假設的思維進行科學實踐(也就是觀察、假設與驗證)，來獲取知識並進而達到持續學習的目標。軟體開發與運維本來就是持續的在做嘗試錯誤的動作中推進的工作，由於資訊工作的環境往往存在著眾多紛雜的變數，經常是一件小小的更新或是一個細微的動作就能讓整個工作癱瘓下來，因此我們經常疲於奔命就為了一個細微而不經意的失誤，這種蝴蝶效應是一種系統的反應(屬於系統思維的範疇)，它教我們除了工作更專注之外就是要常常具備實驗的心態(對變數的主動探索)，用假設來預測前行的風險然後用驗證來踏實化具體的結果。
假設思維的知識體系
上圖中的四個工具正好構成一個簡單的可以將假設思維運用在開發上的開發者知識體系，運作方式說明如下: 在探索需求的初期運用影響地圖來設定各種假設(里程碑milestone)，然後透過看板方法來具體實踐，以設定各種半成品數(WIP, Work In Progress)值來實驗何者的流量最適合當前作業，並借助OKR的關鍵指標來激發團隊潛能，最後能夠達到具體實踐「觀察-假設-驗證」的DevOps三步工作法的持續學習與(科學)實驗的實踐。
API First有二個面向，一個是對外的策略，提供合作夥伴或協力廠商可以取得公司服務的應用程式介面，無形的擴大了公司的規模(影響)邊界。另一個是對內的模組化分工。讓API成為內部界接的標準化語言，進一步讓API成為一等公民，成為團隊之間協作溝通的介面。無形間也讓內部協作能夠晉升到雲端的環境上。這也是進年來成長快速的公司紛紛祭出的政策，例如: 熱門的微服務也是實踐 API First的一種方式。
實施API-first 的基本优点:
相依性下降
安全化的抽象层
高效、迭代更新快
API first的潮流下，衍生出來的AaaP,API as a Product
API 應用程式介面沒有標準格式
沒有標準；其實是標準太多，造成沒有一致的標準。依據美國 API 學院將API產品區分成五種樣式，供我們在設計相關API界面時參考，陳列如下。
首先；在手機上執行Trello，選擇創建一個最基本的 「To do – Doing – Done」 看板，一個簡潔到不能再簡單的看板，它能讓人能一目了然，即使手機不在你身邊只要閉上眼睛稍微想一下就能意會自己現在在做什麼、接下來該做什麼了。若是用手機(那麼小的屏幕)就能讓你看清楚，想當然就是沒有手機的時候你也能清楚的記住它長成什麼樣子，也就是；目前你在進行怎樣的工作，做到哪裡?
填加工作卡: Trello + mail
如果有突發的事件發生造成你必須中斷手頭正在做的工作，就用email寄給自己的方法，email給 Trello 的看板(註1.)，它會自動加入到 To do的待辦事項裡頭，接著判斷一下是要接受中斷，把新工作拉進Doing欄位開始進行呢? 還是先pending一下等做完手頭的工作在接著做它。如果選擇中斷，就做好註記，記下被中斷的工作做到哪裡了、進度如何?好回過頭來便利於繼續做下去，不至於每次都從頭開始。
運用自我反饋逐步改善自己(trello + email)
.
一分鐘看板如何提升居家工作的效能
在史蒂芬·柯維提出的成功者的7個習慣中，你覺得哪一個最難做到呢? 出人意料的調查結果，最難的並非是與他人合作或持之以恆之類的習慣，而是“要事第一”Put First Things First。因此日程規劃的難點在於，決定哪一件事是最重要的事? 因為既便你排好了優先順序，又總是會有些事情突然冒出來打亂你原先的規畫和節奏。
上圖是一個最基本的 「To do – Doing – Done」看板，填加卡片的方式是採用email的方式，目的是透過時間差加入卡片的方式，讓你有一點時間思考該立刻改換工作還是繼續手頭的工作，依據的是「何者對你的意義較大呢? 」，想好了就打開手機上的 Trello ，若決定是改換工作項目，就做好註記，把它小在email 裡頭然後寄給自己(所以你的email裡頭就多了二種信件，一種是寄給Trello的工作卡片，另一種是註記被你pending的工作進度、註解或說明。其實還可以多做一種回饋的email，註3.)，寫下手頭上工作的注意事項，接著把新卡片從 To do欄拉進 Doing欄開始新工作，做完了就移到Done。上圖中的第四個欄位，我放的是以日期做標題的前一天所完成的工作，目的是檢視用，看了以後再寄信給自己做成回饋鏈。目的是透過 email 的方式來提醒自己衡量自己的工作成效。
.
不知道從哪裡開始?
如果你沒用過看板、不知道什麼是看板方法，下面是我的開始(記得第一次畫這張圖是在餐廳裏頭，用的是黃色可回收的紙巾)，請堅守一次只做一件事，那是因為聚焦可以讓你心無旁騖做好你該做的事，多工只會害你失誤。而開始的第一步是排序。做你認為此時此刻應該做且最有意義的事。開始執行的方式事依靠 「 拖拉 」 這個動作。它的意思是前面的工作已經做完了(拉進Done了)，如果還沒完成就不能再拉入新的工作；被擋住了(Blocked)。所以我可以開始拉進新的工作來做了，意思就是用線性化的流程被擋住的方式來實踐 「 單工作業 」 (請參考這一篇)。繪製下面這張圖，只需花掉你幾秒鐘的時間，但它卻可以把腦中的一維的 To do list 變成平面可視覺化的執行過程(請參考: 讓 To-do List 變敏捷起來)，這便是看板的價值。
培養在腦子裡想像 To do-Doing-Done 的看板，需要經常練習，習慣了就會在想完之後作相互對照，拿起手機來看看是想得快呢?還是手機上的正確些，蠻有趣的；我經常在躺椅上做這件事，手上明明就握著手機，但硬是要用背得來驗證自己想像的準確。也算是動動腦的方法吧，它讓我對該做的事更不會遺漏，而且記憶的更深。試試看；蠻有趣的。
<Something>-as-a-service 是一個讓人心生敬畏的標語。聽起來就好像有一股新風潮即將對準著技術人員席捲而來的味道。讓我們來回味一段歷史；記得是從 1983年昇陽電腦提出「網路即電腦」The Network is the computer 開始，到1996年，Compaq公司首次提出了「雲端運算」Cloud Computing這個詞彙(現在雖然Compaq不見了，但雲端將永遠長存)。隨後AWS的雲端真正的成熟並成為一代雲端的霸主，並造成一股「軟體即服務（SaaS）」的風潮。而AaaP，API as a Product, API是個產品則是指「組織將API視為可衡量的產品」，也就是對待應用程式介面(API)的方式，與其它的產品並無差異的意思。講得白話一點，就是將API的原型、設計、部屬與管理視同為一個產品來開發維運。這也意味著，設計一個應用程式介面(API) 也應該從了解你的使用者開始。有趣的是；這個使用者不是其他的客戶而是開發人員(developer)。我認為這是一股 DX的風潮，DX太重要了，對一個時時處於壓力之下的開發人員，一個設計良好的工作情境可以提升多少效能，又能避開多少陷阱、多少不經意的缺陷呢。
New ways of working such as globally distributed development or the integration of self-motivated external developers into software ecosystems will require a better and more comprehensive understanding of developers’ feelings, perceptions, motivations and identification with their tasks in their respective project environments. User experience is a concept that captures how persons feel about products, systems and services. It evolved from disciplines such as interaction design and usability to a much richer scope that includes feelings, motivations, and satisfaction. Similarly, developer experience could be defined as a means for capturing how developers think and feel about their activities within their working environments, with the assumption that an improvement of the developer experience has positive impacts on characteristics such as sustained team and project performance. This article motivates the importance of developer experience, sketches related approaches from other domains, proposes a definition of developer experience that is derived from similar concepts in other domains, describes an ongoing empirical study to better understand developer experience, and finally gives an outlook on planned future research activities.
