從code review到Git commit log

最近在讀一本技術類的書：朱贇——《躍遷：從技術到管理的硅谷路徑》，其中聊了不少頗有趣的觀點，好比：技術管理、技術實踐、硅谷文化、我的成長等。

讀到關於硅谷人如何作code review這一篇時，不禁想到了前段時間看過的一篇博客：如何寫好Git commit log。

以前的工做用Git作版本管理工具，所以每次提交改動時都會寫註釋，其中也踩了一些坑，如今回想起來仍是以爲頗有收穫。

這篇博客，聊聊我我的關於code review和Git commit的一些認知和資料總結，僅供參考。。。

參考資料：《躍遷：從技術到管理的硅谷路徑》

博客：如何寫好Git commit log

 

1、聊聊code review

一、什麼是code review

code review，即：代碼審查。指在軟件開發過程當中，對源代碼進行審查，目的是查找系統缺陷，保證軟件整體質量，團隊內部知識分享，提升開發者自身水平。

Code Review是輕量級代碼評審，所須要的各類成本要明顯低的多，若是流程正確，它能夠起到更加積極的效果。

二、爲何要code review

①、提升軟件代碼質量；

②、及早發現潛在缺陷與BUG，下降風險成本；

③、促進團隊內部知識共享，提升團隊總體水平；

④、評審過程對於參與人員來講，也是一種思路重構的過程，幫助更多的人理解系統；

三、如何進行code review

①、code review目標和原則

發現代碼的正確性

不只是code review，更重要的是學習和分享

高效code review

②、有選擇的進行code review

最近一次迭代開發的代碼；

系統關鍵模塊；

業務較複雜的模塊；

缺陷率較高的模塊；

③、code review的工做流

本篇博客主要介紹基於Git作版本管理工具的code review，所以以Git爲例子說明。由於Git比較靈活，誕生了不少工做流，常見的有下面幾種：

Forking工做流

Gitflow工做流

功能分支工做流

集中式工做流

Pull Request工做流

四、code review具體要作什麼

檢查代碼設計體系的合理性和業務邏輯的正確性；

檢查代碼的可讀性和可維護性；

檢查代碼的功能實現完整性；

檢查代碼的安全性；

五、code review注意事項

保持code review的目標單一性；

確保code review的代碼都是通過測試且測試用例覆蓋率較高；

不要刻意去尋找代碼存在的缺陷；

不要強制別人遵循本身的編碼風格和習慣；

不要抨擊和批評，學會建議和學習；

不要在不肯定的問題上花費太多時間；

學會傾聽和理解別人的建議，同時通過思考再給別人提建議；

六、code review須要自頂向下的支持

制定統一的編碼規範和風格；

統一代碼管理和審覈的流程與工具，並確保你們使用一樣的工具，遵循既定的流程規範；

鼓勵團隊成員幫別人code review，甚至能夠列入績效評估之中；

 

2、聊聊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 <laozhang@163.com>
4 Date:   Sat Aug 11 00:27:46 2018 +0800
5 
6     first commit

編寫commit log的好處有不少，好比：

提升code review的效率；

清晰的描述release分支內容，提高可讀性；

......

總之，一個好的commit log能夠對項目長期的進度提高以及質量管理帶來很大幫助！

 

3、如何寫Git commit log

一、對提交改動的代碼作好分類

在進行code review以前，須要瞭解清楚這部分代碼的核心功能是什麼，而後針對性的進行審覈 ，通常將提交的代碼分爲如下幾種類型：

①、缺陷修復

②、代碼優化

③、系統遷移

④、新功能實現

二、統一commit log的編寫方法和規範

同一個團隊，提交日誌的方法應該一致 。爲了建立一個清晰可用的修改歷史，團隊應該首先對提交信息的約定造成共識，至少明確如下三件事情：

①、風格：包含句語、自動換行間距、文法、大小寫、拼寫，最終的結果就是一份至關一致的日誌，不只可讀性很好，並且能夠按期閱讀；

②、內容：哪些信息應該包含在提交信息的正文中，哪些不用，好比：文件的移動和拆分、函數重構等；

③、元數據：引用問題跟蹤 ID，pull 請求編號等；

 

其餘相關資料連接：

code review應該怎麼作

咱們是怎麼作code review的

如何進行高效的code review

 

以上內容參考了不少其餘同行的資料，我的作了一個整理和總結，僅供參考，若有更好的意見，請在評論區提出交流，謝謝。。。