Code Review:提升代码质量与团队能力的利器

01 引言
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将 Code Review(下文简称CR),即代码审查,是一种通过评审代码以发现并修正错误的实践。它不是一个新概念,但在软件开发中,它的重要性毋庸置疑。首先,它可以显著降低软件中的缺陷比例;其次,它促进了知识共享,通过评审的过程,团队成员可以相互学习,增强对系统的整体理解;最后,CR是一种预防措施,它有助于维护代码的清晰和统一,减轻技术债务,提升系统的稳定性。
尽管CR有诸多好处,实际操作中却面临不少挑战。例如,交付压力可能导致CR被忽视或流于形式;另一方面,缺乏有效技巧和工具支持,可能会使CR变得低效,甚至引发团队内的冲突;此外,一些团队可能会遇到参与度不足的问题,团队成员不愿意投入必要的时间和精力。 在接下来的内容中,我们将探讨如何克服这些挑战,优化流程,并分享一些实战经验,以帮助读者在自己团队中实施有效的CR。 02 Code Review的核心目标和基本原则
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将
引言
Code Review(下文简称CR),即代码审查,是一种通过评审代码以发现并修正错误的实践。它不是一个新概念,但在软件开发中,它的重要性毋庸置疑。首先,它可以显著降低软件中的缺陷比例;其次,它促进了知识共享,通过评审的过程,团队成员可以相互学习,增强对系统的整体理解;最后,CR是一种预防措施,它有助于维护代码的清晰和统一,减轻技术债务,提升系统的稳定性。
Code Review的核心目标和基本原则
2.1 核心目标
2.1.1 提高代码质量
2.1.2 风险管理
2.1.3 促进知识共享
2.2 基本原则
2.2.1 专注于代码质量
2.2.2 保持一致性的标准
2.2.3 保持尊重/建设性沟通
Code Review的实践步骤与技巧
3.1 实践步骤
3.1.1 准备
3.1.2 执行评审
3.1.3 修改及完成
3.2 CR的最佳实践技巧
3.2.1 有一份明确的checklist
设计:主要评审整体设计,例如,API设计简单清晰,代码交互、系统交互恰当,技术组件、中间件使用得当等。 功能性/非功能性:评审代码的行为是否符合预期?大多数时候,仅靠评审并不能发现每一行代码是否如期运行,我们应特别关注一些异常的极端情况,例如,边界处理、异常死循环、非法的输入输出、大报文处理、兼容性问题、线程安全/并发问题、Exception处理等。 性能/稳定性:对于一些高吞吐量的系统,响应性能尤其重要。例如,确保依赖服务SLA符合预期,超时和重试配置得当,避免产生慢SQL、大量锁等待、线程阻塞/耗尽等。 可观测性:是否在上线后可观测代码运行的行为,发生异常时可及时感知?例如,确保方法添加了必要的监控埋点、有正确的日志级别及日志内容。 复杂度:代码实现足够简单吗?是否有过度设计?作为评审者应让代码尽量保持简洁,以便让其他的开发者可以快速理解,降低未来修改时引入新错误的风险。 命名:是否为变量、类、方法等选择了清晰的名称?命名应遵守代码规范,且能够准确表达代码的意图,而又不至于过长难以阅读。 注释:注释清晰无歧义,应解释代码“为什么”,而不是“是什么”。注释更应解释一些代码外的隐含信息,例如,设计的取舍、业务背景、某些看起来很tricky的实现,以及解释正则表达式、特定算法等内容。 测试:是否有适当的单元测试?需要修改已有的单元测试? 风格:是否遵循一致的代码风格?风格无所谓好坏,但保持一致性的风格,会让其他团队成员更容易理解。 文档:是否需要更新相关API说明、Readme等文档?
3.2.2 避免完美主义
3.2.3 拆分为小型MR/PR/Commit
3.2.4 一次不要评审过多的代码
3.2.5 尽早进行小而频繁的评审
3.2.6 保持尊重
3.2.7 度量和改进
设定一些度量指标,并持续追踪趋势,有助于我们持续不断改进CR过程。以下是一些可以用作度量的指标,例如,审查时长、缺陷密度、CR率等。
以下是身边真实发生的一些CR案例,与3.2.1章节中的checklist都有相应的对照,供大家参考。为了便于阅读,部分代码进行了删除简化。
4.1 案例1-异常及并发情况处理不周
问题:静态缓存先clear,再进行加载,如果解析过程异常会导致配置丢失、在高并发访问时读取到错误的配置。
改善:应使用覆盖更新的方式。
public class ReverseSwitch {private static Map<String, Boolean> multiConfigAddress = new HashMap<>();public void setMultiConfigAddress(String multiConfigAddress){ReverseSwitch.multiConfigAddress.clear();// 以下是解析字符串配置映射到Map配置中,省略具体过程for (/*.....*/) {ReverseSwitch.multiConfigAddress.put(/*.....*/);}}public static boolean isMultiConfigSwitch() {// .....}}
public void setMultiConfigAddress(String multiConfigAddress){log.info("ReverseSwitch.setMultiConfigAddress {}", multiConfigAddress);Map<String, Boolean> newAddress = new HashMap<>();// 省略解析过程for () {newAddress.put();}// 使用覆盖更新的方式ReverseSwitch.multiConfigAddress = newAddress;}
4.2 案例2-设计问题、可观测性不足
问题:
1. 本地缓存每小时失效一次,会集中产生大量RPC请求加载数据(容器数量*外部请求数),当依赖的RPC服务抖动时有可能导致雪崩;
2. do while语句在远程数据异常时,可能循环次数超出预期或产生死循环,导致tp99超时、阻塞或OOM;
改善:
1. 使用redis缓存并预加载;
2. while内设置最大分页次数进行break;
3. 上层调用增加监控埋点及日志。
@CacheMethod(key = "vrs.SpareQueryProxyCache.getAllSpareInfo",cacheBean = "localGuavaCacheBean60m",timeout = Constants.REDIS_KEY_TIMEOUT_MINUTES_60)public List<BaseStoreInfoDto> getAllSpareInfo() {int pageNum = 0;PageDto<List<BaseStoreInfoDto>> page;List<BaseStoreInfoDto> returnList = new LinkedList<>();do {page = basicPrimaryWS.getBaseStoreInfoByPage(++pageNum);if (page != null && CollectionUtils.isNotEmpty(page.getData())) {// 省略对page内容进行筛选等逻辑处理代码// ......returnList.addAll(page.getData());}}while (page != null && page.getCurPage() < page.getTotalPage());return returnList;}
4.3 案例3-代码复杂度
public void buildWaybillCodeList(AfterSaleOrderReceiveContext afterSaleOrderContext) {boolean useServiceCode = true;// 条件1if (condition_1) {useServiceCode = false;}// 其他条件if (!canUseServiceCode(afterSaleOrderContext)) {useServiceCode = false;}// 条件2if (condition_2) {useServiceCode = false;}List<String> waybillCodeList = new ArrayList<>();if (useServiceCode) {// 场景1:单号规则waybillCodeList.add(WAYBILLCODE_PREFIX + afterSaleOrderContext.getAfterSaleOrderReceiveDTO().getServiceCode());} else {// 场景2:单号规则waybillCodeList.add(this.preDeliveryId(afterSaleOrderContext));}// ......}private boolean canUseServiceCode(AfterSaleOrderReceiveContext afterSaleOrderContext) {List<ProductDetailDTO> productDetailDTOList = buildMainGiftProductList(afterSaleOrderContext);// 只针对一单一品一个数量的返回truereturn productDetailDTOList.size() == 1 && Objects.equals(productDetailDTOList.get(0).getProductCount(), 1);}
public void buildWaybillCodeList(AfterSaleOrderReceiveContext afterSaleOrderContext) {List<String> waybillCodeList = new ArrayList<>();// 将多次需求变更的逻辑点聚合到职责明确的方法内if (canUseServiceCode(afterSaleOrderContext)) {// 场景1:单号规则waybillCodeList.add(WAYBILLCODE_PREFIX + afterSaleOrderContext.getAfterSaleOrderReceiveDTO().getServiceCode());} else {// 场景2:单号规则waybillCodeList.add(this.preDeliveryId(afterSaleOrderContext));}// ......}private boolean canUseServiceCode(AfterSaleOrderReceiveContext afterSaleOrderContext) {// 条件1if (condition_1) {return false;}// 条件2if (condition_2) {return false;}// 条件3List<ProductDetailDTO> productDetailDTOList = buildMainGiftProductList(afterSaleOrderContext);// 只针对一单一品一个数量的返回truereturn productDetailDTOList.size() == 1 && Objects.equals(productDetailDTOList.get(0).getProductCount(), 1);}
4.4 案例4-增加灰度策略控制
public void setConsigneeAddress(WaybillAddress targetAddress) {// 100%修改至新逻辑:A// ......}
public void setConsigneeAddress(WaybillAddress targetAddress) {// 选取可控的特征属性,例如按流量比例或商家切量if (ThreadLocalRandom.current().nextInt(1000) < ducc.getAddressMontageSwitchRate()) {// 新逻辑:A,使用灰度策略,控制本次改动影响范围// ......} else {// 原逻辑:B// ......}}
4.5 案例5-善用工具
在提交人工CR前,善用工具进行代码扫描,可能有意想不到的收获。
if (response != null&& response.getCode() != 0&& String.valueOf(response.getCode()).length() > 2&& (KK_PARAM_PREFIX_CODE.equals(String.valueOf(response.getCode()).substring(0, 2)))|| KK_BIZ_PREFIX_CODE.equals(String.valueOf(response.getCode()).substring(0, 2))) {throw new BusinessException(StringUtils.isNotBlank(response.getSubMsg()) ? response.getSubMsg() : response.getMsg());}
JD JoyCoder给出的评审意见:“代码中存在一个潜在的逻辑错误,这是由于条件判断中的逻辑运算符&&和||的优先级没有被明确区分。在Java中,&&操作符的优先级高于||,这意味着在没有适当的括号的情况下,&&绑定的条件会先被评估,然后才是||绑定的条件。”
修改后:
if (response != null&& response.getCode() != 0&& String.valueOf(response.getCode()).length() > 2&& ((KK_PARAM_PREFIX_CODE.equals(String.valueOf(response.getCode()).substring(0, 2))|| KK_BIZ_PREFIX_CODE.equals(String.valueOf(response.getCode()).substring(0, 2)))) {throw new BusinessException(StringUtils.isNotBlank(response.getSubMsg()) ? response.getSubMsg() : response.getMsg());}// 此段代码可以进一步优化,将if里面的条件提前抽取到有明确业务语义的变量中,提升可读性
除目前流行的基于LLM实现的AI扫描工具外,使用传统代码扫描也可以发现潜在问题。
以下代码通过静态扫描工具发现问题:直接使用“==”进行包装类型Integer的比较,当遇到[-128, 127]范围外时比较结果会不符合预期。
if (!(request.getSkuList().stream().allMatch(sku -> sku.getPreProduce() != null &&sku.getPreProduce() == request.getSkuList().get(0).getPreProduce()))) {throw new DOSException(ResultEnum.PRE_PRODUCE_UN_SAME.getCode(), ResultEnum.PRE_PRODUCE_UN_SAME.getMessage());}
if (!(request.getSkuList().stream().allMatch(sku -> sku.getPreProduce() != null &&sku.getPreProduce().equals(request.getSkuList().get(0).getPreProduce())))) {throw new DOSException(ResultEnum.PRE_PRODUCE_UN_SAME.getCode(), ResultEnum.PRE_PRODUCE_UN_SAME.getMessage());}
Code Review的成果收益
总结与展望
未来,CR将继续发挥其关键作用,我们期待AI+CR成为一个更加强大和智能的伙伴,使团队将能够保持竞争力,持续提升软件质量和交付速度。
感谢京东物流平台技术部的同事们对本文撰写提供的帮助
▪功能支撑:会员成长体系、等级计算策略、权益体系、营销底层能力支持
▪用户活跃:会员关怀、用户触达、活跃活动、业务线交叉获客、拉新促活