從code review到Git commit log
最近在讀一本技術類的書：朱赟——《躍遷：從技術到管理的矽谷路徑》，其中聊了很多很有趣的觀點，比如：技術管理、技術實踐、矽谷文化、個人成長等。
讀到關於矽谷人如何做code review這一篇時，不由想到了前段時間看過的一篇博客：如何寫好Git commit log。
之前的工作用Git做版本管理工具，因此每次提交改動時都會寫註釋，其中也踩了一些坑，現在回想起來還是覺得很有收獲。
這篇博客，聊聊我個人關於code review和Git commit的一些認知和資料總結，僅供參考。。。
參考資料：《躍遷：從技術到管理的矽谷路徑》
博客：如何寫好Git commit log
一、聊聊code review
1、什麽是code review
code review，即：代碼審查。指在軟件開發過程中，對源代碼進行審查，目的是查找系統缺陷，保證軟件總體質量，團隊內部知識分享，提高開發者自身水平。
Code Review是輕量級代碼評審，所需要的各種成本要明顯低的多，如果流程正確，它可以起到更加積極的效果。
2、為什麽要code review
①、提高軟件代碼質量；
②、及早發現潛在缺陷與BUG，降低風險成本；
③、促進團隊內部知識共享，提高團隊整體水平；
④、評審過程對於參與人員來說，也是一種思路重構的過程，幫助更多的人理解系統；
3、如何進行code review
①、code review目標和原則
發現代碼的正確性
不僅是code review，更重要的是學習和分享
高效code review
②、有選擇的進行code review
最近一次叠代開發的代碼；
系統關鍵模塊；
業務較復雜的模塊；
缺陷率較高的模塊；
③、code review的工作流
本篇博客主要介紹基於Git做版本管理工具的code review，因此以Git為例子說明。因為Git比較靈活，誕生了很多工作流，常見的有下面幾種：
Forking工作流
Gitflow工作流
功能分支工作流
集中式工作流
Pull Request工作流
4、code review具體要做什麽
檢查代碼設計體系的合理性和業務邏輯的正確性；
檢查代碼的可讀性和可維護性；
檢查代碼的功能實現完整性；
檢查代碼的安全性；
5、code review註意事項
保持code review的目標單一性；
確保code review的代碼都是經過測試且測試用例覆蓋率較高；
不要刻意去尋找代碼存在的缺陷；
不要強制別人遵循自己的編碼風格和習慣；
不要抨擊和批評，學會建議和學習；
不要在不確定的問題上花費太多時間；
學會傾聽和理解別人的建議，同時經過思考再給別人提建議；
6、code review需要自頂向下的支持
制定統一的編碼規範和風格；
統一代碼管理和審核的流程與工具，並確保大家使用同樣的工具，遵循既定的流程規範；
鼓勵團隊成員幫別人code review，甚至可以列入績效評估之中；
二、聊聊Git commit
之前的博客介紹過Git基礎使用教程和和Git分支管理規範，在每次代碼改動之後，都需要將本地分支的代碼提交到暫存區，編寫commit log，然後推送到遠程倉庫。
所謂的commit log，就是對每次代碼的改動進行說明和註釋，示例如下：
編寫commit log：
1 $ git commit -m ‘first commit‘
2 [master (root-commit) d8fedf7] first commit
3 28 files changed, 396 insertions(+)
查看commit log：
1 $ git log
2 commit d8fedf7548e2f1314e7bfc0ffc3a1d4612c83e9e (HEAD -> master, origin/master)
3 Author: laozhang <[email protected]>
4 Date: Sat Aug 11 00:27:46 2018 +0800
5
6 first commit
編寫commit log的好處有很多，比如：
提高code review的效率；
清晰的描述release分支內容，提升可讀性；
......
總之，一個好的commit log可以對項目長期的進度提升以及質量管理帶來很大幫助！
三、如何寫Git commit log
1、對提交改動的代碼做好分類
在進行code review之前，需要了解清楚這部分代碼的核心功能是什麽，然後針對性的進行審核 ，一般將提交的代碼分為以下幾種類型：
①、缺陷修復
②、代碼優化
③、系統遷移
④、新功能實現
2、統一commit log的編寫方法和規範
同一個團隊，提交日誌的方法應該一致 。為了創建一個清晰可用的修改歷史，團隊應該首先對提交信息的約定形成共識，至少明確以下三件事情：
①、風格：包含句語、自動換行間距、文法、大小寫、拼寫，最終的結果就是一份相當一致的日誌，不僅可讀性很好，而且可以定期閱讀；
②、內容：哪些信息應該包含在提交信息的正文中，哪些不用，比如：文件的移動和拆分、函數重構等；
③、元數據：引用問題跟蹤 ID，pull 請求編號等；
其他相關資料鏈接：
code review應該怎麽做
我們是怎麽做code review的
如何進行高效的code review
以上內容參考了很多其他同行的資料，個人做了一個整理和總結，僅供參考，如有更好的意見，請在評論區提出交流，謝謝。。。
從code review到Git commit log