五年前發了一篇這樣的文章：開發者的 UX: Developer Experience (DX) (finfin.github.io)
如今隨著開發工具的成熟，我們更注重開發效率，關注 DX 已經成為一種顯學，不管開源套件還是軟體服務供應商，沒有好的 DX 很難說服開發者們使用。自家開發軟體也該注重 DX，以減少開發中的各種摩擦、卡關。就如同好的 UX 讓人專注在他們主要的任務上，好的 DX 目的也是讓開發者可以專注在自己開發的功能上，說穿了 DX 的另一面就是生產力的提升。也因此，只要還需要有人當開發者的一天，DX 就會是一個重要的議題。
對照 UX 的十大經驗性原則，可以衍生出如下的 DX 思考：
系統狀態的能見度
對開發者來說，狀態指的是『開發狀態』，包含了開發的進度，開發時的系統穩定性等等。現在各種框架、語言的提示訊息都很充足，只要一些設定就可以知道系統運行的詳細狀況，比較容易無法掌握的通常都是自家的程式碼運行狀態，或是一些相對比較不完整的第三方套件。這裡的開發進度以及穩定性可以透過 E2E / 整合 / 單元測試來反應，針對想開發的功能需求完成的 E2E 可以反應當前系統的功能完成度，而 E2E / 整合 / 單元測試們組合起來可以反應出當前系統的穩定性。針對前端我們還可以再透過三種測試來反應系統的狀態：效能測試、視覺測試以及無障礙測試。 參考資料
測試之外，系統狀態的監控也是提升能見度的一環，這可以幫助開發者及時發現問題，以及問題發生時有更多的線索（資訊）可供參考，這包含了伺服器狀態、錯誤監控等等。 最後，還有一種開發狀態是『另一個空間的開發狀態』，這可以透過善用 git 來了解過去各 commit 的狀態來完成。
真實世界與系統的對應關係
以產品角度來說，產品提供的解決方案，裡面的商業邏輯、流程等都是屬於概念層級的東西，而系統則是這些概念的實作結果。如果系統能夠依照解決方案的邏輯 / 流程來開發，那麼就會比較符合產品本身想要達成的目的。這塊就需要許多人包含領域專家以及開發者們共同來討論，透過瞭解問題領域進而產生出解決方案的流程，最後映對到系統上。如此，無論在命名、檔案結構上，因為有了確切的領域可以參考，也比較不容易產生詞不達意的狀況。參考資料
操控自由性
自由建立在自律之上，開發者擁有對系統夠大的權限，足以影響系統內的所有使用者，因此在談論自由時需要考慮到：自由的前提是不影響到使用者，或至少，最低限度的影響使用者，以讓開發者可以隨心所欲的實驗新的功能。這需要一些配套措施包含了
- 快速的錯誤回覆：比如系統 rollback 方式、資料庫的還原等等，讓系統可以快速回到上一個正常狀態
- 實驗性質功能採用逐步發佈方式：如 pilot deployment，在可控的影響範圍內自由的實驗新功能。 搞壞系統是工程師的惡夢，因此建立一個完整的系統回復流程，讓工程師不用因為懼怕而綁手綁腳，就是釋放工程師自由創造能力的重要因素
一致性與準則
近幾年隨著開發成熟度的提高，各種準則蓬勃發展，從 coding style / convention / design guide / bem / oocss 到 API 命名規範都是我們可以拿來提升開發一致性的方法。
另一個提升一致性的方法則是 DDD 所提到的通用語言 Ubiquitous Language，這是第 2 點的延伸：變數所代表的真實世界對應的物件叫什麼，變數就應該要叫什麼。如此可以達到跨角色的一致性，非開發人員雖然不知道技術上的細節，但若依據通用語言，就有了可以溝通的基礎領域共識。
錯誤防堵
好的錯誤防堵是從源頭就不讓你有出錯的機會，框架、準則就有類似的效果：透過設定好的規則，讓開發者的開發路徑一致，減少走錯路所造成的邏輯衝突。有的框架或工具會提供預設值，讓開發者能夠先在一個『一般正常』的狀況下開始，這也可以減少自己摸索所造成的錯誤。 各種 Linter 不但可以提升一致性，也能透過發現這些不一致的程式碼進而發現或避免奇怪的寫法所導致的錯誤。另外不得不提 spell checker 是很重要的東西。 TDD 也是很有用的工具，透過測試在變更時及時驗證功能是否如常，及早發現及早治療。
辨識而非記憶
能夠熟記各種指令的人畢竟是少數中的少數，開發過程中能有一些 autocomplete 的指令列工具或是 IDE 絕對對於開發速度上來說是有很大程度的幫助。如果指令列沒有辦法 autocomplete 至少也要有個 help 指令，列出可能的選項來讓開發者選擇使用。 不要依賴人類的記憶，只要有資訊就應該記錄下來，當資料量大的時候還必須把相關資料做一些連結，比如軟體規格文件就應該附上相關的討論、資料等，方便開發者查詢。
彈性與使用效率
前一點主要是給不熟悉的場景，若想要有效率的開發，順暢輸入為必要條件，這仰賴對語言的熟悉程度。包含對語言本身的語法、控制結構、設計模式等的了解，更深一點的包含對專案結構、產品功能設計背景上的了解，都有助於在開發 / 除錯時更快速的理解現狀並且闢出一條改進的道路。你越了解你現在手上在處理的是什麼，就越有可能有效的解決他。 而原始 UX 原則提到的彈性，指的是一個環境應該同時提供兩種（或多種）達成同樣目的的方法，讓不同經驗程度的人都有辦法完成功能，例如：介面操作與快捷鍵。在系統的設計上，Convention over Configuration 是一種常見的做法，初階使用者可以使用系統提供的預設值，進階使用者則可以依據自己的需求來調整。
美觀與簡潔的
簡潔的意思是不要有不相干的內容，透過減少雜訊的方式增加使用效率。程式碼也該是如此，一個函式中應該就是專注把一個結果做好，避免一個函式同時做好幾件事情。一些資料夾結構或是框架也能幫助我們達成類似的效果。 當然，講到 clean code 不免把經典的書拿出來看一下：
https://www.notion.so/yourator/Clean-Code-8ae06dca163f4e318cae4d9e88688cc6
至於美觀的作用大多在於給開發者帶來點好心情，比如你的測試可以像這樣：
幫助使用者處理錯誤狀況
發生問題時沒有頭緒是一件很惱人的情況，這對一般使用者或開發者都是如此，要確保自己的系統在可以想像得到的狀況下都有足夠的資訊來排除問題。套件的選擇上可以考慮採用較為活躍的套件，活躍包含了使用人數多、GitHub 上的 issue 有在處理、文件清楚、有完整錯誤說明、 FAQ 等等，這樣的套件有問題也比較容易找到支援。而自家的程式則盡量留下足夠的足跡如 log 或監控等，如此在發生錯誤的時候，才有辦法找到錯誤發生時的狀態，以便進一步的處理。
幫助與文件
教學方面，一個好的文件需要讓使用者可以依照其中的步驟快速把相關的環境設立起來。 規格方面，因為比起一般使用者開發者需要更了解系統，因此會更依賴這些文件，這包含廣大的範圍，從軟體規格、系統架構、產品需求、操作與排查手冊、FAQ 等等。 另外給開發者的文件還需要包含系統尚未處理的漏洞、未來的發展等等，以讓開發者比較全面的了解系統的現狀。
這些是從原來的 UX 準則衍生的，其實因為開發者需要更全面的理解系統，因此真正 DX 所包含的遠超過這十個面向，這些就留待讀者思考嘍。
