前言:

付清技术债务的方法, 大家应该都不陌生:

  • 将多个函数、方法中可共享 (重复) 的代码, 抽象形成新的函数、方法。
  • 参数化所抽象提取出的共享的函数、方法。

这样付清了多个函数、方法中重复代码的技术债务, 但却也引入了其他严重的问题:

  • 当多个函数、方法分别是处理不同、差异颇大的业务逻辑时,  从这些函数、方法中所抽象产生的共享的函数、方法, 将会陷入复杂的业务逻辑判断的地狱当中。
  • 当多个函数、方法是属于测试代码时, 把这些函数、方法中可共享 (重复) 的代码, 抽象形成新的函数、方法, 将会使得这些函数、方法丧失测试代码原本应具备的沟通、理解需求的作用。

所以, 是否应消除  “重复代码” ? 一直是个没有定论、没有标准答案的争议。

我们回归到付清技术债务的目的上重新的来思考:

  • 付清技术债务只有一个目的: 提升产品开发的效率、质量。

也就是说, 付清技术债务是为了提升产品开发的效率、质量; 消除  “重复代码” 只是付清技术债务时, 会运用到的一个方法、手段、选项, 而不是唯一的指标、目的。

所以, 我们真正该去思考的问题应该是:

  • 不消除重复代码, 却能提升产品开发效率、质量的方法是什么?

本文:

开发人员当面对需求变更或需新增特性时, (非正式的统计) 往往会花费 70% – 90%  的开发时间, 去理解所需要变更的多个函数、方法。

所以, 当我们在探讨付清技术债务以提升产品开发效率、质量的方法时, 我们真正应该去解决的一个核心的问题是:

  • 如何使得开发人员能快速、高效的理解所需变更的多个函数、方法? 也就是说, “缩短” 开发人员理解、查找所需变更的多个函数、方法的时间, 将能比 “消除重复代码” 更能提升产品开发的效率、质量。

如何使得开发人员能快速、高效的理解、查找所需变更的多个函数、方法?

格式塔心理学 (Gestalt psychology) 中的相近原则 (Proximity principle) 为我们提供了思路、方法。

格式塔心理学 (Gestalt psychology) 中的相近原则 (Proximity principle)  指的是:

人类的认知系统会将距离相近的各部分趋于组成整体。也就是说, 人类往往会将距离相近的多个、不同的个体, 视为单一的整体。请参考图一, 图二。

图一: 距离相近, 单一的整体?
图二: 有距离上的隔阂, 三个个体?

人类的认知系统会将距离相近的各部分趋于组成整体; 这是个十分关键的点, 关于开发人员去理解所要变更的多个函数、方法。

也就是说, 当我们能从开发人员提交代码行为的背后, 分析出那些函数、方法在开发人员提交代码时, 是都会同时发生变更的, 然后, 我们就将这些函数、方法都给 “搬” 到一块, 那开发人员的认知系统便会将这些函数、方法视为 “单一的整体”, 而使得开发人员能快速、高效的理解这些函数、方法, “缩短” 开发人员理解、查找所需变更的多个函数、方法的时间, 进而提升产品开发的效率、质量。

图三: String_StartsWith_MethodCall() 与 String_EndsWith_MethodCall() 在开发人员提交代码时, 都同时会发生变更根据相近原则 (Proximity principle) , 就将String_StartsWith_MethodCall() 与String_EndsWith_MethodCall() 给 “搬” 到一块

CODESCENE 是目前唯一支撑相近原则 (Proximity principle) 的工具。

如图四, CODESCENE 告诉我们:

函数 suspend_scheduler 与 stack_element_dump 在开发人员提交代码时, 都同时的会发生变更, 但在suspend_scheduler 与 stack_element_dump 之间却隔著 “81” 个其他的函数!

所以, 假如, 不将 suspend_scheduler 与 stack_element_dump 给 “搬” 到一块, 开发人员的认知系统在理解 suspend_scheduler 与 stack_element_dump 上, 毫无疑问的, 将会是件没效率且又容易犯错的事。

图四: suspend_scheduler 与 stack_element_dump 之间隔著 “81” 个其他的函数

结论:

运用相近原则 (Proximity principle) 付清技术债务的方法, 无疑的是一个相当容易且风险最低的作法。尤其, 是在交付时程很紧凑的项目中, 使用相近原则 (Proximity principle), 可使我们能避免陷入复杂的业务逻辑判断的地狱中。同时, 也能使得开发的效率、质量获得提升。更重要的是, 相近原则 (Proximity principle) 使得日后需再重构时, 也变得更容易、更高效。

相关阅读:

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

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

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

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

发表评论

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

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