One Piece X 開發者體驗 三分鐘斷捨離，讓每天都早點下班

大家有沒有一種經驗就是每次剛搬完家很多急著要用的東西都會找不到，但又要用就只好又買一組新的，寫程式也是一樣的概念，來了一個新需求以前我們到底有沒有做過? 有做過的話要去哪裏找該怎麼找?

究竟是來當工程師是進行軟體開發還是來當海賊王尋找 One Piece

開發者體驗

什麼是開發者體驗 (Developer Experience)?

開發者體驗 (DX) 是指開發者在開發軟體時所感受到的一切，包括工具、框架、程式碼結構、文件、測試、調試等方面的體驗。

一個好的 DX 可以提高開發效率，降低錯誤率，並鼓勵開發者樂意參與和貢獻。

開發者體驗其實就是從 UI/UX 來評估開發者的日常行為

• User Interface: 開發者的使用者介面就是程式碼
• User Experience: 好的使用者體驗除了包含了好的使用者介面外，開發環境提供語法高亮、自動完成等功能也是重要的環節

對開發者來說，常見的使用者情境大多為加新功能、修正問題、極端案例測試三種

1. 加新功能: 找到適合的位置後加上對應程式碼且沒有增加新的問題
2. 修正問題: 找到問題在程式碼中的位置，修正並測試且沒有增加新的問題
3. 極端案例測試: 找到發生位置並測試極端值是否會讓程式碼不正常運作

可以發現開發者會不斷進行 “尋找” → “閱讀” → “修改” 的過程，所以接下來也分成兩個部份來進行優化

1. 程式碼 SEO: 優化尋找
2. SOLID: 優化閱讀

程式碼 SEO

當需要修改時，相關的程式碼好找嗎? 會不會找到很多無關的程式碼放在一起? 舉例來說我們就可以將相近功能的程式都放在一起，這樣直觀的設計能夠更快的幫助新進人員進入專案協助。

1
2
3
4
5
6
7

├── Login/
│  ├── SocialButton/
│  │  ├── LineButton.js         # 社群登入的 Line 按鈕
│  │  └── FacebookButton.js     # 社群登入的 FB 按鈕
│  ├── Modal/
│  │  └── ModalLogin.js         # 登入的 Modal
│  └── index.js                 # 登入邏輯與主要 Layout

對工程師來說，會忘記之前寫的東西在哪是很合理的，所以在 IDE 有支援搜尋的前提下，我們就需要針對程式碼做一定程度的 SEO，一個最棒的搜尋結果就是當使用者輸入一個關鍵字後只會得到一個最適合的結果。

舉例前端的例子來說，一般團隊有可能會使用 BEM 的命名規則，像是 info__title 這樣代表我們設定的是訊息的標題，所以當進行搜尋時 info__title 就會是我們的關鍵字，如果是底下示範的第一種寫法反而會造成開發者的困擾。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// Bad 用 .info 才能找，且找到後還要再找第二層
.info {
  height: 100%;
  margin: 1% 2%;
  &__title {
    padding: 1% 0 1% 2%;
    color: white;
  }
}

// Good 大多情境可一次就找到
.info {
  height: 100%;
  margin: 1% 2%;
  .info__title {
    padding: 1% 0 1% 2%;
    color: white;
  }
}

命名

方便搜尋的命名代表程式碼有多方便被修改

• 保持命名的一致性: camelCase、snake_case
• 使用描述性的前綴: is表示布林值、str表示字串
• 避免縮寫: 保密防諜的是對外而不是對內，例如應該使用 numberOfItems 而不是 numItems
• 避免名稱衝突: 確保相似概念的變數都有作用域或是命名空間保護
• 目的明確的命名: 避免使用模棱兩可或不明確的名稱，而應該選擇能夠清楚表達目的的名稱，名稱應該反映其功能、用途或內容
  • 確定 (OK) / 取消 (Cancel): 使用者確定了什麼取消了什麼
  • 送出 (Send)/繼續編輯 (Keep Editing): 可以推測出是送出文章和取消送出且繼續編輯
  • 更新使用者資料使用 getUserInfo() 而不是 getData()

舉個例子來說判斷盡量用布林值的概念命名會更方便，隱藏的條件就可以用 isVisible 或是 isDisable 的布林值來控制條件渲染。

1
2
3
4
5

function getNowElement({ isVisible, isDisable }) {
  const isHidden = !isVisible || isDisable;
  if (isHidden) return null;
  return <span>show</span>;
}

雖然布林值算好讀，但當命名和布林值寫在判斷式中時，會發現我們還是需要進行思考，也較不直觀，底下舉了兩種例子，可以發現第二種命名來說就會更直觀一些。

1
2
3
4
5
6
7
8
9

const VISIBLE = true;
const HIDDEN = false;

// 需要稍微思考
if (element.visible === true)

// 幾乎不需要思考
if (element.visibility === VISIBLE)
if (element.visibility === HIDDEN)

SOLID

SOLID 分別代表了六個原則的縮寫

• Single Responsibility Principle: 一個類別應該只有一個單一的職責，SRP 的目標是減少同個區塊中不相關的邏輯，將相關的功能組織在一起，使開發者更容易找到所需的功能
• Open Closed Principle: 對於擴展是開放的，但對於修改是封閉的，需要新功能時應該透過擴展現有程式碼來實現，而不是修改原始程式碼
• Liskov Substitution Principle: 子類別應該能夠替換父類別，而不會影響程式的正確性，這建立一致性的介面和行為讓開發者不會認知失調，也不會分不清楚是菜鳥還是實習生更不會叫錯名字
• Least Knowledge Principle: 一個模組不應該知道太多關於其他模組的內部細節，只與最接近它的朋友(直接相互依賴的模組)互動，有些事情知道的太多不是好事
• Interface Segregation Principle: 將介面簡化為只包含必要的方法，減少開發者需要關心的內容
• Dependency Inversion Principle: 透過依賴的反轉，我們可以不再被物件牽制，真的去使用東西而不是被東西使用

SOLID 原則有助於將程式碼模組化，使不同的功能和關注點分開，目標是當被開發者找到程式碼後，可以更快確認在哪一行產生目前的行為，更容易去判斷在這一階層 (頁面) 的操作只要正確就可以不用煩惱其他階層的任何操作，專注於特定的功能而不必擔心整個系統的細節，進而更容易且安全的去修改和擴展程式碼。

• ← 上一篇
• 下一篇 →