0
0
前言:
在软件开发中, 我们一直藉由设计冲刺、敏捷开发、软件工程、自动化的测试、部署工具等, 期望能找到从用户想法到产品发布的那条最短的路径; 能高效的发布符合用户期望的产品。
然而, 我们往往却深深的陷入了由 “一大堆的用户需求”、”一大坨的产品代码”、”一大长串的产品缺陷” 所形成的泥沼当中;想快速的交付产品, 却怎么也快不起来 ？!
为何会如此?
为何我们该学的都学了，该懂的都懂了，然而，我们还是需要天天长时间的工作、甚至是没有周末、假日，而最终也只是体现出 “差强人意” 的产品质量、客户满意度 ？！
当然，也有可能是我们没学好，甚至是学错了 ？！
然而，真正的根因到底是什么 ？！
Google 早就看出了这一点（其实就是个 Common Sense）：
- 开发软件的是人；而由人类的行为所产生的代码，最终都将会汇聚到 “配置库” 中。
所以，要知道如何将自身产品的开发效率、产品质量获得提升，便必需要懂得如何对配置库中的代码进行所谓的 “人类行为分析”。
配置库中的人类行为分析的结果，将使得我们能明确、清楚的了解到：
团队是因为什么样的 “根因” 而使得开发的效率、产品的质量每况愈下 ？！团队应该要如何的持续改善 ？这些都是传统的软件度量所做不到的。
2018 年，我们对于软件开发的持续改善，也应该要有个不一样的思维与作法：
“将配置库中的代码当成是海量数据，并对其进行人类行为分析，以试着从中能找出阻碍团队高效、高质量开发的根因，进而定制出能使团队提升开发效率与质量的策略、工程实践与工具。”
在此我们将介绍的是 Adam Thornhill; 文中简称 Adam; 的算法模型。
Hotspot算法:
Adam 的思维主要是来自于犯罪心里学中的地域犯罪心理学。
地域犯罪心理学主要讲的是:
- 罪犯往往都是会在自己所熟悉的地域范围内犯罪。所以, 我们可以藉由分析某个罪犯平日移动的地域范围, 而划定出会发生犯罪率高或低的区域 。
- 下图是分析了凶手的犯罪频率与犯罪地域间的关系; 我们发现凶手虽然会在城市中的各个不同的地域间犯罪, 但凶手在城市中的某个特定地域的犯罪频率却会明显的高于其它地域的犯罪频率; 如图中的红色区域就是凶手犯罪频率最高的地域。
- 凶手在城市中犯罪频率最高的地域, 我们就称作是 “Hotspots”。
毫无疑问的, Hotspots 可帮助警察将有限的警力资源专注在特定的地域上, 而能在最短的时间内将凶手捕获。
Adam 将地域犯罪心理学的方法、思路应用在软件开发上; 他经过十多年研究过数百个中型、大型的产品, 发现地域犯罪心理学的方法确实可应用在软件开发上。
Adam 发现开发人员也是和凶手有著相同的行为模式: (抱歉, 我不是说开发人员是凶手。)
- 凶手会在某个特定的地域重复发生犯罪的频率, 明显的要高于其他的地域。
- 开发人员会在某个特定的文件进行代码变更的频率, 明显的要高于其他的文件。
下图是 Adam 的研究结果:
不管是只有一年的产品、六年的产品, 还是已经是十二年的产品; 也不管产品是使用 C#, VB, Erlang, Ruby on Rails, 都有著相同的行为模式:
- 产品代码的变更都集中在特定的文件中。
产品代码的变更都集中在特定的文件中; 这是一个相当有趣、关键的开发者的行为。
从这个相当有趣、关键的开发者的行为出发, 我们再更进一步的思考著下面的几个问题：
- 产品代码的变更都集中在特定的文件中, 是否就意味著, 我们也可在产品中找到 “Hotspots” ?
- 我们在产品中所找到的 “Hotspots”, 是否就是产品中技术债务、缺陷发生频率最高的文件 ?
- 我们在产品中所找到的 “Hotspots”, 是否可以让我们以最少的人力、最短的时间, 就能有效的提升产品的质量?
- 我们应该从那些个纬度来定义产品中的 “Hotspots” ?
Adam 经过十多年研究过数百个中型、大型的产品, 终于找到了产品中的 “Hotspots” !
Adam 根据产品文件内的代码的行数 (代码复杂度) 映射成是城市中的不同的地域; 代码行数多 (代码复杂度高) 的代表城市中的高楼 (商业区), 代码行数少 (代码复杂度低) 的代表城市中的平房 (住宅区)…等等。
Adam 再根据代码在配置库中的提交的频率, 映射成是开发人员所熟悉的地域范围。所以, 将代码的行数 (代码复杂度) 与代码在配置库中的提交的频率相结合, 就可以分析出产品的 Hotspots; 最容易产生缺陷的文件 (会发生犯罪率高的区域) 。
我们先看看由 Adam 所提供的某个案例的研究; 以了解 Hotspots 与产品缺陷间的关系：
这个案例的背景信息如下：
某个 400,000 行代码的开源项目, 分析出 Hotspots 后… (附注: Hotspots 就是代码复杂度最高并且提交配置库的频率也最高的文件。)
- 团队发现占总代码行数 4% 的 Hotspots, 却产生整个开源项目 72% 的缺陷。
所以, 藉由 Adam 的算法模型：
- 我们可在产品中找到 “Hotspots” !
- 我们在产品中所找到的 “Hotspots”, 就是产品中技术债务、缺陷发生频率最高的文件。
- 我们在产品中所找到的 “Hotspots”, 只占产品总代码行数中极少的部分。
- 我们在产品中所找到的 “Hotspots”, 让我们能以最少的人力、最短的时间, 就能有效的提升产品的质量; 团队只需花费 4% 的 effort (人力、时间), 便可大幅的提升此开源项目的质量。
下图是更多Adam 的算法模型的案例。
结论:
Adam 举了个他的某个客户的例子:
- 这位客户有个已经运行、开发 15 年的系统。
- 这位客户使用了某个可分析出技术债务的工具, 分析了这个 15 年的系统。
- 这个分析技术债务的工具, 给出了一份分析报告：“这个 15 年的系统已经积累了4,000 年的技术债务。”
- 任何一个人是这位客户时, 都只能有一个选择：
- 彻底的放弃这个系统。
- 或是继续的忍受这个系统的技术债务所带来的很难维护、很难扩展的世纪大难题。
因为, 根据这个分析技术债务的工具, 所提供的技术债务的分析报告, 这世上应该是没有任何的一个人, 能够清楚的知道, 该从何处去著手解决这个 15 年系统的技术债务。
所以, 假如我们只是分析出产品 (系统) 中有那些的技术债务, 对提升产品的质量、开发的效率是一点帮助都没有的。
我们要努力的工作, 更要聪明的工作; Adam 的算法模型, 让我们能找到产品中的 Hotspots。而使得我们能以最少的人力、在最短的时间内, 就能解决在产品中会影响产品质量与开发效率的技术债务; 使得我们能在最短的时间内, 重新的又回到高效开发产品的轨道上。
相关阅读:
高效、低成本的付清技术债务; 在 200,000 行代码的模块里, 找到最值得优先关注的 180 行代码
Proximity: 付清技术债务; 不消除重复代码, 却能提升产品开发的效率、质量
别再傻傻的写单元测试了; Hotspots 告诉我们单元测试的真相: 单元测试是负债? 还是资产?
