前面兩篇文章分享了工程師容易卡住的問題、常犯的錯誤，而這篇文章會聚焦在「協作」這個部分，提供一些方法讓開發團隊發揮更穩定的效能。
大綱➤ 可以一起遵守的 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### description1. 解決排序無效 bug
2. 在「異常」欄位增加是否為 null 的判斷，避免字串切割異常
3. 解決 pagination 參數沒有傳送到的問題
筆者認為「簡單、易懂」為第一優先，中英文表達都可以。
相信還有很多可以讓開發團隊協作更愉快的工具與方法，期待大家的留言分享～
下班有約系列文▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式(本篇)
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！▶︎ 如果這篇文章有幫助到你1. 可以點擊下方「Follow」來追蹤我～
2. 可以對文章拍手讓我知道 👏🏻你們的追蹤與鼓勵是我繼續寫作的動力 🙏🏼▶︎ 如果你對工程師的職涯感到迷茫1. 也許我在iT邦幫忙發表的系列文可以給你不一樣的觀點 💡
2. 也歡迎您到書局選購支持，透過豐富的案例來重新檢視自己的職涯
