運維自動化基礎建設|CodeReview

運維自動化基礎建設|CodeReview

提到code review，相信你們對此並不陌生，各大廠也時不時的會有各類文檔出來，這是一個很深的話題，也是一門玄學，接下來的文檔裏以我有限的認知來聊聊我所理解的code review。

code review 流程

code review 流程圖片來源^[1]

code review前置工做

曾經流傳一個段子，一個新手提交了10行代碼，而後收到了500個的issue, 有一次提交了500行代碼，收到了0個issue，雖然是一個段子，從中咱們不難看出一些問題：

代碼風格的問題

代碼風格的統一在每一個公司落地實踐的方式各不相同，有的公司是經過IDE的各類插件來實現代碼風格的統一(不過這種方式也很差統一，畢竟有的人買了idea, 有的人喜歡用vscode), 有的公司是經過pre-commit或post-commit方式來實現代碼風格的統一。

若是你做爲code review的人，看到提pr的人的代碼不知表達什麼意思的變量或函數命名，或者一屏幕看不到頭的一行代碼，你內心是否會mmp, 還有繼續看下去的心情麼。

Google Style Guides^[2]

Commit Message 的問題

Commit Message信息的標準化也是一個重頭戲，做爲code review的人，看到一句修復bug的commit信息，確定是有砸電腦的衝動，因此統一規範化的信息提交是一個團隊要遵照的規範之一，要否則的話，那就呵呵了。能夠參考下下面的文檔，看看別人家的Commit Message規範是如何作的。

優雅的提交你的 Git Commit Message^[3]

code review 放在哪一步進行

動做

我我的的感覺是看團隊規模大小吧，小規模團隊的狀況下，放pre-commit下作code style的風格統一的動做足夠知足需求，大些的團隊多半會把這些工做放到CI裏去作，你們能夠看下Github Action，自定義組合感覺下，常規的語法檢測，代碼格式化操做等等工做。

共識

若是一個團隊中沒有達成共識，或者沒法取得承認的場景下，強推code review的結果可能不是很理想，另一個方式就是自上而下的強推，須要一個漫長的適應期。

具體落地

這個涉及到前面咱們提到的分支模型的選擇，在分支模型落地的基礎上(不容許用於直接提交代碼，只能提PR)，用戶提交PR, 至少須要兩我的進行Approve(投票，bitbucket中稱做點贊)才容許進行Merge的動做。

運維自動化基礎建設|代碼分支模型

相關工具

開源工具，不限於下面所列（能夠深挖Gitlab, 結合Flask實現內部的Code Review平臺）

基於python語言的rietveld^[4]

reviewboard^[5]

phabricator^[6]

gitlab code review^[7]

Gerrit^[8]

收費工具

The 8 Best Tools For Code Review In 2020^[9]

•AccessLint•Imgbot•LGTM•DeepSource•Codelingo•DeepScan•CodeScene•FeaturePeek

參考文檔

Google Engineering Practices Documentation^[10]

Code review checklist^[11]

Code Review Review is the Manager's Job^[12]

How to give great code review feedback^[13]

How one code review rule turned my team into a dream team^[14]

code-review-tools^[15]

總結

code review是一門玄學，就像人跑步同樣，剛開始的時候你會以爲，真特麼累，這不是本身給本身找事麼，過了適應期，你會發現，真香~

時間久了你會發現，市面上開源的這些工具不足以知足需求，二開是不可避免的趨勢。

雖然你們都在口口聲聲的說着code review, 可是真正用起來的團隊不多不多。說到這個不得不提TDD, 本身領會吧~

引用連接

[1] code review 流程圖片來源: https://www.freecodecamp.org/news/how-code-reviews-work-at-microsoft-4ebdea0cd0c0/
[2] Google Style Guides: http://google.github.io/styleguide/
[3] 優雅的提交你的 Git Commit Message: https://juejin.im/post/5afc5242f265da0b7f44bee4
[4] 基於python語言的rietveld: https://github.com/rietveld-codereview/rietveld
[5] reviewboard: https://demo.reviewboard.org/r/
[6] phabricator: https://www.phacility.com/phabricator/
[7] gitlab code review: https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html
[8] Gerrit: https://www.gerritcodereview.com/
[9] The 8 Best Tools For Code Review In 2020: https://featurepeek.com/blog/the-8-best-tools-for-code-review-in-2020/
[10] Google Engineering Practices Documentation: https://google.github.io/eng-practices/
[11] Code review checklist: https://dev.to/uday_rayala/code-review-checklist-20c6
[12] Code Review Review is the Manager's Job: https://hecate.co/blog/code-review-review-is-the-managers-job
[13] How to give great code review feedback: https://www.michaelagreiler.com/great-code-review-feedback/
[14] How one code review rule turned my team into a dream team: https://medium.com/inside-league/how-one-code-review-rule-turned-my-team-into-a-dream-team-fdb172799d11
[15] code-review-tools: https://kinsta.com/blog/code-review-tools/

本文分享自微信公衆號 - 追馬Linux（zhuima_k8s）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。