技术债务的那些事

技术债务最早是由Ward Cunningham提出的,当时是为了向非技术背景的项目干系人解释为什么要去做我们现在称之为“重构”的事情。Steve McConnell对技术债务的解释是:技术债务是短期的一种权宜,但从长期看相同的工作会比当前会费的成本要高很多。Jean-Louis Letouzey对技术债务的解释是:对不适合做法的补救成本的总和

关于技术债务,我们要重点讨论的是:

1)     技术债务的种类

2)     如何发现技术债务是否引发重大问题?

3)     处理技术债务的常用方法

4)     什么时候技术债务可以先暂缓处理?

 

技术债务的种类:

根据 Philippe Kruchten等人在 IEEE上面发表的文章,认为技术债务主要包括:

其中,

技术鸿沟( Gap)是指最初的技术决定可能在当时是正确的,但是随着时间、市场、技术等不断改进,这个技术决定已经出现了很多的问题。

Martin Fowler提到了 22种代码异味,代码重复是很常见的一种。

 

如何发现技术债务是否引发重大问题?

Jean-Louis Letouzey认为,代码类型的技术债务,有一个量化的数据来考量债务程度: Bug反馈系数。 Bug反馈系数是修改 10个 bug,新注入(或者是衍生)出多少个 Bug?如果这个系数过大,则是个非常危险的信号。

BrainLink分享了 7个技术债务引起重大问题的危险信号:

1)     系统加载的时间越来越长

2)     某个模块缺陷率不断增加

3)     相同的问题在不同的模块或者组件中出现

4)     新的功能数量增加,引发新的 bug数量持续增加

5)     修复 bug的时间越来越长

6)     团队对某个模块或者组件抱怨很难理解或者很难测试

7)     某个模块的源代码频繁被修改, check- in

 

处理技术债务的常用方法:

第一步:发现项目中包含哪些技术债务

第二步:把技术债务加到产品列表( Product Backlog)中

第三步:根据债务造成的影响和修改债务的成本做优先级排序,这里是和业务需求一起整体排序

第四步:在不同的迭代中分阶段修改。

这里我们的几个具体实践是:

a)         我们会在技术债务的影响和快速交付的要求之间做平衡

b)       尽 量把最核心的技术债务在本次迭代完成,常用的是把技术债务作为技术需求对待,但我们也遇到过这样的情况:团队基于业务需求交付压力的考量,把技术债务在迭 代中消除基本是不现实的。在当前快速交付的前提下,很多团队会出现大量的技术债务。对于后者,我们的做法是:每三个迭代,休整一周(这一周的工作就是集中 消除关键的技术债务和学习债务)。

c)       技术鸿沟和架构债务,越晚修复成本越高,所以我们一般会增强团队中架构师的角色(无论是招聘还是短期合同工),同时增强架构和技术选择的评审,这些都会在迭代 0中进行,我们认为这些都是值得的。同时,我们在最初的几个迭代,独立的测试团队会集中测试架构是否可工作。

d)       代码复杂性、编码风格混乱等都是属于静态代码质量的问题,这些可以通过工具来解决,而不需要太多的人工评审。常用的静态代码检查工具有: Stylecop、 Fxcope、 Gendarme用于 C#开发; Checkstyle、 Findbugs、 PMD用于 Java开发

e)         每隔两天,会有一个 coding show的会议, 20~30分钟,每一个成员展示最核心的一段代码,快速评审,评审的重点是和规范不符的,编写质量较差的内容,然后及时修改。及时修正和全员共识是我们保证代码的手段之一。

 

什么时候技术债务可以先暂缓处理?

1)     上市时间的要求很急。我们要考量修改债务的成本和没有上市造成的损失。例如修改债务需要 1, 000元的成本,没有上市造成的损失是 100, 000元,还不包括客户潜在的转换成本,那就先不考量消除债务吧

2)     产品预算的限制。我们可以把债务后期的偿还费用,一直延迟到产品发布得到下一期产品投资为止。

3)     产品的生命周期很短。一些产品的生命周期很短,无论是对市场的认识不足,还是产品本身就是试探性产品。产品结束了,所有与之相关的债务也就消失了。很多时候,等看到产品的价值后再去偿还债务也是务实的。

### 技术债务的定义 技术债务是一个比喻性的术语,用于描述在软件开发过程中因采取某些权宜之计而导致的质量问题或潜在风险。最初由 Ward Cunningham 在 1992 年提出,他将技术债务类比为财务上的借贷行为[^2]。具体而言,当开发者为了加速功能交付而选择了次优的设计方案或者忽略了代码优化时,就可能积累了技术债务。 更进一步地说,技术债务不仅限于低质量的代码实现,还包括不合理的架构设计、未更新的技术栈以及对第三方库的过度依赖等问题[^3]。这种“欠债”虽然能够在短期内帮助团队更快地完成目标,但从长期来看却可能导致高昂的成本支出和效率下降。 --- ### 技术债务的影响 #### 1. **维护成本增加** 随着时间推移和技术债务累积,修复错误、改进性能或是扩展新特性所需的工作量会显著增长。这是因为原有的缺陷使得系统的可读性和可修改性变差,从而增加了后续工作的难度[^1]。 #### 2. **开发速度减缓** 由于存在大量遗留问题,每次新增改动都需要花费更多时间去理解现有逻辑并规避已知陷阱。这直接影响到了整个项目进度安排,并使原本简单的任务变得复杂耗时。 #### 3. **产品质量受损** 持续积累下来未经处理的技术债务最终会影响产品的整体品质——无论是用户体验还是内部稳定性都会受到不同程度损害。例如频繁崩溃的应用程序或者是响应缓慢的服务接口都可能是背后隐藏着巨大数量级技术负债的结果之一。 #### 4. **员工士气低下** 面对日益复杂的代码基底以及不断堆积起来的新旧问题,工程师们往往会产生挫败感甚至抗拒心理;与此同时管理层也可能因为无法按时达成预期成果而施加压力给到研发部门成员身上,进而形成恶性循环局面。 ```python def calculate_technical_debt_impact(debt_level, project_size): """ A simplified function to demonstrate the impact of technical debt. Args: debt_level (float): The level of accumulated technical debt between 0 and 1. project_size (int): Size of the software project measured by lines of code or features. Returns: float: Estimated additional effort required due to technical debt. """ base_effort = project_size * 0.5 # Base development cost without any debt extra_cost_factor = debt_level ** 2 # Non-linear increase based on debt severity return base_effort + (base_effort * extra_cost_factor) # Example usage additional_effort = calculate_technical_debt_impact(0.7, 1000) print(f"Additional Effort Due To Technical Debt: {additional_effort:.2f} units.") ``` 此函数展示了如何通过量化方式评估不同水平下的技术债务对于总体工作负担所带来的额外增量效果。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值