CODING DevOps 程式碼品質實戰系列第一課：程式碼規範與 Git Flow
講師介紹
楊周
CODING DevOps 架構師
CODING 佈道師
連續創業者、DIY/Linux 玩家、知乎小 V，曾在創新工場、百度擔任後端開發。十餘年一線研發和帶隊經驗，經歷了 ToB、ToC、O2O、中國、出海各種項目，見證了雲計算時代的誕生，擅長研發最佳實踐：Code Review、DevOps、Git Workflow、敏捷開發、架構、極客辦公硬體。
背景
隨著 ToB（企業服務）的興起和 ToC（消費互聯網）產品進入成熟期，線上故障帶來的損失越來越大，程式碼品質越來越重要，而「品質內建」正是 DevOps 核心理念之一。而且提高程式碼品質的最佳實踐，不只適合新項目，也為老項目提供完善的漸進式方案。
常見程式碼品質問題
- 英語拼寫錯誤
- 泄露密碼
- 無效注釋
- 魔法數字
- hard code（寫死）
- 縮進等程式碼風格問題
如何解決程式碼品質問題
Code Review
第一步是鎖定主幹，禁止直接提交，採用多分支開發。先拉取一個分支，修改程式碼並推送分支，然後發起一個合併請求，請同事進行程式碼評審了。比較高級的技巧是推程式碼時自動創建一個合併請求，合併後臨時分支被自動刪除。
創建合併請求後，需要把鏈接發給同事進行評審，這也是敏捷開發倡導的一個理念——高效溝通。一般選擇直接通過企業聊天工具通知同事，如果不及時通知，可能同事好幾天才會看到，耽誤項目進度。收到合併請求後，請盡量做到當天評審，不要拖延。
需要注意每次提交程式碼只提交最小粒度的一件事，即「原子性提交」，而不要把幾件事做完一次性提交。比如有三件事，其中一件是修 Bug，結果修的有問題要回滾。如果三件事分三次提交，就可以輕鬆回滾有問題的，另外兩個正確的不受影響；而一起提交的話就沒法回滾。
Code Review 一定是在每次程式碼合併進去之前進行評審，發現問題減少故障，如果錯誤的程式碼已經合併上線了，這個時候再看就叫「故障反思會」而不叫「Code Review」，就沒有意義了。
Lint 程式碼規範的增量檢查
Lint 叫程式碼靜態掃描程式，各種語言對應的 Lint 程式是不同的，對應的規範也不同：
- Lint 的使用時機
1、在 IDE 里實時運行，邊寫邊檢查，這樣是最方便的，缺點是需要每個人都進行配置。
2、Git commit 提交程式碼時檢查：每個 Git 項目都有 .git/hooks 目錄，修改裡面的 pre-commit 腳本，即可在提交程式碼時進行攔截檢查。缺點是可被刪除。
3、最可靠的就是服務端檢查。當程式碼推送到伺服器上時，進行持續集成檢查，這種方式非常可靠且不會被刪除，缺點就是不如本地那麼及時。
這三種方式一般結合使用。
- 增量檢查
老項目的規範問題往往很多，一次清理乾淨需要耗費大量人力，而且一次改動的程式碼越多，風險就越高，可能導致線上故障，尤其是缺乏自動化測試的項目。
所以建議使用增量檢查。如果同學們對 git 命令熟悉的話就很好理解，增量檢查就是 git diff。在本地提交時 git diff 可以拿到所有新增的、修改的和刪除的文件，只要把刪除的文件排除掉，把別的文件挑出來，傳遞給 lint 程式就可以了。同學們一定要熟悉 Linux 命令、git 命令，不要一直用 git 的圖形介面，那你就很難掌握這些內容。
訪問 CODING 幫助文檔（ //help.coding.net/ ），搜索「增量檢查」，即可看到完整的配置程式碼。
Git workflow
單兵作戰的時代就如上圖所示，一個人提交程式碼，不需要什麼工作流，一直往主幹里提交就可以。而現在多人協作做項目時，每個人都往主幹里提交就會產生衝突。如下圖所示，多分支開發，每個需求每個 Bug 都拉一個小分支，開發完畢再合併進主幹里。
有兩種常用的工作流，第一種最簡單叫：Feature branch workflow（需求分支工作流）。可以從下圖中看到主分支里拉下來兩個分支，一個做登錄，一個做支付。登錄做完就合併進去，後續有個簡訊的 bug 修復了，也合併進去後就發布了，但支付功能還在開發，這時就會出現問題。本來登錄和支付要一起上線，表示同一時期同一階段的兩個功能相互有依賴，結果因為線上的簡訊 bug 修復，就把登錄先帶上線了，這就導致了問題，所以大項目不適合用這種模式，而是使用第二種。
簡易 Git Flow 是雙分支的開發模式，除主分支外還有一個 develop 分支。Develop 分支對應敏捷開發里的迭代，每次迭代都會創建一個 develop，這次迭代里的所有功能開發完都合併到 develop，而不會合到主幹上。主幹保持隨時可發布的狀態，有 Bug 就在主幹上修，等這次迭代全部結束，再把 develop 合到主幹上。
Fork
Fork 不是工作流，團隊協作一定不要用 Fork。Fork是專門用於開源項目的。當我們試圖修改開源項目時，由於沒有創建分支的許可權，只能把這個項目復刻（官方翻譯）成為自己的項目，然後再在自己的項目里拉分支，修改程式碼，最後發起一個跨項目的合併請求，合併到作者的開源項目里，如果後面還想再開發的話，需要再同步過來。所以 Fork 僅僅用於開源協作，完全不適合團隊協作，同學們千萬不要搞錯，具體的文檔可以掃碼進行查看。
結語
最後總結一下程式碼品質的升級路線。從最原始的提交主幹不檢查程式碼，不檢查規範，到鎖定主幹進行人工檢查，然後人工檢查太累，希望能做自動檢查，把盡量多的東西都做成自動檢查。但有些東西是自動檢查做不了的，比如程式碼里使用了拼音，語法沒有報錯；或者英文單詞用錯，比如用戶的「積分」應該使用points 而不是integral。所以不能看見自動化檢查過了，就直接同意合併，這是不負責任的做法，一定要進行人工檢查。
經過這個流程，同學們的程式碼就會非常乾淨漂亮，團隊協作的風格也一致了。一般會挑一個知名的業界大廠的程式碼規範，而不要自己發明規範，這樣不僅不能服眾，而且以後再參加開源項目的話，難以和業界保持一致。
