专栏首页DDDcode review

code review

也不知code review是从哪年开始流行的,我的职场经历从刚开始完全没有到1对1,再到团队式review

一、Review Meeting

优点:

1.团队内新技术/新观点的交流Meeting、项目开发思路、解决方案讨论,偏头脑风暴式;2.各类项目都适合进行;

缺点:

1.依赖于主持者(项目owner)的素质、时间成本高(为会议上所有人时间的总和);2.集体评审的代码行数有限;

二、Single Review

优点:

1.更偏重与具体的代码评审,人员分散参与,评审代码行数有保证;2.时间自由,reviewer什么时候进行评审时间可自控;

缺点:

1.依赖reviewer的技术水平,代码提交合并前强审核,只适用于重要项目或核心模块;

why

为什么需要code review,其实在任何行业,基本都是大厂带给整个行为最佳实践,code review就是其中一种实践

The biggest thing that makes Google’s code so good is simple: Code Review.

At Google, no code, for any product, for any project, gets checked in until it gets a positive review.

code review的好处可以罗列出很多很多,设计、结构、编码方方面面

代码有这几种级别:1)可编译,2)可运行,3)可测试,4)可读,5)可维护,6)可重用。通过自动化测试的代码只能达到第3)级,而通过Code Review的代码少会在第4)级甚至更高

Code Review主要是让你的代码可以更好的组织起来,有更易读,有更高的维护性,同时可以达到知识共享,找到bug只是其中的副产品

以我个人经验看,code review更多是技术及业务知识的分享,甚至可以相互结合,理论分享与code的结合

比如check list与最佳实践结合

how

code review有点类似TDD,但强于TDD,这儿的强于不是说功能性,而在于落地层面,只要大家坐一起,指点江山,就可以完成了,当然效果另说

怎么更好地落地code review呢?或者说code review需要review些什么?code?

每个团队都有各自的情况,所以并不是随便拿一份review check list对照就做好,至少侧重点不同

比如人家团队人员素质普遍高一些,那人家的checklist可能就少了些基础知识点;团队职责不同,checklist也可能会相应不同,基础架构的checklist肯定跟业务线的不一样,各个不同业务线的也不同,需要根据团队情况制定合适的checklist

极端情况,团队中无人能识别好代码,每次都是流水帐式看代码,那团队人员得流动一下了

如何code review,结合why谈谈一些点

不要挑毛病

这就是上面的图中显示的,尤其团队式review,一群坐在下面的人

1.命名不太好啦2.空格太多了3.方法太长了4.编码没格式化啊5.这循环用lambda一行解决问题6.实现的不是产品要的7.这设计有问题啊

对1~4点,这些纯粹是浪费时间,一个团队的时间是宝贵的,来review这些,极大的浪费

因此需要明确两点:

•Code review 不应该承担发现代码错误的职责•Code review 不应该成为保证代码风格和编码标准的手段

【管理工具化、工具流程化】指导方针,这儿可以引入checkstyle工具,让团队统一code sytle,新人加入团队时的培训指南中,并加入到CI中,检查失败直接构建失败

再引入sonar识别常见质量问题和安全问题,这样提高code review的质量

第5点:这也很典型,从code review层面讲,这也不应该是code review的职责,但从知识分享角度讲,这的确是,怎么办呢?使用流还是经典的for循环最好,如果团队成员对同一段代码有不同的意见,那么开发人员应该如何进行修改,结束审阅,并将代码推送到生产中?

解决这个问题最好能有一套最佳实践标准,明确什么情况使用流式,什么情况使用传统方式,其实这很难,真这样搞最佳实践会成为一本谁也学不完的手册,那只能说“这要看情况”,未尝不可,但需要有前提,团队中需要有一名裁决者来决定最终方案,而不能陷入长时间的争论

好比service能不能跨业务调用dao,这也是无对错,需要是的团队的一致性和最初的决策方案,不必每次code review时无休争论

6~7两点,这是最坑的,浪费了开发时间,也对代码作者造成极大打击,为什么到此时才发现,所以需要在开始前就得对功能设计和架构设计进行review,不能只看结果,得看起始与过程

保证正确性

这是code review的前提条件,如上述的6、7两点,不应该出现,一个优秀的工程师需要能够独当一面,能够在系统角度实现局部的良好设计,通过合理的测试方法论验证结果。能够用合理的数据结构、算法实现功能

在技术驱动的团队里,即使需求很紧急,对于关键的功能,核心成员也会耐心地审视架构设计和实现方案,如何控制熵,如何用更合理的方式实现,如何考虑到未来的变化。技术驱动的团队里,应该持续进行对设计的调整和代码的微小重构与改良,时刻在整个系统的设计和表现(performance)角度审视自己的工作。这也是“系统思考”的核心。大部分的代码的熵增大难以控制,并不是因为没有好的架构,而是因为迭代中忽略了系统性的思考和审视,而是用局部的解决方案解决问题,在反复迭代后,复杂度过高导致控制熵变得异常困难。这是code review比较难解决的

分享

从上面所述,code review虽然能发现代码中的一些错误,但不应该是他的核心价值。正好在《DDD总结》[1]中所述,“降低代码复杂度”是所有方法实践论的终极目标。降低复杂度、易于扩展是我们的目标。那么code review也应该是为实现这个目标的手段,因此code review需要去review设计的合理性(如实现方法,数据结构,设计模式,扩展性考虑等),是否存在大量重复代码等

如何达到这些呢?需要发挥团队力量,三个臭皮匠顶过一个诸葛亮,代码终究是需要人去看的,通过与他人的交流,去寻求最佳实践,交流前提就是去分享自我,包括设计思想和实现路径

小到与一个人分享,也就是一对一code reivew,这样让review的开发人员了解代码的设计和实现,即能得到别人的指导,又能传递自我,并且能互为backup,方便后期维护,减少项目风险

大到与团队分享,产生技术氛围,让好的知识、设计在团队中分享,实现整体团队的成长和整体效益最大化

也鉴于要去把代码与人分享,就更容易让大家写出更具可读性的代码,提高可维护性,随便也让别人发现除功能逻辑外的一些技术逻辑:比如数据库连接是否忘记关闭,线程池是否正确使用等等,也加强了checklist的广度和深度

when

什么时候code review,大多数时候都是在上线前才做这件事,但理论最佳时间应该在提测前,以防测试完成后,又要对代码做变动

在实践时,可以拿出专门时间进行,以错开迭代发布的紧张期


除了上述的方法论,team leader还要在如何更好地code review,让团队更有意愿地参与上花心思,让团队成为一个学习型组织,有工程师文化的组织

简而言之,主体思想就是code reivew不应该把精力花在表面的code上,而是要关注设计思路,代码复杂度,工程熵增上,实现高内聚低耦合的大道上

References

[1] 《DDD总结》: http://www.zhuxingsheng.com/blog/ddd-opening-summary.html

本文分享自微信公众号 - 码农戏码(coder-game),作者:朱先生

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-02-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Code Review

    翻译为代码审查,大白话就是在代码提交后,由管理员或几个人对提交的差异内容进行审核,一般包括如下 常规项:

    用户6884826
  • 闲扯code review

    今天早上要开会,所以文章早点放出来。 如果说git终于让工程师在合作撰写代码的过程中找回了丢失已久的乐趣,那么,code review的过程还是让人相当地抓狂。...

    tyrchen
  • Code Review探讨

    我一直认为Code Review(代码审查)是软件开发中的最佳实践之一,可以有效提高整体代码质量,及时发现代码中可能存在的问题。包括像Google、微软这些公司...

    Spark学习技巧
  • Java Code Review 指南

    Java代码俯身指南,主要为Java开发人员提供代码复审参考,快捷有效提出修改意见。

    白凡
  • 什么是Code Review

    Code Review 是一种通过复查代码提高代码质量的过程,在XP方法中占有极为重要的地位,也已经成为软件工程中一个不可缺少的环节。

    阳光岛主
  • Java Code Review清单

    三产
  • MEP | Code Review 建议

    一、目标和原则二、开发者三、评审者四、实用性建议1. 对事不对人2. 每个 Review 至少给一条正面评价3. 使用统一的代码风格规范4. 全员参加 Code...

    双鬼带单
  • 测试驱动Code Review

    交叉领域是容易产生新思想和新技术的地方。软件测试和代码评审(code review)是软件质量保障体系的两大重要组成部分。看似互不相关的它们,如果结合在一起,会...

    muntainyang
  • Google: 如何做code review?

    ? 导语:Google 前几天公开了一篇谷歌的工程实践文档,内容跟 code review 相关,里面包含了 Google 工程师如何进行 code revi...

    腾讯技术工程官方号
  • 怎么做好Code Review?

    想要做好Code Review,必须让参与的工程师充分认识到Code Review的好处

    落落落洛克
  • 前端 Code Review 指北

    ? 作者:magentaqin,腾讯 CSIG 前端开发工程师 说到 Code Review,经常有同学会问,究竟从哪些方面下手?除了一些抽象的 Review...

    腾讯技术工程官方号
  • 你有做 Code Review 吗?

    在代码的编写中有一个很重要的环节,经常会被忽视,那就是 Code Review ,据说在 Facebook、Google 这种互联网大公司,要求每一个提交都必须...

    oec2003
  • Code Review之delete后置空

    大部分同学应该都发现了,单例的destoryInstance函数没有在delete之后将s_pInstance 置空。本次使用没问题,但下次getInstanc...

    用户5521279
  • 【译】感谢你的Code Review

    这意味着我需要发出大量的代码审查。在一次修改中通常会涉及到从UI到数据库的所有部分。

    Jackeyzhe
  • Code Review都有哪些坑

    代码审查是许多高效团队的工程实践。即使你的软件已经有很多优点了,但团队在做代码审查时仍然会遇到一些陷阱。

    Jackeyzhe
  • Git Code Review设置与使用

    自从转到git上之后,已经一年多没有code review了(哈哈,捂住无辜的小脸)。但是坦白来说,code review绝对是利大于弊的。不仅可以让自己把控代...

    腾讯工蜂
  • Google 是如何做 Code Review 的

    Google 的代码审查在工程实践中起着重要作用,并且 Google 早期就已经开始采用。直到今天,代码审查仍用于保证代码库的整洁,一致,并确保没有人随意提交代...

    GitHubDaily
  • 基于GitLab的Code Review教程

    也就是说,使用GitLab进行Code Review就是在分支合并环节发起Merge Request,然后Code Review完成后将代码合并到目标分支。

    KenTalk
  • 活动#4 来互相 Code Review 吧

    Code Review 是一种通过复查代码,提高代码质量的过程。通过 Review 别人的代码,学习别人写的好的地方。别人 Review 自己的代码,别人可以指...

    前端GoGoGo

扫码关注云+社区

领取腾讯云代金券