0
0
前言:
软件开发有个很重要、很基本的一件事:
- 随著时间的推移、版本的演进, 如何确认软件的架构仍能支撑需求上的变更? 新特性的开发?
在过往我们只是知道产品模块、文件间的依赖; 如图一所示。但这样的模块、文件间依赖的信息, 至多只是告诉了我们:
某些产品的模块、文件间的依赖是违背或符合了软件架构设计的原则。
我们只是知道了产品的架构是违背或符合了软件架构设计的原则, 是不足以让我们能确认, 随著时间的推移、版本的演进, 软件的架构仍能支撑需求上的变更、新特性的开发。
因为, 我们发现, 我们要能确认, 随著时间的推移、版本的演进, 产品软件的架构仍能支撑需求上的变更、新特性的开发, 我们就必需掌握下面的关键信息:
- 开发人员提交代码行为的背后, 会同时发生变更的模快、文件。
只有去分析开发人员在提交代码时, 会同时变更到哪些的模快、文件, 我们才能清楚且明确的掌握到, 随著时间的推移、版本的演进, 产品软件的架构是如何的发生变化的? 我们也才能确认, 随著时间的推移、版本的演进, 产品软件的架构仍能支撑需求上的变更、新特性的开发。
提交代码到github:
CODESCENE 能帮助我们分析出:
- 开发人员提交代码行为的背后, 会同时变更到哪些的模快、文件。
如图二所示, 开发人员在提交代码行为的背后, 会使得在 9 个不同模块的 Startup.cs 都同时会发生变更。
随著时间的推移、版本的演进, 9 个不同模块的 Startup.cs 都会同时的发生变更; 这个在开发人员提交代码行为的背后, 所隐藏著的故事, 是否会造成产品软件的架构仍能支撑需求上的变更、新特性的开发?
如图三所示, 开发人员在提交代码行为的背后, 会使得测试代码 TextAreaTagHelperTest.cs, FormTagHelperTest.cs 同时的发生变更。但, 测试代码 TextAreaTagHelperTest.cs, FormTagHelperTest.cs 并没有任何需在架构上发生依赖的原因。
为何测试代码 TextAreaTagHelperTest.cs, FormTagHelperTest.cs, 两个在架构上不需发生依赖的文件, 却在开发人员提交代码行为的背后, 都同时发生了变更? 这个在开发人员提交代码行为的背后, 所隐藏著的故事, 是否代表著:
- 测试代码 TextAreaTagHelperTest.cs, FormTagHelperTest.cs 所对应到的产品代码 (架构), 也已发生了会为了某个单一责任的需求变更、开发, 而需同时变更到多个的产品代码的文件?
- 当产品代码 (架构) 已发生了会为了某个单一责任的需求变更、开发, 而需同时变更到多个产品代码的文件时, 是否会对产品软件的架构能支撑需求上的变更、新特性的开发, 产生负面的影响?
结论:
开发人员提交代码行为的背后, 往往隐藏著会让我们大为惊讶的故事:
- 为何开发人员提交代码行为的背后, 会造成多个模块内的文件同时的发生变更?
- 为何开发人员提交代码行为的背后, 会造成在架构上没有任何依赖关系的多个的文件发生变更?
当我们能随著时间的推移、版本的演进, 掌握开发人员提交代码行为背后的故事时, 我们就能更明确的掌握产品的软件架构, 是如何随著时间的推移、版本的演进而改变的, 我们也就能更清楚的知道:
该如何的做出适当且即时的 “决策”, 使得团队能在最适当的时间点, 整改最值得整改的软件架构上的技术债务。
相关阅读:
产品中的 Hotspots: 基于配置库中代码所隐藏的开发者行为, 高效的提升产品的质量与开发的效率
高效、低成本的付清技术债务; 在 200,000 行代码的模块里, 找到最值得优先关注的 180 行代码
Proximity: 付清技术债务; 不消除重复代码, 却能提升产品开发的效率、质量
别再傻傻的写单元测试了; Hotspots 告诉我们单元测试的真相: 单元测试是负债? 还是资产?
