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

- 作者：林鼎淵（Dean Lin）
- 網址：https://deanlin.net/blog/202202/better-dev-team-collaboration/
- 發布：2022-02-24
- 主題：團隊合作
- 系列：工程師下班有約
- 標籤：Pair Programming、Teamwork、Commit、Coding Style、團隊合作
- 摘要：前面兩篇文章分享了工程師容易卡住的問題、常犯的錯誤，而這篇文章會聚焦在「協作」這個部分，提供一些方法讓開發團隊發揮更穩定的效能。

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

```
大綱
➤ 可以一起遵守的 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](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)，他支援大部分程式語言的 Format；當然知名的 [ESLint](https://eslint.org/) 也是團隊協作時的好選擇。

> 不同 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 參數沒有傳送到的問題

```

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

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

**如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《[工程師下班有約](https://www.tenlong.com.tw/products/9786264142083)》這本書能為你帶來靈感與啟發：**

  [https://www.tenlong.com.tw/products/9786264142083](https://www.tenlong.com.tw/products/9786264142083)

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

```

---

關於作者：林鼎淵（Dean Lin），台灣的生成式 AI 企業內訓講師、外商資安公司軟體專家，也是生成式 AI 創新學院發起人。出版 7 本書（包含全台第一本 ChatGPT 應用專書），兩度獲得 iThome 鐵人賽佳作，累積上百場授課與顧問經驗。（https://deanlin.net/about/）
引用時請附上原文網址：https://deanlin.net/blog/202202/better-dev-team-collaboration/