讓開發團隊更好協作的方式 — 下班有約系列文

前面兩篇文章分享了工程師容易卡住的問題、常犯的錯誤，而這篇文章會聚焦在「協作」這個部分，提供一些方法讓開發團隊發揮更穩定的效能。

大綱
➤ 可以一起遵守的 Coding Style
➤ 使用相同的程式碼 Format 工具
➤ 沒有明確 Git Flow 機制會發生什麼事？
➤ 制定團隊 Git Flow 的規則

可以一起遵守的 Coding Style

即使是有經驗的工程師，在同一個專案中也很常不小心有多種命名的風格，下面列出幾個建議：

• 變數與函式：都用小駝峰式（camelCase）的命名，ex：downloadDoc、deleteDoc。
• 常數命名：會建議使用全大寫英文命名，字詞間使用下底線（_）連接，ex：VUE_APP_ROOT_API。
• 少用簡寫或自己發明縮寫：就算是本人，幾個月後也會忘記自己當時創造的東西。
• 不要拼錯英文單字：當程式結構越來越大，我們會透過搜尋來找答案，如果你拼錯就會造成大家的困惑。
• 字串單引號、雙引號統一：儘管在 JavaScript 中兩者皆可運行，但在閱讀體驗上就會有點不舒服。

使用相同的程式碼 Format 工具

其實上面的問題大部分可以透過「工具」來解決，但必須律定團隊使用「統一」的工具。

如果團隊沒有統一的工具，會導致你每次在更新專案時，明明只更新一行，但因為每個人 Format 工具不同導致在 Merge Branch 時看起來幾乎是重寫。

這邊推薦使用 VSCode Extensions 的 Prettier，他支援大部分程式語言的 Format；當然知名的 ESLint 也是團隊協作時的好選擇。

不同 Format 工具的斷行字數、單引號、雙引號、結尾有沒有「;」…的習慣都不一樣，如果大家不統一，你看 diff 時會覺得很崩潰並且浪費時間。

沒有明確 Git Flow 機制會發生什麼事？

如果沒有一套基礎簡單的規則，你可能會遇到以下障礙：

• Deploy（部署）沒有基準：正式機、測試機要用哪個 Branch？如果每次都不一樣，那遲早都會出事。
• 花很多時間在 Merge Branch（合併分支）上：如果不是從同一條 Branch 分支出去，那在 Merge 時很容易出現各種衝突需要解決。
• 難以從 Branch 追蹤作業進度：有些人會只用一條 Branch 從頭做到尾，造成單純看這個分支無法理解他到底完成了哪些功能。
• 無法理解的 commit 內容：每個人都有自己的 commit 風格，導致追溯歷史時很難找到節點。
• 任務交接時的困擾：有些人沒有定期 push 的習慣，喜歡累積非常多的 commit 再一次 push；這樣如果他突然請假，或剛好在忙其他事情時，職務代理人並無法協助處理他的任務，甚至重工浪費時間。

制定團隊 Git Flow 的規則

下面是筆者團隊在各個 Branch 的規則：

🏷️ Master

• 功能：部署到正式機的 branch
• Merge request：由資深工程師或是技術主管審核

🏷️ Develop

• 功能：部署到測試機的 branch
• Merge request：由資深工程師或是技術主管審核

🏷️ Feature

• 命名方式：依功能命名，如果有任務編號的話一同附上，方便日後追蹤
• 基礎規則：原則上都是從 Develop 分支出去，每個 Feature 的功能盡量細分到可以在一天內完成

🏷️ Hotfix

• 命名方式：依功能命名，如果有任務編號的話一同附上，方便日後追蹤
• 基礎規則：原則上是為了解決正式機上面的緊急 Bug，因此通常是從 Master 分支出去；完成修改後再合併回 Master、Develop

🏷️ Release

• 命名方式：依釋出的版本命名
• 基礎規則：當有一個大版本準備部署到正式機，為了保證系統穩定性，會先從 Develop 分支 Release 的版本

以及其他希望大家一起遵守的細節：

• 完成 Feature 時要 push 一版，並通知協作夥伴確認功能。
• 如果該 Feature branch 已經 merge 回 develop，且不會再使用該 branch，就需要把它給 delete 掉，避免線上有太多分支，會不清楚哪一個才是有在作用的。
• 每天下班前至少要 push 一版，讓管理者容易掌握進度。
• commit 可以用「新增功能、變更功能、修補 Bug」作為 title 的分類，然後將調整的內容條列式寫入 description，這樣其他人在 Code Review 時可以知道重點，範例如下：

### title
修補 Bug：解決職員列表 issues
### description
1. 解決排序無效 bug
2. 在「異常」欄位增加是否為 null 的判斷，避免字串切割異常
3. 解決 pagination 參數沒有傳送到的問題

筆者認為「簡單、易懂」為第一優先，中英文表達都可以。

---

相信還有很多可以讓開發團隊協作更愉快的工具與方法，期待大家的留言分享～

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式(本篇)
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！