講師介紹
楊周
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 幫助檔案（ 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，了解更多
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/960.html
標籤：其他