前面兩篇文章分享了工程師容易卡住的問題、常犯的錯誤,而這篇文章會聚焦在「協作」這個部分,提供一些方法讓開發團隊發揮更穩定的效能。
大綱➤ 可以一起遵守的 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. 也歡迎您到書局選購支持,透過豐富的案例來重新檢視自己的職涯