摘要：在软件研发工作中，功能新增、体验优化、技术改造、问题修复等各类研发活动都是围绕着代码在进行，因此整个过程的质效也必将反映到代码相关数据，代码本身以及其产生的提交记录、审核记录、权限审批记录、研发任务、缺陷数量等都为洞察研发效能提供了重要素材，是分析和发现研发质

在软件研发工作中，功能新增、体验优化、技术改造、问题修复等各类研发活动都是围绕着代码在进行，因此整个过程的质效也必将反映到代码相关数据，代码本身以及其产生的提交记录、审核记录、权限审批记录、研发任务、缺陷数量等都为洞察研发效能提供了重要素材，是分析和发现研发质效瓶颈的重要抓手。

工商银行软件开发中心建设代码洞察平台，通过分析海量的源代码变动数据，同时结合缺陷问题信息、核心程序资产、程序的动静态调用量、方法复杂度等微观度量数据进行综合分析，从面向对象编程的设计原则和研发质效提升的典型场景出发，识别代码变动体现出的潜在问题和风险。通过代码洞察平台，各级管理者可快速掌握代码在各层组织内、不同技术栈间变动规模分布情况以及质量合规问题，有效圈定核心代码，为合理调配研发资源、有效识别代码隐患提供有力支撑。

建设思路

代码变动数据必须与其他各类研发管理过程数据相结合，才能发挥其在质效洞察中的作用。首先汇集研发过程中各类系统和工具的数据，再通过不同的度量指标对数据进行加工分析，发现值得关注的现象、揭示可能存在问题、聚焦潜在风险。代码洞察平台的基本实现思路如下图所示：

另一方面，作为研发过程度量体系的一部分，必须结合研发过程中的关键环节和痛点，形成有效的度量指标体系。数据汇集是基础，度量指标体系是实现从数据到洞察的关键。代码洞察平台的度量指标体系如下：

应用场景

1．部门代码变动情况总览

部门总览页面对代码变动的基本情况进行部门、应用、小组级的汇总和可视化展示。包含部门月度代码变更总行数、涉及提版人数、变更程序、核心程序数、代码变动行数小组/应用分布、程序修改次数排行榜、代码提交关联问题小组/应用分布以及程序提交关联问题号排行榜。

在部门总览页面，用户可找到如下问题的答案：部门每个版本的代码变动量有多少？有多少人提交了代码？改动了多少个程序？包含多少核心程序？这些改动的代码在各组、各应用是如何分布的？哪些程序修改次数最多？

同时，可查看部门代码提交人员的人均变动代码行数，并与中心均值和研发部均值进行对比，光标悬浮可显示中位数等数据以供进一步分析。用户可快速了解当前部门在各技术栈的代码变动规模。系统也会自动识别代码变动量明显偏低、偏高的代码提交人及其对应的代码变动行数，方便管理者及时掌握研发产能明显超高或过低情况，及时实施相应的改进措施。

在程序修改排行榜中，可点击图表显示程序画像，方便用户在关注到某一程序时查看其详细的度量指标。该画像作为全局嵌入功能，在展示程序名称的页面均可被调用。

2．识别程序研发耦合或设计缺陷

程序多人修改：同一期版本内多人修改同一程序，定义为程序多人修改。基于面向对象编程的“单一职责（Single Responsibility Principle,SRP）”的设计原则，一个类应该只负责一件事，引起它变动的原因同一时间应该只有一个。同一版本多人修改一个程序说明可能存在功能或架构上的耦合，应考虑重构。

程序跨部门修改：同一期版本内跨部门修改同一程序，定义为跨部门修改。这可以看作是程序多人修改的一种更复杂的情况，即程序的多个修改人分别属于不同的部门。这种情况下可能出现由于跨部门沟通不充分导致的信息不对称，引起修改点遗漏或合并冲突，带来质量隐患，同样建议对程序进行重构，按照单一职责原则进行拆分。

程序高频修改：在给定时间范围（通常是多个版本）内频繁发版投产的程序，定义为高频修改程序。基于面向对象编程的“开闭原则”：软件实体（如类、模块、函数等）应该对扩展开放、对修改封闭。这意味着软件实体应该允许在不修改现有代码的情况下添加新功能，从而提升程序的可扩展性、可维护性和可复用性。在需求未发生频繁变动的前提下，一个程序如果几乎每期版本都改动，除了质量原因，很可能还存在设计上的不完善，是技术治理应关注的重点。

3．评估研发质量情况

除了正常需求开发相关的研发任务，缺陷修复活动也是导致代码变动的重要来源。良好的研发工程实践中要求代码提交必须关联缺陷编号。在代码变动数据中，对关联的缺陷编号进行统计分析，可以反映出程序质量、人员编码质量和代码审核质量等情况。我们通过三个维度的问题集中度来评估：

程序问题集中度：统计程序变动过程中关联的缺陷编号数量。程序修改关联缺陷编号越多，说明程序质量越差或者是设计存在缺陷，导致编码完成后问题较多，一直在修复问题。这样的程序建议在代码评审和投产前检查时重点关注。

提交人的问题集中度：从提交人维度统计提交代码关联问题号的数量。一个开发人员提交代码关联的缺陷编号越多，说明其开发质量越差。原因可能是多方面的，但对于团队管理者来说是值得关注的现象，需要了解人员情况，研判是否存在人岗匹配度不高或者其他异常情况等。

代码审核人的问题集中度：从代码审核人的维度，统计其审核过的代码在后续的修改中又关联过多少缺陷编号。这在一定程度上反映出代码审核的效果是否到位，即代码审核质量。对于审核后关联问题号较多的程序，其对应的审核人可能未对代码进行充分审核。

问题集中度是从代码提交关联缺陷问题数量的角度，对程序和人员的质量情况进行的分析，呈现值得关注的情况。为部门和团队开展质效提升工作提供有效的数据支撑。方便聚焦重点，有的放矢。

4．识别低效代码

“如何快速定位到项目中疑似不再被使用的Java类和资源？”“我们想做应用瘦身，是否有工具能帮我们缩小分析低效代码工作的范围，提供一些参考数据？”这类问题是团队技术主管可能会遇到的典型场景。如何在众多的程序中发现治理对象，特别是对于大型软件项目来说，是一个难点。代码洞察平台集成了低效代码扫描功能，可以检查项目中不再被调用或低频调用的动态和静态资源，帮助团队快速识别低效代码，高效开展技术治理工作。

Java类扫描：经过分析和学习类加载的方式，发现可以通过获取类加载器中的加载情况，获取所有已加载的类。在比对检查项目中已编译结果，可以获取未被类加载器加载过的类，扫描Java类的使用情况。

上图是实际扫描结果的数据，两个工程中均扫描出了经确认可退出的类，可安排后续版本删除，减少冗余代码。未被加载、但不可退出的类均属于低频交易。应用可在运行一段时间后重新获取数据，进一步分析，并根据交易必要性选择是否保留。由于采用定时任务在夜间异步运行，对节点的性能未产生影响。

资源调用扫描：使用web容器接收的请求，可以使用日志记录下所访问的资源请求路径。通过配置日志路径、资源所在的文件夹、资源类型，检查未被通过web容器访问的静态资源，并输出扫描结果到文件中。

扫描日志中静态资源的访问情况，发现项目中53个的静态资源未出现在日志里；再次分析这些静态资源，发现其中有85%的静态资源不再使用。工具扫描不在生产环境执行，对生产无影响。

未来展望

工商银行软件开发中心会将代码变动数据与程序调用、生产问题、项目计划、人员负荷等更多维度的管理数据进一步整合，在完善代码画像、推荐核心程序、辅助识别项目风险，评估人员产出效能等方面持续发力，通过“效能量化、价值评估、风险聚焦、赋能优化”的四步法，实现数字化研发管理闭环。

来源：银行科技研究社