近日，在极狐 TechTalk 直播上，极狐(GitLab) 高级解决方案架构师杨周分享了高效 Code Review 秘籍以及 Code Review 在理论业务场景中的最佳实际，并手把手带大家基于极狐 GitLab 进行了 Code Review。
以下内容整顿自本次分享，干货爆满，分为高低两期：
- 上期解析👉代码品质问题、分支创立与评审、Git 标准、安全漏洞；
- 下期解析👉代码标准、Code Review 实际中大家最关注的几个问题。
关注「极狐 GitLab」不迷路，一起 get Code Review 小技巧吧！
前言
在软件行业，Code Review 始终被认为是一种十分好的工程实际，但在理论工作中，却三令五申也执行不上来。或是业务跑太快，没工夫 Code Review，或是即便发动 Code Review，但 Reviewer 秒批准，收效甚微……
其实，代码里有很多问题是值得去评审的，工程师本人可能会漠视。比方 Git 标准、代码标准、是否影响老代码、数据库英文术语设计、设计模式，业务逻辑是否正确 等等。
不只是高级工程师在代码评审过程获得提高，高级工程师之间相互评审，也往往能发现一些问题，团队成员都能够互相学习和成长。
常见的代码品质问题有哪些？
随便提交
下图是网上曝光的一个大厂的代码，搞笑但实在。有人在正文外面恶搞，前面的同学看到接着恶搞。当然它也没有什么危害，但这阐明代码没有人管，大家都能够轻易提交，长此以往，代码问题就会逐步的暴发。
无用文件
有的用户反映 Git 越来越慢，通过排查发现，有人提交了 jar 包，比方第三方包 rabbitmq，这是初学者常犯的谬误。
其实依赖包不应该提交代码库，应该通过 maven 网络仓库装置。有人问：不少国产包没有公布到 maven 开源仓库，只提供 jar 包下载，比方云领取，怎么办？好办，公布到极狐 GitLab 公有 maven 仓库即可。
魔法数字
大家在老我的项目里可能都见过 1、2、3、4 这种写法，前面接手的人齐全看不懂，甚至本人过一段时间也忘了。
有个说法叫「优良的代码都是不必正文的」，这句话是有情理的。如果再给右边的代码加正文，须要在 1234 的中央都加，反而累赘。正确做法是用英文常量来示意数字，从而防止这种魔法数字问题。
以上问题最根底的解法就是 Code Review。
创立分支和抉择评审
创立分支的 2 种形式
代码评审的根底是把骨干锁定起来，很多人可能会说：“我晓得，咱们都把骨干分支锁定了，大家都在开发分支上写代码，写完了间接提交，最初开发分支被间接合并骨干分支，就上线了。”但这样的话，爱护机制就形同虚设了。
爱护分支的核心理念是爱护所有公共分支，如 develop，是不能够间接推送的，如果有人尝试推送会间接报错。爱护分支当前，就须要创立长期分支。
怎么创立长期分支才是正规的、高效的？有几种形式。
形式一：本地创立分支，网页创立合并申请
最常见的办法是：
1. 在本地拉分支 git checkout -b；
2. 起一个贴切的、不反复的分支名字，这让不少开发同学头疼，破费了不少工夫考虑；
3. 推送完了当前会提醒关上网页，创立一个合并申请 MR。
这里有三步操作，关上了网页合并申请之后，还要再点一下，效率是比拟低下的。怎么优化？极狐 GitLab 提供了一个十分简洁的形式。
形式二：先创立需要，一键拉分支
首先，创立一个需要或者 bug，而后就能够一键拉分支了。
分支名字主动起好了，用需要 ID 结尾，来确保它的全局唯一性，前面跟着需要题目，英文保留，那汉字怎么办？GitLab 以前是间接抛弃了汉字，作为 GitLab 的中国发行版——极狐 GitLab 主动把汉字转成拼音，更适宜中国开发者。
创立好分支当前，就须要抉择共事进行评审，这也有好几种形式：
抉择评审的 3 种形式
形式一：每次创立 MR 时选人
极狐 GitLab 免费版可选 1 集体，专业版可选多集体。
留神：这里有个草稿性能，草稿不须要审核，也不能合并，前文说的需要一键拉分支，就会主动加上草稿前缀，十分不便。
然而，每次提代码的时候都选人去审比拟低效，到底选几个人适合？选中的人有没有空？这是未知的。因而，极狐 GitLab 提供了一个更高效的形式——提前配置小组评审，这样就不必每次选人了，也不必放心选的人销假了。
形式二：一次设置，多个小组评审
当前端我的项目为例，应该由高级后端小组评审，能够设置须要几个人审，比方金融合规要求至多 2 集体，其余行业为了节约老本往往设置为 1 集体。
还能够设置多个小组评审，比方平安团队也要审核是否有安全漏洞，这是极狐 GitLab 的特色性能，业界很多同类产品不具备该性能。
形式三：代码所有者(Code Owners)
极客同学喜爱这种 Configuration as code（配置即代码）形式。比方这个目录应该谁负责审，把他的名字写上，这里能够是多集体，而后在网页配置里能够看到所有符合条件的用户。
接下来咱们聊聊开发团队十分须要的 Git 标准。
Git 标准
首先要不要在 Code Review 的时候审核 Git 标准？
来看一个实在代码：李雷同学提交了一个分支想要合并，咱们看到间接就正告⚠️了，这里提醒他改了 6000 多行代码，100 多个文件，网页都显示不下了。
这是个常见的谬误——用本人的名字做分支。人名用作分支确实和他人不抵触，但在一个分支里提交好多个需要，而后请共事评审，共事就疯掉了。
那怎么做才是正规的呢？
JiHu Flow
业界的最佳实际是：每个需要一个分支，这也是 JiHu Flow 推崇的做法。严格来说，是每个议题一个分支，议题包含：需要、bug 以及重构工作等各种类型。
那么骨干就没有用了吗？
不是的，骨干用来修复线上的紧急 bug。比方线上 1.2.0 这个版本，有紧急 bug，不可能等下一个迭代去修，那就拉起一个长期分支——Hotfix，修完之后打一个新的 Tag——v1.2.1。这个三位数字的版本号也是有标准的，叫做语义化版本号标准。依照这个标准，当新的迭代想公布时，合并过去须要打一个新的 Tag——v1.3.0，这里的逻辑是：有新性能应该减少数字两头这一位，修 bug 应该加最初一位。
分支命名标准
怎么可能确保大家的分支拉取命名都是标准的呢？靠口头传播？靠入职培训？分支命名标准不可能人工评审，因为分支先推送到服务器，能力评审，为时已晚。
所以分支命名标准应该做成 Git 服务器的钩子性能，只有不标准，就在入库之前进行拦挡。极狐 GitLab 提供了这个性能，能够公司对立配置，也能够在每个我的项目里配置，它是一个正则表达式，能够束缚各种分支命名标准。
咱们看上图这段代码，有人拉了一个分支叫 login，难以看出是需要还是 bug，他没有在网页上依照标准去创立（网页上会主动依照标准去创立，不须要人去干涉），本人手动拉的话就会很难恪守这个标准。当他 push 的时候，间接就会报错，基本推送不上来。
咱们再看看上图这个代码有没有别的问题？能够看到上面有一个 PDF，十分奇怪，PDF 是二进制文件，为什么要提交 Git？可能是要放在公司的网盘里，就大家看一看就好了。
那怎么拦挡？很多同学对 Git 比拟熟，晓得用 gitignore，但它只能拦挡已知的文件，拦了 PDF，又有人提交了 word，或者 MP4 视频……防不胜防。
怎么拦挡这种无穷无尽的后缀？极狐 GitLab 提供了一个高级玩法，拦挡文件大小就能够了。
杜绝提交垃圾文件
比方能够拦挡任何大于 1M 的文件，大于 1M 的话，十有八九它不是代码。如果是一个大的游戏素材，确实须要提交的库里，那怎么办呢？能够用 git lfs (大文件存储)，这里就不开展说了。
也能够配一些常见的文件名，比方 Jar 包这些，它与 gitignore 的区别是能够在整个公司群组级别设置，对所有新我的项目失效，这样即便新我的项目开发组长没有配 gitignore 也不要紧。
合并申请：git log
咱们来看看上面这个代码合并页面有没有什么问题。
能够看到提交信息十分的诡异，2.2.0 版本公布了两次，批改了一个 readme 文档，修了一个 bug，做了一个需要，但齐全看不出来修了什么 bug。
这是小白常犯的谬误，正确的写法应该是什么样呢？
下图是出名的开源我的项目 angular，前端同学可能比拟熟，它的写法就很漂亮，比方：docs 阐明改了什么文档，fix 阐明修了什么 bug。
这些标准如何学习？如何在团队落地呢？
git cz 取代 git commit
学习好办。大家在本地装置 git cz 命令，配置 angular 标准来取代 git commit，就会弹出来 10 个英文前缀供选择。但这个办法是大家本地学习用的，不可强求，有得人本地电脑就没有装置。
那么作为开发组长、研发管理人员，应该怎么在团队内落地标准呢？
查看 commit message
在极狐 GitLab 的仓库配置里，能够配置 commit message 标准正则表达式。咱们约定 10 来个前缀，前面能够写汉字，如果团队英文程度都很好的话，也能够要求写 a 到 z。这样如果有人瞎提交，一推送就会失败。
代码关联需要
即便咱们严格依照方才说的格局去写，比如说 build: server env，写的时候晓得什么意思，过了一段时间就记不得了，他人看着也有点晕，这里到底是做了什么需要？
因而，更好的形式是把需要 ID 写上，叫做 代码关联需要，如下图成果，“#1”就会变成一个链接，点过来就是这个需要。
提交的时候也不必写很长，一个需要可能很简单，咱们很难去形容它，有 ID 十分不便了，这个配置也是在 commit message 标准里，大家配一下“#\d+”就能够了。
Git 标准总结
GitLab 最后诞生的时候，就做了 Git 仓库性能，所以在 Git 标准方面十分成熟，包含 commit message、标准的正则表达式、垃圾文件后缀拦挡、文件大小拦挡，分支命名标准 等罕用的性能，这些都属于 Git Workflow。
在 Code Review 过程中，如果配好了极狐 GitLab，就帮你解决了大部分标准落地的问题，齐全不须要人去干涉，节俭了高级工程师的工夫。
安全漏洞
代码反复
举个🌰：有一天，李雷提交了 pom.xml，做了新业务，引入了一个 log4j 2.14.1。评审的同学质疑 log4j 旧版本如同有破绽，那么李雷就须要去查看哪个版本没有破绽。这时候李雷就十分的郁闷，引了那么多包，哪个包有破绽谁晓得？靠人工去核实每个包效率也太低了。
过后 Apache Log4j 破绽大暴发就产生了很大的危害，因为开发同学不可能投入很多精力去盯着哪个破绽又暴发了，所以 Apache 过后紧急修复了好几个版本，新版本收回来又被发现有破绽，大家都十分抓狂。
开源破绽库
这几年平安问题越来越严厉，各种破绽层出不穷，于是 GitLab 做了一个开源破绽库，有专职的平安人员去保护它，寰球开发者也一起参加，做成了一个开源的 Git，这也是 极狐 GitLab 的技术理念，叫做所有皆代码 。咱们偏向于把所有的配置都存到 Git 仓库里， 一方面便于用户开源合作，另一方面 Git 是一个很好的技术底座，能够和各种工具买通，如果存成别的格局，就很难买通了。
有了破绽库当前，怎么执行？
很简略，先把破绽库克隆下来，放在一个本地目录里，而后执行一下就好了。咱们把这些平安工具都封装成了 docker，执行起来非常简单，并且能够离线合规运行。
像金融等行业要求各种工具和代码扫描都必须在内网里运行，极狐 GitLab 是齐全反对的，能够定时在联网的环境下拉取破绽库，再转移到内网里，来确保安全合规。
当然下面说的是原理，实际上咱们不是在本地敲命令，而是心愿安全漏洞可能主动被拦挡，不须要人工去做任何操作，那么怎么来配置？
离线运行，平安合规
上图是一个 GitLab CI 的配置，就是一个 yml 文件。这是一个 Java 我的项目，外面就执行了一个 build 命令，收集了编译的 Jar 包。想要在外面 引入平安扫描，只有两行代码：
CI 官网插件：一键配置平安扫描
这就是极狐 GitLab 的插件机制，yml 外面可能有几百上千行，大家也能够在开源代码找到它，去学习它的写法，并且能够做本人的插件，给本人的我的项目用，给整个公司用，甚至开源进来给大家用。
写了这一行之后，它就会在咱们提交代码合并时进行平安扫描拦挡，MR 页面两头呈现一个模块，叫做平安扫描，发现了 4 个破绽——Apache log4j，不容许合并。
每个破绽都能够点开，比方这里提醒要把这个包降级到某某版本，就毁灭破绽了。解决方案就来自于 GitLab 破绽库。
以前，想解决安全漏洞问题，须要平安人员来去钻研破绽库，选型平安工具。当开发同学的代码，通过 Code Review 之后合并上来，部署到测试环境，平安人员下来扫描，有问题就打回批改当前再提交。
这个跨部门的反馈周期是很长的，怎么提高效率？
平安左移
咱们能够把平安工具左移，放到继续集成里，主动下载破绽库跑起来，这样当开发人员提交代码的时候，有问题的间接打回自助批改。这个就是业界的平安左移理念，叫做 DevSecOps。
极狐 GitLab 的依赖扫描反对各种语言，如 Go、PHP、Java、NPM。
极狐 GitLab 还提供九大平安扫描能力，除了依赖扫描之外，还有动态扫描、动静扫描，以及容器扫描比方 Docker 等。当初很多公司当初曾经用上 Docker 了，还有很多正在做容器化。Docker 外面一不小心引入的根底镜像里，就可能有很多破绽，肉眼是看不出来的，须要扫描工具去发现。
极狐 GitLab 安全漏洞防护，依附流水线的自动化，让开发同学自主修复，从而进步研发效率。在 Code Review 的时候，弹出来并自助修复。
🌟《高效 Code Review 秘籍以及 Code Review 在理论业务场景中的最佳实际》上期就分享到这里，心愿对你有所启发和帮忙 😊
下期精彩，敬请期待！