嗯本篇不是要講 UX，這主題讓專業的來就好，在這邊用五個字來總結 UX：讓使用者爽。這篇主題是最近在思考著怎麼讓開發者也能有好的開發經驗，結果估狗之後發現還真的有 Developer Experience 這樣的一個詞，一樣可以用五個字總結：讓開發者爽。這裡所謂的開發者可能是你同團隊的戰友、github上的跟隨者、甚至是你自己。什麼你問說為什麼要讓開發者爽？開發者爽了之後程式碼品質提升、工作效率加快、大家就有更多時間讓使用者爽幫老闆賺大錢，這樣重不重要？

其實 UX 也好 DX 也好，參與其中的都是活生生的人，基本的原則是差不多的。對照 UX 的十大經驗性原則，可以衍生出如下的 DX 思考：

1. 系統狀態的能見度： 針對開發中的系統，品質的能見度也是很重要的，每個開發者都經歷過大功能上線整天燒香拜乖乖祈求不會爆炸的日子，這其實就是一種系統能見度不高的現象。這種情形通常只有兩種狀態 a. 系統沒有回應很好使用者應該都沒在抱怨 b. 客戶生氣啊啊啊東西壞掉怎麼辦啊啊啊。於是乎開發者開始擁抱 TDD，不斷的測試確認功能完善且不會影響到其他功能，重點是及早把問題提升到可視範圍，提升系統能見度。
2. 真實世界與系統的對應關係： 在 UX 範疇下，系統通常會借助真實世界的對應來讓使用者比較容易理解，而在開發者角度來說系統通常就是一堆程式碼。要能近似真實世界是比較不可能的，但程式碼裡變數的命名、檔案的取名、檔案的結構，都要能直接對應系統的結構，這樣開發者也會比較容易了解。重點在於人如其名，這樣對於整個系統的認知上才會起到正面的效用。
3. 操控自由性： 操控自由性很重要的一點是，可以輕鬆的從錯誤狀態中回覆。系統不會永遠都處於完美狀態，當有錯誤發生的時候要怎麼回復？無論是降版、重啟、系統還原，有一個基礎的歸零點之後，才有談自由操控的可能。
4. 一致性與準則： a. 同樣的一個詞，就應該代表同一件事情。比如說 RESTful 準則：發 POST 就應該要是建立新的物件，PUT 就是修改物件。 b. 準則即是有規則可循。比如說同一個資料夾下面應該是類似的東西。甚或常聽到的 Coding Style, coding convention, style guide 等，都在這範疇裡面。當系統越來越複雜時，這樣子的規則會幫助我們不至於在增長的過程中迷了路。
5. 錯誤防堵： 從簡單的 IDE 錯誤檢查到單元測試、整合測試，開發者現在有越來越多工具幫助我們及早發生及避免掉錯誤。TDD 也是一個幫助錯誤防堵的開發方式。
6. 辨識而非記憶： 能夠熟記各種指令的人畢竟是少數中的少數，開發過程中能有一些 autocomplete 的指令列工具或是 IDE 絕對對於開發速度上來說是有很大程度的幫助。如果指令列沒有辦法 autocomplete 至少也要有個 help 指令，列出可能的選項來讓開發者選擇使用。
7. 彈性與使用效率： 此原則的概念是把常用的功能以最少操作的方式呈現給使用者以達到最大效率。舉例來說：對於工程師來說，只要可以自動化的功能都可以寫成一個一鍵執行的 script，效率上不是問題。通常為了保持 script 彈性我們會設計他可以接受參數，但又有一個可以一鍵快速執行的預設值。
8. 美觀與簡潔的設計： 開發者可能是公認最沒有美感的一群，美觀就放水流吧。但無論如何簡潔還是很重要的，不管是產出的程式碼、系統的操作方式，步驟越簡單越能減少問題的發生。
9. 幫助使用者處理錯誤狀況： 發生問題時沒有頭緒是一件很惱人的情況，因此需要確保自己的系統在可以想像得到的狀況下都有足夠的資訊來排除問題。
10. 幫助與文件： 這點應該不用多作解釋，比起一般使用者，開發者才是真正依賴文件的一群。

DX 跟 UX 本質上沒有兩樣，重點在於設身處地的為其他的工程師（或是未來的自己）想像他們的需要。比起 UX，相信工程師在實踐 DX 上會更為踏實，畢竟只有工程師了解工程師（汗）。