卓越工程之如何做好Code Review

这篇具有很好参考价值的文章主要介绍了卓越工程之如何做好Code Review。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

卓越工程之如何做好Code Review

本文主要从我们为什么需要CR?CR面临哪些挑战?CR的最佳实践几个方面分析,希望可以给读者一些参考。

 

为什么需要CR?

代码质量

定性来看,大家都认可Code Review(后文简称CR)能显著改善代码质量,但国内量化的研究结果比较少,以下引用业界比较知名的几个定量研究结果:
Capers Jones分析了超过12,000个软件开发项目,其中使用正式代码审查的项目,潜在缺陷发现率约在60-65%之间;大部分的测试,潜在缺陷发现率仅在30%左右。
Steve McConnel在《Code Complete》中提到:仅仅依靠软件测试效能有限–单测平均缺陷发现率只有25%,功能测试35%,集成测试45%,相反,设计和代码审查可以达到55%到60%。
SmartBear研究了一个历时3月,包括10名开发人员完成的10,000行代码的工程,通过引入CR在接下来的6个月中可以节省近6成的bug修复成本
卓越工程之如何做好Code Review卓越工程之如何做好Code Review

 

技术交流

SmartBear研究报告中这段话比较能表达CR对技术交流的价值,引用如下:
Actually writing the source code, however, is a solitary activity. Since developers tend to create code in quiet places, collaboration is limited to occasional whiteboard drawings and a few shared interfaces. No one catches the obvious bugs; no one is making sure the documentation matches the code. Peer code review puts the collaborative element back into this phase of the software development process.
Google认为CR参与塑造了公司的工程师文化,CR也与笔者所在部门一贯倡导的「极致透明」的文化相契合,资深同学的CR,对团队内新人的快速成长也很有帮助。

 

卓越工程

Linux的创始人Linus Torvalds有句名言:Talk is cheap, Show me the code,代码是程序员的作品,CR只是一种提升代码质量的工具,敢于Show出自己的代码,并用开放的心态去优化完善,才是每个程序员审视自我,从优秀到卓越的关键所在。
既然CR好处这么多,大多团队也在实践,但为什么效果差强人意呢,主要是CR在大型项目实践中面临诸多挑战。

 

CR面临哪些挑战?

挑战1:CR的代码改动范围过大

笔者观察,很多项目落实CR的最大挑战是项目进度压力很大,发布计划倒排根本没有给CR预留时间,所以大部分CR是在临近提测前(甚至有些是边测试边进行)集中进行,面对动辄上千行的代码变动,评审者需要花大量时间和代码提交者交流了解业务逻辑,迫于时间压力大多只会检查最基本的编码规范问题,而没有达到CR预期的效果。SmartBear公司对 CR 节奏的研究指出:每次大于400行的CR每千行代码缺陷发现率几乎为零。
卓越工程之如何做好Code Review 卓越工程之如何做好Code Review
那么怎样的提交粒度比较合适呢?笔者的经验是和单元测试case匹配(这里问题来了,没时间写单元测试怎么办,本文姊妹篇再来聊聊单元测试),完成一个功能,跑一个单元测试验证逻辑,然后commit一次。如下图,Aone(阿里内部的研发平台)提供的功能内置支持按照提交版本分批DIFF,分批Review。
卓越工程之如何做好Code Review

挑战2:CR对评审者全局知识要求很高

CR一般由团队内资深的技术同学进行,对于大型复杂项目的CR需要评审者对编码规范、分布式架构设计原则、业务知识有全面的了解,举个例子,下面是某服务提供的等级查询接口关键代码CR片段:

- public Level queryLevel(LevelQueryRequest request) {
+ public Level queryLevelWithExpireRefresh(LevelQueryRequest request) {

    Level result = levelRepository.findLevelWithoutInit(request.getId());
    if (null == result || isExpired(result.getEndTime())) {
        // 如果等级为空,兜底返回L0;等级已过期,实时返回默认等级,并异步刷新
        if (result == null) {
            result = levelRepository.buildInitLevel(request.getId(), LevelEnum.L0);
        }

        //查询为空,或者已过期发送消息,刷新等级
-       LevelRefreshRequest refreshRequest = buildRefreshRequest(request);
-       levelWriteService.refreshLevel(message.getId(), refreshRequest);
        
+       RefreshMessage refreshMessage = buildRefreshMessage(request);
+       refreshMessageProducer.sendMessage(refreshMessage);
    }

    return result;
}
- public class RefreshMessageListener extends AbstractMessageListener {
+ public class RefreshMessageListener extends AbstractOrderlyMessageListener {

    @Autowired
-    private LevelWriteService levelWriteService; 
+    private LevelWriteRegionalService levelWriteRegionalService;

    @Override
    protected boolean process(String tags, String msgId, String receivedMsg) {
        RefreshMessage message = JSON.parseObject(receivedMsg, RefreshMessage.class);
        if (message == null || message.getId() == null) {
            log.warn("message is invalid, ignored, src={}", receivedMsg);
            return true;
        }

        LevelRefreshRequest refreshRequest = buildRefreshRequest(message);
-       levelWriteService.refreshLevel(message.getId(), refreshRequest);
+       levelWriteRegionalService.refreshLevel(message.getId(), refreshRequest);

        return true;
    }
}
 
面对上面代码改动,要进行富有成效的CR,下面是代码评审者必须掌握的业务和技术知识:
  • 为什么存在等级为空的情况?

  • 为什么要设计成读时写?

  • 为什么不是直接计算等级,而需要用消息队列?

  • 为什么要用Regional(区域化)接口和有序消息刷新等级?

 

挑战3:CR价值最大化需要团队具备卓越工程基因

前文提到CR有助于团队内的技术交流,下面是几个笔者亲历的Case,通过对典型CR问题的广泛讨论不仅提升了业务代码的质量,而且探索到了技术创新点,逐步建立起团队追求技术卓越的氛围:

CASE1:一个业务使用3个时间穿越开关

背景
时间穿越是营销类业务系统最常使用的工具之一,通过全局控制,可以提前测试某个在未来开始的业务功能。笔者接触到的一个业务由2个服务A、B组成,A是一个老应用,使用了一个开关,后来B又在不同业务场景中使用了2个新的开关,在一次CR中发现了一个业务重复使用3个不同开关的问题,由此展开了一次讨论。
private static final String CODE = "BENEFIT_TIME_THROUGH";

public Date driftedNow(String userId) {
    try {
        TimeMockResult<Long> result = timeThroughService.getFutureTime(CODE, userId);
        if (result.isSuccess()) {
            return new Date(result.getData());
        }
    } catch (Throwable t) {
        log.error("timeThroughService error. userId={}", userId, t);
    }
    return new Date();
}
观点1:彻底服务化
按照DRY(Don't Repeat Yourself)原则,最理想的方案是把该业务用到的时间穿越开关统一由一个服务提供,因为时间穿越工具是借助动态配置中心推送开关到本地,然后做内存计算;如果统一成服务后,A和B都需要依赖远程服务调用,而B是一个高并发的使用场景,会有较大性能损耗。
观点2:富客户端
把统一开关包装成一个三方库,独立提供jar包供A、B服务分别依赖,这样解决了前面方案的性能消耗问题。但两个应用需要同步做更新和升级。
观点3:配置统一,重复代码三处收拢为两处
该观点认为彻底服务化和富客户端属于两种极端,可以采取折中方案容忍部分代码重复,但使用相同的时间穿越开关。
总结:
这个Case的讨论涉及到一个公共逻辑抽取的方案权衡问题,进程内调用的富客户端性能损耗低,但后期维护和升级困难,而且过于复杂的客户端逻辑容易引发依赖方包冲突、启动耗时增加等问题;彻底服务化只需要保持接口契约一致可以实现较快迭代,但对服务提供者SLA要求高;为了平衡前两者的问题,微服务架构中的SideCar模式则是在功能性的应用容器旁部署另一个非功能性容器,使得开发团队可以对主应用和SideCar进行独立管理。关于这个问题网上有很多讨论内容读者可以进一步了解学习。

CASE2:SSR(服务端渲染)API稳定性优化

背景
卓越工程之如何做好Code Review
上图是一个典型的服务端渲染服务架构,SSR服务通过加载配置,对每个模块进行独立数据组装,并整体返回结果到端侧。一般应用在电商系统复杂只读页面的动态搭建,如首页、商品详情页、导购频道等。下面是组装数据部分的待评审代码片段。

// 提交任务
ioTaskList.stream().forEach(t -> futures.add(pool.submit(() -> t.service.invoke())));

// 阻塞获取任务结果
futures.stream().forEach(f -> {
    try {
        result.add(f.get());
    } catch (Exception e) {
        log.error(e.getMessage(), e);
    }
});
Step1:增加固定超时控制
// 提交任务
ioTaskList.stream().forEach(t -> futures.add(pool.submit(() -> t.service.invoke())));

// 阻塞获取任务结果
futures.stream().forEach(f -> {
    try {
-       result.add(f.get());
+       result.add(f.get(1000, TimeUnit.MICROSECONDS));
    } catch (Exception e) {
        log.error(e.getMessage(), e);
    }
});
Step2:自适应超时控制
public abstract class BaseService<T> implements Service {

    @Override
    public T invoke(ServiceContext context) {
        Entry entry = null;
        try {
            // 根据service类别构造降级资源
            String resourceName = "RESOURCE_" + name();
            entry = SphU.entry(resourceName);
            try {
                // 未触发降级,正常调用后端服务
                return realInvoke(context);
            } catch (Exception e) {
                // 业务异常,记录错误日志,返回出错信息
                return failureResult(context);
            }
        } catch (BlockException e) {
            // 被降级,可以fail fast或返回兜底数据
            return degradeResult(context);
        } finally {
            entry.exit();
        }
    }

    public abstract T realInvoke();
}
Step3:自适应超时控制+自定义资源key
public abstract class BaseService<T> implements Service {

    @Override
    public T invoke(ServiceContext context) {
        Entry entry = null;
        try {
            // 这里的key由service实现,融合了服务类型和自定义key构造降级资源
            String resourceName = "RESOURCE_" + key(context);
            entry = SphU.entry(resourceName);
            try {
                // 未触发降级,正常调用后端服务
                return realInvoke(context);
            } catch (Exception e) {
                // 业务异常,记录错误日志,返回出错信息
                return failureResult(context);
            }
        } catch (BlockException e) {
            // 被降级,可以fail fast或返回兜底数据
            return degradeResult(context);
        } finally {
            entry.exit();
        }
    }
    

    public abstract String key(ServiceContext context);

    public abstract T realInvoke();
}
 
总结:
Step1很容易理解,增加1000ms超时设置可以避免某个数据源严重超时导致整个渲染API不稳定,做到fail fast,但核心挑战在于多长的超时时间算合理;Step2通过依赖降级组件,根据不同数据源服务设置不同超时时间,实现了自适应超时控制;Step3相比Step2改动非常小,不了解业务背景可能不清楚它们的区别,Step2的降级控制作用在服务类别上,比如营销服务、推荐服务各自触发降级,但还有一类数据源服务其实是网关类型,内部耗时会根据某个或某些参数不同有较大差异,例如TPP(阿里内部的算法平台,不同算法逻辑共享一个网关API,但不同算法复杂度耗时差异巨大)服务就是一个典型,所以Step3允许自定义key()实现更精细的超时控制。
卓越工程之如何做好Code Review
团队由CR引发的技术深入讨论和持续优化形成了这套自动化降级能力,上图是实际线上运行效果,可以看到系统随着依赖数据源服务RT的抖动实现了自动化自适应降级和恢复。

CR有没有最佳实践?

Code Review的边界

 

卓越工程之如何做好Code Review
对于什么是一个好代码,上图从可靠、可维护和功能完备做了划分。笔者认为CR并非包治百病的银弹,它也有它的能力边界。把设计方案交给设计评审,把业务逻辑验证交给单测;把编码规范交给静态代码扫描(Static Code Analysis),剩下部分再由Peer Review做最后一道把关。CR引发的技术传承、技术交流以及由此形成的追求卓越的团队文化,才是它的最大价值。
卓越工程之如何做好Code Review

出发点:程序员的初心

 

归根结底,程序员的好奇心和匠心才是提升代码质量的根本,目前笔者所在部门已经在晋升考核中增加了CR环节,烂代码会被一票否决,这就需要日常工作中不断追求技术卓越,在平时多下功夫。

看不见的手:自动代码扫描

 

之前在某社区看到有个热帖讨论程序员的工作是不是劳动密集型,某个回帖比较形象「我们的工作本应是CPU密集型,结果却成了IO密集型」。基本的编码规范完全可以借助代码自动化扫描识别,而这个占比也是比较高,可以有效降低CR成本。业界的CheckStyle、FindBug都有完善的CI/CD插件支持,阿里云也提供了IDE智能编码插件,内置了编码规范支持。

看得见的手:Team Leader的重视

 

喊口号没有用,只有躬身入局。身边几位参加晋升同学CR的评审官普遍感受是:代码质量分布通常会团队化,不要指望个别优秀的同学带动团队的整体水平提升。确实如此,代码质量需要Team Leader高频参与CR,技术文化的形成需要主管以身作则。

参考:

  1. https://en.wikipedia.org/wiki/Code_review
  2. https://smartbear.com/learn/code-review/agile-code-review-process/
  3. Lessons From Google: How Code Reviews Build Company Culture
  4. 阿里巴巴Java编码规约:https://github.com/alibaba/p3c
  5. 五种Code Review反模式:https://blogs.oracle.com/javamagazine/post/five-code-review-antipatterns
  6. Capers Jones对软件质量的研究分享:http://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf
  7. Modern Code Review: A Case Study at Google:https://sback.it/publications/icse2018seip.pdf
  8. 智能编码插件:https://developer.aliyun.com/tool/cosy

 

作者| 三觉文章来源地址https://www.toymoban.com/news/detail-608824.html

到了这里,关于卓越工程之如何做好Code Review的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 还在为618电商推送方案烦恼?我们帮你做好了!

    618是每年重要的电商大促活动,热度高流量大,是电商App吸引新用户,提高用户转化率(购买率)的最好时机。对电商App运营来说,消息推送是不可忽略的流量来源之一,适当的消息推送可以召回用户,提高用户复购率。如何利用消息推送功能在618电商节帮助App获取流量并提高

    2024年02月08日
    浏览(41)
  • AI工程师在崛起,我们如何做到快速转型

    W...Y的主页 😊  代码仓库分享💕 前言:针对目前AI快速发展,越来越多的程序员遭到裁员的风险,AI终将取代程序员的事情好像可以板上钉钉,程序员的行业已经开始走向下坡路,我们的内心不免有一些慌乱,但是AI程序员却在悄悄崛起,并且在不断的推进,我们应该怎么办

    2024年02月05日
    浏览(44)
  • 【软件工程】自动化测试保证卓越软件工程能力(3)

    对照目标系统,如下:  给出自动化测试平台目标如下: Case level Case brief Report send to OVERALL User 1 - Process - Customer 1 Boss Level 1 User 1 - Process - Customer 1 User 1 - Process - Customer  2 User  2  - Process - Customer 1 ... Manager, Some users, Developers, Testers Level 2 User 1 - Igeress - Process - Router - Sender 1

    2024年02月04日
    浏览(57)
  • 前端代码审查(Code Review)---具体实践规范会持续更新(新增Vite基础组件全局注册方式)

    针对目录结构、SCSS规范、JS规范、Vue规范 可参照官方给出的风格指南(Code Review) 1、POST/PUT/DELETE 请求按钮需要添加 loading 状态,防止重复提交。 建议使用 Element UI 提供的button 组件的loading属性,或者自己封装一个 loading 状态的按钮组件。 2、模板上超过两个的判断条件,写

    2024年04月17日
    浏览(83)
  • Code Review、InLineChat、RAG能力全部独家提供,这波上新CodeGeeX平替Github Copilot稳了!

    智谱 AI 2024年度的技术开放日上,CodeGeeX重磅发布第三代模型。针对CodeGeeX插件产品的系列新功能,也同时上线发布,提供给用户免费使用。 一、第三代模型性能全面提升 CodeGeeX第三代模型正式发布,基础能力全面提升。 针对Python、Java、JavaScript、C++、Golang五种主流编程语言,

    2024年01月18日
    浏览(41)
  • AI 大语言模型的提示词工程 Prompt ,以及我们如何使用 Prompt 改善 AI 的思考能力

    1、Prompt 的发展 Prompt 是为了改善 AI 输出质量的一些 关键引导词 Prompt 是有一定的门槛的 但是后面马上 GPT 自己生成 Prompt 就被验证是可行的,且生成的 Prompt 符合人们的预期 为了减少创建和验证有效指令的人工工作量,来自多伦多大学、滑铁卢大学等机构的研究者提出了一种

    2024年02月10日
    浏览(41)
  • 云图说|云数据库GaussDB如何做到卓越性能

    摘要: 对于数据库来说,性能一直被视为最关键的部分。GaussDB作为华为自主创新研发的分布式关系型数据库,那么华为云数据库GaussDB在提升数据库性能方面都有哪些黑科技呢? 本文分享自华为云社区《【云图说】第275期 云数据库GaussDB如何做到卓越性能》,作者:阅识风云

    2023年04月12日
    浏览(31)
  • 【提升FPGA面试技能:40GE、XGE、GE接口详解】——FPGA工程师和网络工程师在实现高速接口时需要了解这些常用的网络接口,本文将深入讲解这些接口的特性和...

    【提升FPGA面试技能:40GE、XGE、GE接口详解】——FPGA工程师和网络工程师在实现高速接口时需要了解这些常用的网络接口,本文将深入讲解这些接口的特性和实现方法。 在网络领域中,传输速率是一个重要的指标,因此在选择网络接口时,需要根据不同的需求选择不同的接口

    2024年01月24日
    浏览(61)
  • 如何做好SEO优化

    SEO优化是指通过对网站的结构、内容、代码、链接等方面进行合理的调整和优化,使网站更符合搜索引擎的排名规则,从而提高网站在搜索引擎中的排名,增加网站的流量和转化率。SEO优化可以分为两大类:站内优化和站外优化。 站内优化是指对网站本身进行优化,主要包括

    2024年02月13日
    浏览(86)
  • 前端如何做好性能优化?

    1、谈谈你对重构的理解。 网站重构是指在不改变外部行为的前提下,简化结构、添加可读性,且在网站前端保持一致的行为。也就是说,在不改变UI的情况下,对网站进行优化,在扩展的同时保持一致的UI。 对于传统的网站来说,重构通常包括以下方面。 把表格( table)布

    2024年02月11日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包