前言:

软件开发有个很重要、很基本的一件事:

  • 随著时间的推移、版本的演进, 如何确认软件的架构仍能支撑需求上的变更? 新特性的开发?

在过往我们只是知道产品模块、文件间的依赖; 如图一所示。但这样的模块、文件间依赖的信息, 至多只是告诉了我们:

某些产品的模块、文件间的依赖是违背或符合了软件架构设计的原则。

图一: 产品模块、文件间的依赖

我们只是知道了产品的架构是违背或符合了软件架构设计的原则, 是不足以让我们能确认, 随著时间的推移、版本的演进, 软件的架构仍能支撑需求上的变更、新特性的开发。

因为, 我们发现, 我们要能确认, 随著时间的推移、版本的演进, 产品软件的架构仍能支撑需求上的变更、新特性的开发, 我们就必需掌握下面的关键信息:

  • 开发人员提交代码行为的背后, 会同时发生变更的模快、文件。

只有去分析开发人员在提交代码时, 会同时变更到哪些的模快、文件, 我们才能清楚且明确的掌握到, 随著时间的推移、版本的演进, 产品软件的架构是如何的发生变化的? 我们也才能确认, 随著时间的推移、版本的演进, 产品软件的架构仍能支撑需求上的变更、新特性的开发。

本文:

CODESCENE 能帮助我们分析出:

  • 开发人员提交代码行为的背后, 会同时变更到哪些的模快、文件。

如图二所示, 开发人员在提交代码行为的背后, 会使得在 9 个不同模块的 Startup.cs 都同时会发生变更。

图二: 开发人员在提交代码行为的背后, 会使得在 9 个不同模块的 Startup.cs 都同时会发生变更

随著时间的推移、版本的演进, 9 个不同模块的 Startup.cs 都会同时的发生变更; 这个在开发人员提交代码行为的背后, 所隐藏著的故事, 是否会造成产品软件的架构仍能支撑需求上的变更、新特性的开发?

如图三所示, 开发人员在提交代码行为的背后, 会使得测试代码 TextAreaTagHelperTest.cs, FormTagHelperTest.cs 同时的发生变更。但, 测试代码 TextAreaTagHelperTest.cs, FormTagHelperTest.cs 并没有任何需在架构上发生依赖的原因。

为何测试代码 TextAreaTagHelperTest.cs, FormTagHelperTest.cs, 两个在架构上不需发生依赖的文件, 却在开发人员提交代码行为的背后, 都同时发生了变更? 这个在开发人员提交代码行为的背后, 所隐藏著的故事, 是否代表著:

  • 测试代码 TextAreaTagHelperTest.cs, FormTagHelperTest.cs 所对应到的产品代码 (架构), 也已发生了会为了某个单一责任的需求变更、开发, 而需同时变更到多个的产品代码的文件?
  • 当产品代码 (架构) 已发生了会为了某个单一责任的需求变更、开发, 而需同时变更到多个产品代码的文件时, 是否会对产品软件的架构能支撑需求上的变更、新特性的开发, 产生负面的影响?
图三: 开发人员提交代码行为的背后, 使得测试代码 TextAreaTagHelperTest.cs, FormTagHelperTest.cs 同时的发生变更

结论:

开发人员提交代码行为的背后, 往往隐藏著会让我们大为惊讶的故事:

  • 为何开发人员提交代码行为的背后, 会造成多个模块内的文件同时的发生变更?
  • 为何开发人员提交代码行为的背后, 会造成在架构上没有任何依赖关系的多个的文件发生变更?

当我们能随著时间的推移、版本的演进, 掌握开发人员提交代码行为背后的故事时, 我们就能更明确的掌握产品的软件架构, 是如何随著时间的推移、版本的演进而改变的, 我们也就能更清楚的知道:

该如何的做出适当且即时的 “决策”, 使得团队能在最适当的时间点, 整改最值得整改的软件架构上的技术债务。

相关阅读:

产品中的 Hotspots: 基于配置库中代码所隐藏的开发者行为, 高效的提升产品的质量与开发的效率

高效、低成本的付清技术债务; 在 200,000 行代码的模块里, 找到最值得优先关注的 180 行代码 

Proximity: 付清技术债务; 不消除重复代码, 却能提升产品开发的效率、质量 

别再傻傻的写单元测试了; Hotspots 告诉我们单元测试的真相: 单元测试是负债? 还是资产?

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据