iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 3
0
Modern Web

用 JavaScript 打造全端產品的入門學習筆記系列 第 3

Git 程式碼版本控制 初步上手——全端產品工具箱 II

git logo

git logo from Wikimedia

軟體產品的開發、營運到維護是個失序到有序、複雜到規律的過程。其誕生需要動輒團隊中各種角色:產品經理/營運、UI/UX 設計師、各種工程師、QA 測試人員;還得歷經從需求確認、user story、規格定義、wireframe 設計、prototype 設計、功能開發、反覆測試、正式上線等流程。

而版本控制的完整度、細緻度及嚴謹度,會直接影響維護產品的效能與成本。由於操作型的技術文章已經很多,本篇筆記將聚焦 「如何建立良好的版本控制習慣」

 

為何版本控制很重要?

以學生時期的小組報告為例,如果你看到組員報告修改完後長這樣,會做何感想?

鬆散版本控制的後果

鬆散版本控制的後果

如果放到產品開發中,想必會是公司的災難吧!相對而言,若有優異的版本控制,能帶來以下三點好處:

易於長期維護

產品長期營運的過程中,每次的更新升級可能就牽涉許多檔案,就算有良好的程式架構及檔案分工,難免會遇上修改而產生的衝突。此時,若有版本控制的協助:短期而言,能透過快速切換版本,還原問題尚未產生時的環境;長期而論,還能透過版本紀錄來釐清 Bug 產生的原因,已進行全面修復。

促進團隊協作

對於正式營運的網站及軟體,隨意暫停及更新維護可能都是成千上百萬的損失;從成長面來看,產品優化的速度也是競爭力的指標之一。如果能在不影響現有版本穩定運作的前提下,同時進行優化、更新、修錯,想必能大幅提高營運效能。

而版本控制洽能透過「分支 (branch)」和「合併 (merge)」達到上述目的。

掌握產品全貌

閱讀詳細記錄的產品開發史,能夠協助開發者快速掌握產品全貌。對個人而言,能夠鍛鍊扎實的產品思維、累積良好開發習慣、在開放原始碼的業界中也易於傳播。對團隊而言,無論在哪個階段加入,都能快速上手和銜接。

 

git init 前要做的事

就像航機出發前,機長必定會先確陣航線、方向等無誤後,才會起飛前往目的地。在多數情況,版本控制中最重要的往往是動手開發前的準備。

take off

take off from Unsplash

思考並描繪開發流程

在開始敲鍵盤前,我會先思考專案的開發歷程,並列下所有預計要做的小任務,幫助自己能按部就班、有效地逐一解決問題。

以課程中一個我蠻喜歡又有趣的小專案「幹話產生器」為例,可能就有以下步驟:

  1. 用 Express 初始化專案
  2. 引入前端框架來組裝頁面
  3. 建立生成幹話的演算法
  4. 整合演算法和 app 以實踐功能
  5. 新增 README.md 文件

嘗試事先撰寫 commit message

完成之後可以嘗試轉換成 commit message。這部分沒有標準答案,我的可能也還有很大的改善空間。主要想表達的是,透過事前的文字演練,在還沒開始寫程式碼前,我們就能大致掌握開發的進度。

1. feat: project init
include Express to buildup server
2. feat: include packages to build pretty UI fast
- Handlebars
- Bootstrap
- Font Awesome
3. feat: build algorithm in generate_nonsense.js
- define tasks for different roles and nonsense phrases
- start generating task and phrase of nonsense for selected role
- return the generated nonsense
4. feat: realize the generateNonsense function in app
- Use generateNonsense() and Body-Parser in app.js
- Show nonsense in view
- Keep the content in form
- Return error message
5. docs: add README.md

 

git commit 風格標準推薦

我們知道刻意練習的原則之一,就是找卓越大師來模仿,試圖縮小與他們的差距,就能有感地看見自己的進步。以下彙整兩個讓我受益良多的經驗原則。

Conventional Commits

from Conventional Commits

淬練自經驗的 good commit 原則

  1. 用一行空白行分隔標題與內容
  2. 限制標題最多只有 50 字元
  3. 標題開頭要大寫
  4. 標題不以句點結尾
  5. 以祈使句撰寫標題
  6. 內文每行最多 72 字
  7. 用內文解釋 what 以及 why vs. how

原則摘錄自:

標準化的 conventional commits

在開頭加上 type:

  • feat: 新增/修改功能 (feature)。
  • fix: 修補 bug (bug fix)。
  • docs: 文件 (documentation)。
  • style: 格式 (不影響程式碼運行的變動 white-space, formatting, missing semi colons, etc)。
  • refactor: 重構 (既不是新增功能,也不是修補 bug 的程式碼變動)。
  • perf: 改善效能 (A code change that improves performance)。
  • test: 增加測試 (when adding missing tests)。
  • chore: 建構程序或輔助工具的變動 (maintain)。
  • revert: 撤銷回覆先前的 commit 例如:revert: type(scope): > - subject (回覆版本:xxxx)。

內容摘錄自:

 

git add . 刻意練習到成為習慣

當我們在個人學習階段時可能對版本控制仍感困惑,這時可以試圖想像一下曾經體驗過的粗糙交接,就算幸運的沒遇過,看到下圖也能明白,如果接手一個職責不明、歷史紀錄缺漏的專案,內心應該也是五味雜陳吧?

冰山一角的交接任務

冰山一角的交接任務 edit from jwgecko

如果在學習的過程中倍感興奮,證明你很適合走上這條路,那未來我們勢必有機會成為工程師,用未來看現在的自己,是否會發現學會「版本控制」超重要!

接下來就開始搭配圖形介面的 git 軟體,不斷 git add 大量刻意練習吧,以養成習慣為目標前進!

 


閱讀更多

Infinite Gamer
關於本系列更多內容及導讀,請閱讀作者於 Medium 個人專欄 【無限賽局玩家 Infinite Gamer | Publication – 】 上的文章 《用 JavaScript 打造全端產品的入門學習筆記》系列指南


上一篇
VS Code & Terminal for Mac 初步上手——全端產品工具箱 I
下一篇
GitHub 遠端儲存庫 初步上手——全端產品工具箱 III
系列文
用 JavaScript 打造全端產品的入門學習筆記30

尚未有邦友留言

立即登入留言