從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