Codereview

近日，在极狐 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 ，是不能够间接推送的，如果有人尝试推送会间接报错。爱护分支当前，就须要创立长期分支。 ...

本文首发于泊浮目标掘金:https://juejin.cn/user/146860...版本日期备注1.02022.8.3文章首发1.12022.8.10依据反馈改良内容0.前言最近接了几个我的项目，代码品质参差不齐。本想依照以往的实际倡议每个patch都做review，但往往dead line当头。我会想，我如果对这次patch做了review、以及长期做review能给业务带来什么价值。接着本文，我还想探讨其余技巧在coding中也可能显著带来价值。 留神，这里的价值指的是可量化的价值。常见的说法可能是有利于零碎长期的可维护性、稳定性等，但无奈给出相干指标。但咱们须要晓得，数据思维要优于教训积淀。 1. 期间最重要期间很重要，依据不同的期间，咱们会抉择不同的生存，也会抉择不同的投资策略。技术也是，之前听王志猛的分享，给出了一个很接地气的技术倒退阶段： 能用好用卓越在商业模式或者业务价值被验证之前，最好是谋求速度。这就像你饿着肚子要去打猎，你不会在意这把武器有多丑陋，而是它能不能帮忙到你打到猎物防止饿死。这就是能用的阶段。 CodeReview往往产生在好用和卓越的阶段。这个时候我的项目的价值曾经被验证，须要配合业务倒退进一步的迭代。这里也能够拆分细说： 好用即齐全满足业务需要。卓越即在齐全满足业务需要的根底上，可能用更少的老本。无论是从业务还是技术的角度做到行业顶尖。而CodeReview的价值就是从好用开始产生的，这个时候往往关注如何稳固的迭代业务。而到了卓越期间，CodeReview显得更加重要——这个时候承载的业务往往是有体量的，须要更加留神业务的稳定性和连续性；同时团队规模也在扩充，须要进一步关注降本增效。 2. CodeReview的双刃剑我本人是参加过很多CodeReview的，在ZStack每个patch都要找相应的maintaner review当前才能够合入主干，总体Review的粒度也很细。就对集体而言，我很多的Coding技巧就是在那个时候学来或者收到启发的。但这具备肯定的老本——我举个例子：比方有一个性能开发了3天，测试测了3天也测过了，当初进行骨干合入，maintaner看了半小时，提了10个comment须要改良。那么开发就须要去批改并测试（花了1天），并再次配合测试进行测试（测试花了2天），最初骨干合入，那么就比原来的6人天多出了3人天，50%的人天增长。 或者咱们能够聪慧点，搞个develop分支：那么就是开发提交代码，review后再次批改并自测，而后再提交合入，交给测试测试。但总体来说，还是带来了研发“额定的老本”，maintaner往往是业务的次要角色，他的工夫也很贵重。 在沃趣时，我的项目迭代炽热时一天有10多个patch须要我review，于是我一天都在review，起初缓缓的把不同的我的项目、模块拆给不同的负责人，这种状况才好了点。 如果你正在思考引入CodeReview，并且确实是在好用到卓越的过程中。那么我感觉首先要和下层达成共识，对于这额定产生的人力老本如何进行成本计算。当初在ZStack CodeReview由CEO张鑫直推，因而我不分明那时是如何显式量化CodeReview带来的价值。但据我所知，一些大厂都有相应的研发效力洞察平台，会依据大量指标来掂量研发效力，本文谈到相干办法得出的指标可能只是其中的沧海一粟，思考到管制篇幅，不再开展。 而对于引入的CodeReview里的实际规定来说，我认为重点是关注宏观上的设计。举个例子，如果咱们写一个简单的业务平台，而不是简略的CRUD业务（比方图书馆借阅零碎），用“经典”的三层架构，那么无论你的代码细节标准抠的多好（缩小if else技巧，每个函数不能超过x行之类的）最终都是难以迭代的。而当咱们借用了整洁架构的思维后——无论是DDD还是六边形架构或者是SOLID、设计模式、经典编程思维，咱们会发现相比那些蹩脚的小细节，放弃宏观的整洁才是最重要的。 令人惆怅的是，很多自动化检测工具都是关注宏观的细节，而可能关注宏观整洁的工具少之又少。这是能够了解的，不同我的项目对于宏观整洁的要求是不同的，众口难调。举例：咱们的住处往往区域明确，厨房里摆着餐具，卧室里有床铺。即便厨房里的锅或者铲子放的地位有点乱，也不是难以承受——这就是宏观上的整洁，宏观上的小蹩脚；而如果咱们厨房里叠着一个洁净的床单，卧室里有一个锅，就算他们摆放得再参差，这也违反了宏观的整洁，即便在宏观上来说他们很整洁。 另外一个简略暴力的伎俩则是白盒测试的覆盖率，尤其是单元测试。可能轻易编写单元测试的代码相对来说比拟松耦合，因而将白盒测试的覆盖率作为review的考查重点是个不错的抉择。 3. 如果不写代码就能够不Review了正如小标题所说，既然review代码代价这么大，那罗唆不写代码了。比如说咱们能够用DSL。 这种做法其实十分常见，做过大数据的都晓得MapReduce或者Strom，编写它们要关注大量的细节，比方数据如何shuffle，如何保障可靠性。而现在咱们用FlinkSQL则齐全不必关注这些底层的细节，咱们只需关注数据从哪来，怎么做业务解决，而后落哪儿去。这就是陈词滥调的申明式编程，而不是面向过程编程。 同样的思维，也体现在K8S的申明式API上，写好配置申明而后提交，就等资源创立就完事了。假使你创立一组资源，须要依照其依赖先后调用，并关注外面的状态细节，这样的易用性显然是差了很多的——就像OpenStack，你要创立VM前有一系列的事要先筹备好。 低代码平台也是同样的思路，通关拖拽的形式造成UI相干的代码，甚至能够定义一些简略的逻辑在外面。这样造成的代码天然不必Review，要做优化也是低代码平台里的代码解释器来做。 以这种形式来思考业务价值，其实是十分不言而喻的：让一个一般的开发去写一段SQL可能只有10分钟，而用代码写一个对应的数据处理工作可能要半小时起。 4. 写好代码并非一无是处这么说起来，谋求齐全洁净整洁的代码对于业务来说仿佛没有那么重要。从业务角度来说，是这样的。但总有一些外围的代码、常常被大家应用库、框架须要洁净整洁的代码与API设计，它们往往位于我的项目的底层，但却默默的撑持着在下面倒退的业务。这就须要CleanCode，哪怕少传一个参数，少一行代码，普惠的则是所有的使用者——这种价值往往体现在降低成本上。 5. 小结本文探讨了笔者在coding品质上走过的路，针对CodeReview分析了引入工夫以及重点关注项。并指出了更容易被量化价值的申明式编程是一个不错的抉择。 针对绝大多数的业务代码，需依据期间来衡量CodeReview的水平。下面承载的业务就像咱们进来打猎时的武器一样，商业战场就像一个丛林。如果咱们无奈用武器打到猎物——获取商业上的胜利，那么咱们迟早被饿死。至多得在咱们不被饿死的状况下，再思考武器的棘手水平，甚至那天情绪好还能够雕个花在下面，让它像个艺术品一样。 谋求代码的极致并非是无用的。那些外围库，框架就须要这些技巧，因为把它们写好的同时，就曾经能给下层的业务带来更多的价值了。