整理對 Development Experience (DX) 的看法，原文草稿發表於 Facebook。

一、海賊王 D 之一族的傳說：定義 Developer or Development

首先是 DX 這個詞 D 的定義，很容易被理解成 Developer Experience (DX)，而 Developers 通常指的是 寫 Function / Feature 的人。所以有各式各樣的想法、做法、工具，讓開發人員更順暢的工作、提升產能，像是 工程師喜歡 找了一堆工具來增加產能、或者讓工作更流暢，像是 VSCode 的 Extensions。

• 註一：寫 Function / Feature 的人 更精準的詞應該叫做 Programmers，而社群的鄉民會用 Coders 這個詞來調侃自己，而外界更普遍的用詞稱他們為 Engineers，但實際上 Engineers 其實包含其他像 QA / Ops 等角色。
• 註二：關於 Developer vs Engineer 的差異，我個人的定義參閱 “Developer vs. Engineer“。
• 註三：啥是 Function / Feature 以後再說。。。再歪樓下去我會收不了筆。。。

不過比起 Developer Experience，我覺得 Development Experience 更適當。Development 代表參與這個產品開發的團隊所有成員 (Team)，我在 “Software Development Lifecycle“ 一文定義常見的角色有以下四大類：

1. Planner: PO / PM / UI/UX / SA / Architect / Developer
2. Executor: SWE / Programmer / Coder
3. Accepter: STE / QA / Tester / SDET / QE / QoO
4. LiveKeeper: Ops / Infra / SRE / DevOps / SE / IT / MIS / …

• 其中 2), 3), 4) 統稱 Engineers。
• 中文很麻煩，當我寫 工程師 實際上想表達的是 Programmer，而對我來說，大部分的 工程師 都不能算是 開發者
• Software Engineering at Google 這本書一開始提到 工程 (Engineering) 的定義，我自己的定義有兩個面向：已知規模 (Known Scale)、可以擴展的規模 (Scalable)。
  1. 已知規模例，如 … 要建立捷運板南線、三峽大壩、台電輸配電工程、蓋 101 大樓 … 等已知的巨觀規模。
  2. 另外一種則是未知規模、但可以擴展成巨觀的能力，稱為可擴展 (Scalable)，軟體工程大多就是這種。
  3. 不管是已知規模、還是可擴展的規模，工程都必須具備的關鍵特性：可靠性 (Reliability)。前述兩個定義，都要具備可靠性，才能稱之工程。

這些成員，都是 Development Team 的一員。Programmer 有太多 DX 的方法、工具，但我覺得，整個團隊不是只有 Programmer 才是人，也應該關心一下，開發團隊其他成員的開發體驗。

1. 大家知道我們的 QA 是怎麼測試的？開始測試前應該具備哪些條件 (先不用談測試左移)？
2. 大家知道 上線前、中 Ops / DevOps 怎麼處理 Infra / Build / Deploy 的事情？上線後 Ops / SRE 是怎麼處理線上異常與事件？應該怎樣改善這些體驗？
3. 還有辛苦的 Planner (PO / PM …) 是如何把需求收斂成可執行的規格的？

這 整個過程 有體驗可言？怎麼改善這個過程的體驗，讓大家開發的協作有更順暢的體驗？

Again, 品質是整個開發過程

DevOps？

歪個樓，大家常聽到的 DevOps 這個 BuzzWords，通常理解的都是狹義的 Development、或者一些文化之類的，也就是前一段提到的 “2), 4)” 的關係。

廣義的 DevOps 的 Dev 也不是單純講 Programmer，而是以公司角度來看的產品開發 (Product Development)，而 Ops 比較像是業務與營運單位。這個角度來看，我前面提到的四個角色都屬於 Development Team，而 Operation Team 則是把業務帶進來、讓客戶留下來的管理單位，像是業務、行銷、營運單位 … 等。

類似概念可以看我幾年前分享的演講 “導讀持續交付 2.0 - 談當代軟體交付之虛實融合“，有提到廣義 DevOps 的看法，如下圖：

二、Are You Experienced：是 誰 的體驗 (Experience)

標題引用 傳奇音樂家 Jimi Hendrix 最有名的專輯：Are You Experienced，是音樂史的里程碑，重新定義了如何體驗音樂。AWS 2015 的 Well-Architected Framework 介紹也引用這個概念。

談完 D 的定義，再來談談體驗 (Experience)，我想專注的是 “誰” 的體驗？

關於體驗，大家最常見的就是 User Experience (UX)，這個 User 指的是終端使用者 (End User)。最經典了例子就是 開箱，源自於 Apple 產品的體驗感，讓廣大鄉民都可以藉此寫寫廢文、找理由當 Youtuber、無腦下單 … etc。

承接上一段 Development 對象的定義，而對於 Programmer 而言，最常見的開箱就是：

• 到 GitHub 找到一個 Open Source，透過 Quick Start / Getting Started 快速體驗怎麼用，能否解決問題、或者有炫砲的感受。。。。
• 這十幾年全世界開發的份圍，體驗就是：一堆花花綠綠的 terminal、emoji、powerline … 等炫砲 …

如果不容易讓人理解怎麼用，就會被跳過去，因為開箱體驗不好。

上述我覺得都是普遍的第一觀感，其實這些也滿重要的，雖然有時候覺得有點膚淺，但確實是會讓人更容易入門。

我覺得真正的開發體驗應該是這種，舉例以下幾種：

• 第一個是 SpecFlow： 改善橫跨 PO / Programmer / Tester 針對規格的理解，與落地執行測試的方法。有了這個方法與概念，才有後面的工具產生。
• 第二個是 Containzied (Docker)：這個技術的出現，改善了交付的定義，讓所有角色 (四大) 都可以用統一個方法輕易的交付，終結 在我的電腦可以跑，你的電腦不能跑 的交付體驗。

這兩個例子，都是軟體開發劃時代的體驗，我相信還有其他很多概念、方法、技術改善了團隊協作，增加效率。

另外語言層級的改善，像是 .NET6 從 v3.1 ~ v6 的改善，也是個不錯的案例。.NET Developer 如果 .NET 3.1 到 6 一路體驗下來，就可以感受到在 Language 層次的體驗，越來越精簡、越來越多語法糖，啟動 Startup.cs & Program.cs 兩個變成只有一個 Program.cs，更簡單了，更容易理解了。類似的 DX 改善 node.js 生態系的就跑得更前面了。只是直接受惠者只有 Programmer。

以前哪些體驗不好，或者不好入門的工具，像是 vi / git，則是因為本質夠強大，就有人會主動去改善它的體驗。

三、體驗，使用者的體驗

前面定義的四大角色，以及針對體驗的描述都是內在的東西。也就是每個角色，自己在開發過程的體驗如何，都是角色自己的角度出發。

體驗是動詞。

真正的體驗是以客戶的角度，體驗自己的產品，以電商為例：

1. 應該要去驗自己的產品，像是走完一家店的流程、到後台過商品、從 End User 角度下單、然後客戶角度去後台完成訂單流程
2. 給客戶前，應該去用自己開發的 API，吃自己的狗食

怎麼落實這種體驗感？什麼時候開始？上 Production 體驗？我的答案是：

Containzied 技術的出現，已經滿足這種體驗的需求。

在上 Production 之前，不管是怎樣的應用程式、怎樣的架構，都要可以在一台電腦裡 (Linux)、用 Container 跑起來，走完所有業務邏輯。

從設計與規劃階段，就要想這件事情，以終為始。還沒出貨之前，就已經完全可以從客戶角度，體驗整個產品。”淺談軟體測試的階段與策略“ 一文最後談到這整個想法與脈絡。

體驗會讓我們產生行動與認同感。除了薪水，這是凝聚員工向心力與認同感最實際的方法。

後記

寫這篇背後是因為：

1. 資訊發達的時代，太多單一觀點，在決定所有角色的方向，忽略個別角色的角度。
2. 單一觀點寫出來的東西，在網路流傳，如果那個人又有點名氣，整個世界就是被帶風向
3. 團隊有好的開發體驗的同時，也要同步提升自我的專業知識

而我是少數經歷 經歷 Software Develpoer (國際外商)、SQA Manager / SDET Lead (IoT 新創)、Operation / Infrastructure Manager (電商新創)、Architect (電商新創) 等角色，而且每個角色都是全職的、經歷從零到一個過程，對於軟體開發體驗的觀點，有別於單一角色的觀點。

延伸閱讀

站內文章

• Developer vs. Engineer
• 可靠性工程 (Reliability Engineering)
• Software Development Lifecycle
• 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
• 演講：從理想、到現實的距離，開啟品味軟體測試之路
• 淺談軟體測試的階段與策略