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 的使用時機

一、在 IDE 裏實時運行，邊寫邊檢查，這樣是最方便的，缺點是須要每一個人都進行配置。

二、Git commit 提交代碼時檢查：每一個 Git 項目都有 .git/hooks 目錄，修改裏面的 pre-commit 腳本，便可在提交代碼時進行攔截檢查。缺點是可被刪除。

三、最可靠的就是服務端檢查。當代碼推送到服務器上時，進行持續集成檢查，這種方式很是可靠且不會被刪除，缺點就是不如本地那麼及時。

這三種方式通常結合使用。

• 增量檢查

老項目的規範問題每每不少，一次清理乾淨須要耗費大量人力，並且一次改動的代碼越多，風險就越高，可能致使線上故障，尤爲是缺少自動化測試的項目。

因此建議使用增量檢查。若是同窗們對 git 命令熟悉的話就很好理解，增量檢查就是 git diff。在本地提交時 git diff 能夠拿到全部新增的、修改的和刪除的文件，只要把刪除的文件排除掉，把別的文件挑出來，傳遞給 lint 程序就能夠了。同窗們必定要熟悉 Linux 命令、git 命令，不要一直用 git 的圖形界面，那你就很難掌握這些內容。

訪問 CODING 幫助文檔（ https://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。因此不能看見自動化檢查過了，就直接贊成合併，這是不負責任的作法，必定要進行人工檢查。

通過這個流程，同窗們的代碼就會很是乾淨漂亮，團隊協做的風格也一致了。通常會挑一個知名的業界大廠的代碼規範，而不要本身發明規範，這樣不只不能服衆，並且之後再參加開源項目的話，難以和業界保持一致。

點擊觀看課程回放

關於 CODING，瞭解更多