运维自动化基础建设|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源创计划”，欢迎正在阅读的你也加入，一块儿分享。