Page 200 - 《软件学报》2024年第6期
P. 200

2776                                                       软件学报  2024  年第  35  卷第  6  期


                 enterprise-specific  dataset  that  includes  a  total  of  17  000  CRCs  from  34  commercial  projects.  The  results  indicate  that  the  proposed
                 approach  can  effectively  evaluate  the  quality  attributes  and  grades  of  CRCs.  The  study  also  provides  some  modeling  experiences  such  as
                 CRC labeling and verification, so as to help software organizations struggling with code reviews better implement the proposed approach.
                 Key words:  software  quality  assurance;  code  review;  code  review  comment  (CRC);  quality  evaluation;  multi-label  learning;  empirical
                         software engineering

                                                                                                       [1]
                    代码评审    (code reviews) 起源于  20 世纪  70 年代  Fagan 在美国  IBM  公司提出的“代码审查  (code inspections)” ,
                 其旨在通过人工检查源代码来减少软件开发错误和缺陷. 在随后的数年中, 代码评审作为一种典型的质量保证措
                 施被世界范围内各大软件组织逐渐推广和使用, 成为现代软件开发的最基本的流程之一                             [2,3] . 除了保证代码质量以
                 外, 代码评审还有利于提升开发者编程能力、协作能力和质量意识                      [4,5] , 帮助减少静态扫描工具的漏报和误报         [6,7]
                 等. 由于这些特性, 代码评审目前已被应用于各类开源软件项目和商业软件项目                         [8−10] , 成为被广泛认可的软件工程
                 “最佳实践”之一    [11] .
                    另一方面, 代码评审的负作用日益凸显. 代码评审有时候不能发现缺陷, 变成软件工程中一种典型的浪费                                 [12] .
                 更糟糕的是, 低效的代码评审容易延缓项目进度               [13] . 不友好和不公平的代码评审容易引发团队负面情绪和信任危
                 的评审意见质量评价方法相比, 本文提出的方法仅需关注评审意见文本, 无需依赖代码变更状态, 能够实现“实时
                 机, 极端情况下甚至导致员工离职, 进而对团队和项目都产生负面影响                      [14−18] . 相较于其他质量保证活动     (如测试
                 等), 代码评审缺少系统化理论指导和智能工具支持. 相反地, 代码评审长期以来, 通常由经验性的“最佳实践”指
                 导  [19] , 即代码评审更多依赖代码作者和评审者的技能、经验、参与和投入程度等.
                    近年来, 越来越多的研究开始评价和提升代码评审               [4,10,18,20] . 其中的大多数都提及“代码评审意见”(后文简称“评审
                 意见”), 并将其视为代码评审的最主要和最重要的产出之一. 评审意见, 即评审者针对开发者提交的代码变更给予的反
                 馈, 是其他评审者和开发者发现代码缺陷的重要提示                [21] , 同时也是开发者修复缺陷、提升质量的重要参考. 尽管代码
                 评审意见的重要意义获得了学术界和工业界的普通认可, 但目前仍缺少针对其质量的有效的评价方式和方法.
                    极少数的相关工作       [10,20,22] 将是否“触发代码变更”作为评价评审意见有用性的标准. 然而, 该方式属于“离线评
                 价”, 即必须依赖于评审后的代码变更状态. 本文认为仅将是否“触发代码变更”作为评价标准, 一方面受人的主观
                 因素影响较大, 难以被评审者广泛接受; 另一方面, 评价并非最终目的, 更重要的是规范评审意见内容, 辅助提升评
                 审质量和代码质量. 因此, 评价需要具备可解释性和指导性. 例如, (1) 如果因为在评审意见中“包含代码元素”可以
                 帮助开发者定位和修复缺陷, 而将其作为评价标准, 那么评审者可能会有意识地复制粘贴代码元素到评审意见中,
                 而不论其是否必要; (2) 如果因为在评审意见中指出严重程度高的缺陷                     (“指出严重缺陷”) 可以降低后期修复成本,
                 而将其作为评价标准, 那么评审者可能会遗漏其他缺陷; (3) 如果因为在评审意见中“表示赞赏”可以提升代码作者
                 的积极性, 而将其作为评价标准, 那么无疑将背离评审的初衷                  (代码质量保证) 和加重评审者的负担. 另一方面, 现
                 有研究  [10,20,22] 大都基于评审意见文本、评审上下文和评审者相关特征来构建预测模型. 此时这些特征                        (样本特征)
                 也可被视为“评价标准”. 即使模型能够实现相当准确的预测效果, 其在应用时也会遭受质疑. 例如, 很难说服评审
                 者其意见质量低是因为意见中未触发代码变更或未包含代码元素等.
                    针对上述问题, 本文开展了文献综述、案例分析等若干实证研究来识别和总结代码评审意见的质量评价标
                 准  (属性), 并在此基础上提出了一种基于多标签学习              (multi-label learning) [23] 的评价方法. 该方法基于多标签学习
                 范式和预训练语言模型的文本分类模型              (自动化模型), 以及启发式的映射规则          (人工经验) 建立起了评审意见质量
                 属性  (“情绪”“疑问”“评价”和“建议”) 和质量等级         (“优秀”“良好”“一般”和“较差”) 的关联, 属于混合式方法. 与已有


                 评价”. 此外, 本文提出的方法属于“多元& 多级评价”. 其中, “多元”指考虑了多个质量属性, “多级”指设置了多个质
                 量等级, 从而有利于提升评价方法的可解释性和指导性, 降低实际应用该方法时面临争议的可能性. 在某全球领先
                 的软件企业的     34  个商业项目, 共计    17 000  条代码评审意见上的实验验证表明, 本文提出的方法在多个量化评价
                 指标上表现出色, 能够有效地评价代码评审意见的质量.
                    本文的主要贡献如下.
                    (1) 区别于现有相关工作根据是否“触发代码变更”来评价代码评审意见有用性                         (有/无), 本文使用了多个质量
   195   196   197   198   199   200   201   202   203   204   205