39、企业数字软件生产力的评估与分析

企业数字软件生产力的评估与分析

1. 重构率与软件生产力评估指标

在软件开发中，重构率是一个重要的指标。它指的是代码中完全替换旧代码并改变代码库本身的更改率。重构率可能暗示团队在初次理解用户需求时效率低下，或者用户对所需产品缺乏了解，从而需要进行整个代码的替换。

管理者通常会结合自身直觉和这些传统软件指标来进行产品管理，检查团队进度和员工绩效。然而，管理者的直觉和对传统软件指标的跟踪可能存在自我诱导的偏差。这些指标既可以有效地促进良好的企业文化和客户满意度，也可能在用于促进裙带关系或偏袒员工时产生负面影响。因此，当务之急是通过对传统指标进行数据挖掘来自动化识别生产力的过程，并为管理层提供辅助工具，使他们能够结合使用此类工具和选定的本能业务指标，以高效地交付产品。

随着版本控制系统和云计算的发展，许多开发者使用机器人和其他手段来避免编写代码，这给衡量程序员的有效工作量带来了巨大挑战。因此，管理者必须奖励真正的人工编码努力，提高团队的士气，以实现快速交付。

2. 软件生产力测量中的数据挖掘

2.1 数据收集

为了衡量程序员完成任务的生产力，我们可以利用他们使用的版本控制系统。版本控制系统为每个唯一的提交分配了 ID，并包含提交时间和描述等详细信息。我们收集了程序中的注释数据、代码总行数，并编写了一个单独的程序来计算同一模块内的传统软件指标。这样，我们将这些程序创建为一个单一的模块组件。这种数据收集方式有助于识别更适合生产的代码，并将问题转化为简单的二元分类。

2.2 数据理解

我们抓取了超过一百万个提交记录，并对其进行处理，以获得用于衡量代码生产力的多个软件指标。现代版本控制系统难以区分人工编写的代码和机器人生成的代码。因此，我们抓取不同的提交记录，以获得具有以下参数的数据集：
1. Transaction ID ：分配给每个提交的唯一主键。
2. API_Code ：为每个提交生成的唯一键。
3. Commit_ID ：由多个提交组成的非唯一参数。
4. commit_date ：提交日期。
5. submit_time ：提交时间。
6. Commit_Status ：指示提交的状态。
7. count_loc_added ：提交中添加的代码行数。
8. count_loc_removed ：提交中删除的代码行数。
9. count_loc_total ：提交中的代码总行数。
10. count_com_change ：提交前后注释数量的变化。
11. change_filesize ：文件大小的总变化。
12. count_filesize_total ：文件的总大小。
13. count_cyclo_change ：圈复杂度的变化。
14. count_cyclo_total ：总圈复杂度。
15. count_dac_change ：DAC 的变化。
16. count_dac_total ：总 DAC。
17. count_halstead_change ：Halstead 复杂度的变化。
18. count_halstead_total ：总 Halstead 复杂度。
19. count_fanout_change ：扇出复杂度的变化。
20. count_fanout_total ：总扇出复杂度。
21. count_nom_change ：方法数量的变化。
22. count_nom_total ：提交中方法的总数。
23. filetype ：文件的扩展名和性质。
24. Employee_ID ：分配给用户的 ID。
25. target ：用于指示工作是由人类完成（表示更高的生产力，值为 False）还是由机器人完成（表示较低的生产力，值为 True）的标签。

2.3 相关特征洞察

2.3.1 圈复杂度

我们通过开发代码的控制图并计算线性独立路径的数量来判断代码复杂度。通过分析程序的复杂度，可以区分人类编写的代码和机器人编写的代码。因为人类编写的代码通常更复杂，具有更多的嵌套语句和大量定义的类/方法，这为区分人类和机器人编写的代码提供了明显的区别。

2.3.2 Halstead 复杂度度量

Halstead 指标可以直接从源代码中使用的运算符和操作数的数量计算得出。一些指标包括 Halstead 程序长度、Halstead 词汇量、程序体积、程序难度和编程工作量。

2.3.3 扇出复杂度

扇出复杂度可以解释为一个类与另一个类的关联。此外，扇出复杂度直接取决于功能程序所需的维护量。因此，这个特征对于确定目标变量可能更具影响力。

2.3.4 方法数量

该指标包含源代码中使用的方法数量。如果方法数量相对于代码行数较少，则可能是人类编写的代码；如果方法数量较多，则可能是机器人编写的代码。然而，我们也可以假设人类会以结构化的方式编写代码，使用大量方法，这就涉及到类不平衡的问题，在模型中我们使用 MICE 方法来解决这个问题。

2.3.5 代码行数

计算代码行数是判断软件系统规模最古老、最广泛使用的软件指标。然而，已经有讨论表明这种方法并不适合衡量生产力。我们在模型中考虑了这个参数，但只有当它与其他相关因素（如注释数量）结合使用时，才能显示出较好的结果，否则效果不佳。

2.3.6 注释数量

该指标用于指示源代码中的注释数量。相对于代码行数，注释数量越多，代码越有可能是由机器人编写的。另一方面，人类通常会相对于代码行数编写较少的注释，使代码更具可读性和最优性。

以下是数据理解过程的流程图：

graph TD;
    A[抓取提交记录] --> B[处理数据获取指标];
    B --> C[区分人类与机器人代码];
    C --> D[确定相关特征参数];

2.4 探索性数据分析（EDA）

数据本质上存在很大的不平衡性。观察人类编写的代码和机器人生成的代码的频率，我们可以发现它们之间存在很大差异。因此，为了建立一个通用的模型，我们需要首先解决目标变量的不平衡问题。

数据中还存在大量缺失值。由于从不同存储库的版本化提交中手动抓取数据，初始数据集是原始的，包含大量缺失值。我们尝试了多种技术来处理缺失值：
- 删除缺失值 ：这种方法效率低下，并且在后续处理中容易出现基于数组形状的错误。
- 用均值或中位数替换 ：由于缺失值的规模较大，这种方法会导致数据集对用于插补的均值或中位数产生偏差。
- 使用 k - 最近邻（kNN） ：这种方法存在多数实例预测的问题，会导致数据集中出现另一种偏差。
- 使用链式方程多重插补（MICE） ：这种方法被证明在处理缺失数据时表现更好，不会引入太多偏差。它通过多次插补而不是单次插补来填充缺失值，增加了获得更好结果的概率。它假设数据集中的缺失值是随机的，从而增加了替换它们的方差，并确保公平处理所有缺失值，保证在整个原始数据中处理缺失值的一致性，以提供预处理后的数据。

最初，我们绘制了热力图来可视化不同特征之间的相关性。通过分析相关性图，我们确定了对目标变量贡献较高的最相关特征。数据似乎存在类不平衡问题，机器人生成的代码数量远低于人工编码的数量，因此在进一步处理之前需要对数据进行平衡。

为了克服类不平衡问题，我们探索了使用合成少数过采样技术（SMOTE）。SMOTE 通过对少数类进行过采样来平衡数据。这可以通过在拟合模型之前简单地复制训练数据集中少数类的示例来实现。这种方法可以平衡类分布，但不会为模型提供额外的信息。应用 SMOTE 后，我们获得了一个平衡的样本，其中来自目标变量两个值的实例数量相等。

相关性用皮尔逊相关系数以数值表示。例如，“cyclo”（圈复杂度）与“nom”（方法数量）特征的相关性为 0.94，“halstead_total”与“nom”的相关性为 0.92，“halstead_total”与“cyclo”的相关性为 0.96。DAC 与扇出复杂度的相关性为 0.82，这表明类之间存在耦合关系。注释数量和代码行数之间的相关性也很高，因此我们可以通过取这两个特征的平均值来中和其影响，并在数据中创建一个新的强特征。同样，方法数量与圈复杂度高度相关，这是预期的模式，因为圈复杂度表示程序执行流程的变化，每当调用一个方法时，程序的流程就会立即改变。我们还注意到，Halstead 复杂度也与方法数量高度相关，这是一种不寻常的模式，但表明方法中使用了不同的运算符和操作数。扇出复杂度也与方法数量高度相关，因为它是衡量不同类之间关联的指标，而不同的方法通常属于不同的类。

2.5 特征缩放

数据中的特征不能直接进行比较，需要进行标准化处理，将它们转换为可比较的特征。特征可以进行 Z - 分数归一化，将其重新缩放到均值为零、标准差为 1 的标准正态分布。另一种方法是进行最小 - 最大归一化，将数据重新缩放到 0 到 1 之间，使两个不同的特征具有可比性。由于数据集规模巨大，我们需要从其中提取有意义的特征样本，因此我们在标准化数据上进一步使用主成分分析（PCA），以获得对输出分类更有贡献的强特征。

2.6 模型选择

分类任务的目标是从数据集中识别出人工编码的努力。我们尝试了多种可用的分类模型，包括逻辑回归、梯度提升分类器、岭分类器、支持向量分类器、高斯朴素贝叶斯和多层感知器分类器。

分类器	平均测试准确率（%）
逻辑回归	80.73
梯度提升分类器	97.98
岭分类器	84.77
支持向量分类器	84.71
高斯朴素贝叶斯	82.03
多层感知器分类器	85.77

我们发现梯度提升分类器的平均测试准确率最高，达到 97.98%。这是因为梯度提升结合了各种弱学习器，基于概率近似正确（PAC）学习和假设提升的概念形成强学习器，它保留所有正确分类的观察结果，并从决策树中修剪掉其他结果，从而处理简化特征向量集中存在的任何额外相关性。逻辑回归无法构建合适的决策边界来分离类，因此平均测试准确率最低，为 80.73%。岭分类器通过使用正则化来防止模型过拟合，实现了最佳性能。多层感知器由于有效使用了神经网络，也表现出了最佳性能，但无法自动处理相关性，因此性能相对梯度提升分类器较低。

通过随机版本控制提交收集的自定义数据经过 MICE 方法处理缺失值，该方法随机插补连续两级数据，并通过被动插补保持插补之间的一致性。这种方法在处理收集的数据时效果良好，比用均值或中位数替换缺失值或直接删除缺失值更好。为了处理类不平衡问题，我们使用 SMOTE 对少数类进行过采样，生成了类平衡的数据。应用 SMOTE 后，数据得到了结构化处理，随后对一些特征进行了标准化，使其具有可比性。对数据进行预处理后，我们对高维数据进行了 PCA 处理，强调了数据集中的变化并揭示了强模式。通过 PCA 实现了降维后，我们对各种分类模型进行了比较分析。在所有模型中，梯度提升分类器在分类实际人工编码努力方面表现最佳，平均测试准确率为 97.98%。

以下是不同分类器模型的分类报告：

梯度提升分类器分类报告

	精确率	召回率	F1 - 分数	支持度
False	1.00	1.00	1.00	503753
True	1.00	1.00	1.00	355634
准确率	1.00	859357
宏平均	1.00	1.00	1.00	859357
加权平均	1.00	1.00	1.00	859357

岭分类器分类报告

	精确率	召回率	F1 - 分数	支持度
False	0.92	0.94	0.93	494398
True	0.91	0.89	0.90	364959
准确率	0.92	859357
宏平均	0.91	0.91	0.91	859357
加权平均	0.91	0.92	0.91	859357

逻辑回归分类报告

	精确率	召回率	F1 - 分数	支持度
False	0.79	0.90	0.84	438154
True	0.88	0.74	0.81	421403
准确率	0.83	859357
宏平均	0.83	0.82	0.82	859357
加权平均	0.83	0.82	0.82	859357

高斯朴素贝叶斯分类报告

	精确率	召回率	F1 - 分数	支持度
False	0.95	0.84	0.89	572411
True	0.74	0.92	0.82	286946
准确率	0.87	859357
宏平均	0.85	0.88	0.86	859357
加权平均	0.88	0.87	0.87	859357

多层感知器分类器分类报告

	精确率	召回率	F1 - 分数	支持度
False	0.89	0.88	0.86	638154
True	0.88	0.87	0.86	521403
准确率	0.85	859357
宏平均	0.86	0.87	0.87	859357
加权平均	0.87	0.86	0.86	859357

综上所述，软件开发是新时代最具活力的行业之一，其不断发展的性质使其既富有生产力又具有挑战性。随着软件行业客户需求的变化和更好的优化，将最终引入新的参数和指标来衡量程序员的生产力。然而，面向对象指标的本质将始终是计算机科学的核心。

3. 软件开发生产力的动态性与未来趋势

3.1 软件开发行业的特性

软件开发行业具有高度的动态性，其不断发展的特性使得它成为一个既富有生产力又充满挑战的行业。随着技术的不断进步和客户需求的变化，软件生产力也呈现出过渡性的特点。版本控制系统的出现，让开发者之间的协作变得更加容易，同时也方便了对项目进度的监控。

3.2 未来参数与指标的引入

随着软件行业的持续发展，客户需求的不断变化以及软件优化的不断推进，未来必然会引入新的参数和指标来衡量程序员的生产力。这些新的指标可能会更加全面地反映软件开发的各个方面，如代码的可维护性、可扩展性、安全性等。然而，无论未来如何发展，面向对象指标的本质将始终是计算机科学的核心，因为它们能够有效地衡量代码的质量和结构。

3.3 对软件开发的启示

对于软件开发团队和管理者来说，需要密切关注行业的发展趋势，及时引入新的指标和方法来评估程序员的生产力。同时，要注重培养团队成员的技术能力和创新能力，以适应不断变化的市场需求。在实际工作中，可以采取以下措施：
- 持续学习 ：鼓励团队成员不断学习新的技术和方法，提高自身的技术水平。
- 优化流程 ：不断优化软件开发流程，提高开发效率和质量。
- 激励机制 ：建立合理的激励机制，奖励真正的人工编码努力，提高团队的士气和积极性。

4. 总结与建议

4.1 总结

在评估企业数字软件生产力时，重构率是一个重要的指标，它可以反映团队对用户需求的理解程度和代码的质量。通过数据挖掘的方法，我们可以收集和分析软件开发过程中的各种数据，包括代码行数、注释数量、复杂度等，以评估程序员的生产力。在数据处理过程中，需要解决数据不平衡和缺失值的问题，同时进行特征缩放和降维处理。通过比较不同的分类模型，我们发现梯度提升分类器在识别实际人工编码努力方面表现最佳。

4.2 建议

• 数据驱动决策 ：管理者应该依靠数据来评估团队的进度和员工的绩效，减少主观偏见的影响。通过建立科学的数据指标体系，及时发现问题并采取相应的措施。
• 技术应用 ：积极应用新的技术和工具，如自动化测试、持续集成等，提高软件开发的效率和质量。同时，要关注行业的最新动态，及时引入新的技术和方法。
• 团队建设 ：注重团队建设，培养团队成员之间的协作精神和创新能力。通过组织培训和交流活动，提高团队的整体素质。

以下是软件开发生产力评估的整体流程图：

graph LR;
    A[数据收集] --> B[数据理解];
    B --> C[探索性数据分析];
    C --> D[特征缩放];
    D --> E[模型选择];
    E --> F[评估与决策];

4.3 展望

随着技术的不断发展和软件行业的不断进步，未来软件生产力的评估方法和指标将会更加完善和科学。同时，人工智能和机器学习等技术的应用也将为软件生产力的评估带来新的机遇和挑战。我们期待未来能够开发出更加智能、高效的评估系统，为软件开发行业的发展提供有力的支持。

总之，企业数字软件生产力的评估是一个复杂而重要的问题，需要综合考虑多个因素。通过科学的数据挖掘和分析方法，结合合理的管理决策，我们可以提高软件开发的效率和质量，推动软件行业的健康发展。