大家有沒有一種經驗就是每次剛搬完家很多急著要用的東西都會找不到,但又要用就只好又買一組新的,寫程式也是一樣的概念,來了一個新需求以前我們到底有沒有做過? 有做過的話要去哪裏找該怎麼找?
究竟是來當工程師是進行軟體開發還是來當海賊王尋找 One Piece
什麼是開發者體驗 (Developer Experience)?
開發者體驗 (DX) 是指開發者在開發軟體時所感受到的一切,包括工具、框架、程式碼結構、文件、測試、調試等方面的體驗。
一個好的 DX 可以提高開發效率,降低錯誤率,並鼓勵開發者樂意參與和貢獻。
開發者體驗其實就是從 UI/UX 來評估開發者的日常行為
對開發者來說,常見的使用者情境大多為加新功能、修正問題、極端案例測試三種
可以發現開發者會不斷進行 "尋找" → "閱讀" → "修改" 的過程,所以接下來也分成兩個部份來進行優化
當需要修改時,相關的程式碼好找嗎? 會不會找到很多無關的程式碼放在一起? 舉例來說我們就可以將相近功能的程式都放在一起,這樣直觀的設計能夠更快的幫助新進人員進入專案協助。
├── Login/
│ ├── SocialButton/
│ │ ├── LineButton.js # 社群登入的 Line 按鈕
│ │ └── FacebookButton.js # 社群登入的 FB 按鈕
│ ├── Modal/
│ │ └── ModalLogin.js # 登入的 Modal
│ └── index.js # 登入邏輯與主要 Layout
對工程師來說,會忘記之前寫的東西在哪是很合理的,所以在 IDE 有支援搜尋的前提下,我們就需要針對程式碼做一定程度的 SEO,一個最棒的搜尋結果就是當使用者輸入一個關鍵字後只會得到一個最適合的結果。
舉例前端的例子來說,一般團隊有可能會使用 BEM 的命名規則,像是 info__title
這樣代表我們設定的是訊息的標題,所以當進行搜尋時 info__title
就會是我們的關鍵字,如果是底下示範的第一種寫法反而會造成開發者的困擾。
// 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;
}
}
方便搜尋的命名代表程式碼有多方便被修改
舉個例子來說判斷盡量用布林值的概念命名會更方便,隱藏的條件就可以用 isVisible 或是 isDisable 的布林值來控制條件渲染。
function getNowElement({ isVisible, isDisable }) {
const isHidden = !isVisible || isDisable;
if (isHidden) return null;
return <span>show</span>;
}
雖然布林值算好讀,但當命名和布林值寫在判斷式中時,會發現我們還是需要進行思考,也較不直觀,底下舉了兩種例子,可以發現第二種命名來說就會更直觀一些。
const VISIBLE = true;
const HIDDEN = false;
// 需要稍微思考
if (element.visible === true)
// 幾乎不需要思考
if (element.visibility === VISIBLE)
if (element.visibility === HIDDEN)
SOLID 分別代表了六個原則的縮寫
SOLID 原則有助於將程式碼模組化,使不同的功能和關注點分開,目標是當被開發者找到程式碼後,可以更快確認在哪一行產生目前的行為,更容易去判斷在這一階層 (頁面) 的操作只要正確就可以不用煩惱其他階層的任何操作,專注於特定的功能而不必擔心整個系統的細節,進而更容易且安全的去修改和擴展程式碼。