写点什么

欠下“技术债”,谁负责?

  • 2020-12-12
  • 本文字数:2691 字

    阅读完需:约 9 分钟

欠下“技术债”,谁负责?

什么是技术债?


技术债是指在当前以某种方式做某件事的好处,以换取在将来某个时候以另外的方式做这件事的成本


这非常容易理解。你现在做某件事,它的成本比较小,但是将来你就不得不更改它,那时它的成本比较大,因为当你计算完成它所需的真正工作量时,你不得不将所有你已经做的工作一起加进来。


假设你正在领导一个团队创建一个内容管理系统。现在让我们聚焦于系统的某一个方面,如这个内容管理系统需要能够展示内容。根据你所属组织的类型,你将通过头脑风暴来讨论你想要以各种形式展示的内容的分类。


也许你们是一个大型组织,拥有营销团队或用户体验调研员,要捕捉关于用户想要什么相关的数据。也许你们是一个比较小的团队,没有那些资源,但是正与屈指可数的几个客户沟通,以便直接根据他们的具体需求定制你们的软件。或者,你是一个单独的开发者,正在从事一个业余项目或者做兼职。无论如何,你都将在某个时候到达那种状态,规范在手且准备开工。


因此,现在开始开发这些内容组件,当它向后端请求要展示的内容后在前端进行渲染。


假设你已经确定了两类用户想要展示的内容——博客帖子和图片帖子。博客帖子是长文本条目,而图片帖子是一些短条目,带有一张图片和图片下方的一两句描述性的文本。


你是否应该将它们创建为各自独特类型的组件?你可以简单地创建一个“blogPost”对象和一个“imagePost”对象,各自具有一些属性。这看起来很简单来发布到产品——博客帖子有一个段落数组来渲染,而图片帖子有一个图片字段和一个紧随其后渲染的段落字段。或者你应该创建一个“masterPost”对象,用一个“type”字段来决定如何渲染它?或者你可以根据对象中存在的字段来动态生成一个“masterPost”对象,然后在渲染内容时以某种方式对其进行解构?


目前来看,创建两种不同类型的对象,blogPost 和 imagePost,是最简单的。在你完成调研之后,利益相关者的规范是非常清楚的。如果你使用更通用的 masterPost 方法来存储内容,那么你必须测试各种额外的情况,没有实际的立马可见的好处。我们必须尽快将这个产品推向市场——它需要为下个季度的营销计划做好准备,该计划会在两个月内生效。因此,这显然是一个开和关的情况。让我们将这些票放入队列并进行分配,我们将在下一个工作阶段完成!


然而,一两个月后,你的利益相关者现在要求你开发一个“recipe post”、一个“tutorial post”、一个“life event post”等等...


不管怎样,你应该明白了。需求已经变更。你需要增加这些新发现的功能。虽然你之前花了一点儿时间来制作各自类型的对象,但似乎创建“masterPost”对象更适合一些。你可以用一种比现在更动态的方式来渲染它们。这个方案的工作量有一点儿多,但它现在更适合。而且,其最大好处之一就是你的设计能经得起未来的考验,当新类型的内容被要求时,你只需要为新的字段添加新的渲染方法就可以了。


最初,你花了两周来构建你单独的帖子类别。它只投入生产一个月左右,但已经有足够多的用户生成了足够多的数据,现在你必须将这些数据转换成新的 masterPost 格式。(你难道不想让这些数据保持原样,为特定时期的数据构建独特的渲染实例吗!你敢不敢!)当然,你还需要构建 masterPost 相关功能。转换用户数据必须等到这些功能就绪并经过了测试。如果你一开始就考虑点儿未来的话,这本来应该只花费一个月时间,但现在将额外花费两个月时间。这甚至会超过新的营销活动的开始时间,使得营销团队不得不将他们的活动再延后一个月。总共,你目前在整个项目的这个部分已经花费了三个月时间,而一开始的一点儿远见会将这个时间减少大约三分之二!


谁来负责?


这真的是技术债吗?需求变化是技术债吗?谁应该为这类“失败”负责?


(提示:这并不是真正的失败。这只是一个做生意的组织的本性。这都是事后诸葛亮。)


当然,这是一个很有争议的话题。在这个决策过程中,似乎有许多力量导致你们没有更好地利用开发资源。你可能在一直修复已知的错误!


无论这个设计缺陷的真正原因是什么,请放心,所有相关方都会指责其他人。用户调研团队没有问对问题;开发团队没有充分讨论产品设计的可预见性;市场营销团队的计划安排对产品团队的工作优先级有太多影响;谁能预测到用户需求的变化呢;CTO 打太多高尔夫球了,没有管理好这些团队和相关个人之间的协作等。


好吧,别再指责别人了!技术债不是任何特定人群的责任。你们整个组织都对此负责。这是因为人类天性中的低效率和缺点,它们在组织框架内相互起作用,因此导致了债务。


组织内不同团队的专家之间的实际的有意义的沟通和信任,是战胜技术债的关键。虽然每个公司都是独特的,但它们都有一个共同点,不论他们做得怎么样——组织内部的人员对彼此的项目和实际需求更坦诚。每一项业务都有独特的需求和需要解决的特殊问题,从而改变讨论的性质。


在上面的例子中,我认为开发团队应该尝试尽可能强烈地据理力争,他们需要一点儿额外的时间来引入一个更健壮的系统设计,以便在将来有更大的灵活性。变更用户需求是产品开发过程中一个众所周知且反复出现的主题,这应该是预料之中的。


许多比我聪明的人都尝试过解决这个问题。Martin Fowler 影响了我很多关于技术债的想法。几年前,他写了一篇关于“技术债务象限”的博客文章


Martin 将技术债描述为落入下图所示图中四个象限之一。具体可参阅上面的博客,来获得相当言简意赅的解释。



我发现“谨慎的(prudent)”一栏改为“不可避免的(inevitable)”可能更好理解。


这个图中显示,你对技术债的出现几乎无能为力。如果这是一个谨慎且深思熟虑的结果,那可能是当时限制条件下的最佳选择,所以这不可避免。如果这是一个谨慎但不经意的决定,那么在当时参与的人中,没有人能在那时看到适当的解决方案,因此,这也是不可避免的。


开发团队对此并不理解。熟悉技术债概念的开发人员——特别是如果他们有像上图那样将问题可视化的话——应该成为讨论这种组织性的设计债务的倡导者。这是考虑产品设计和开发权衡的一种很好的方法,组织的每个部分都能从中受益,甚至如果一个组织中有更多成员考虑这些权衡,我们可能最终能够让技术债可控。这些权衡往往是在一个组织内的团队彼此协商他们的需求时做出的。也许我们将来需要偿还的“不可避免的”技术债会少很多


结束语


在技术债出现之前,相互讨论技术债以及应该如何处理它。与非开发人员讨论重写代码是一种代价非常大的资源浪费——不仅仅是由于技术人员的实际工资,还有由于工作被一次次重建而停滞的业务方面的机会成本。


技术债确实存在,原因多种多样,而且它不会因为对其忽视就很快消失。对技术债的忽视,是这么多“无意的(inadvertent)”技术债存在的首要原因。


原文链接


Does Technical Debt Exist?


2020-12-12 08:003620

评论

发布
暂无评论
发现更多内容

Portraiture2023最新版本下载安装图文教程

茶色酒

Portraiture Portraiture4

建议收藏,轻松搞懂区块链!

蔡农曰

比特币 区块链 后端 比特币区块链

产品团队业务思维的重要性

Bruce Talk

敏捷 Agile

责任链和策略设计模式-基于Java编程语言

京东科技开发者

Java spring 代码规范 京东云 京东技术

拆分电商系统为微服务

Geek_7d539e

架构实战营10期-作业7

炮仗

2023-02-19:请用go语言调用ffmepg,输出视频文件信息。

福大大架构师每日一题

golang ffmpeg 福大大

会声会影2023官方正式版本功能介绍

茶色酒

会声会影2023

中文技术文档的写作规范参考

小 he

React源码解读之React Fiber

flyzz177

LeetCode:240. 搜索二维矩阵 II,直接查找,详细注释

Lee Chen

JavaScript 算法 LeetCode

信源分类及数学模型

timerring

信息 信息论 信息论与编码

统一观测丨使用 Prometheus 监控云原生网关,我们该关注哪些指标?

阿里巴巴云原生

阿里云 云原生 Prometheus 云原生网关

架构误区系列13:令人迷惑的继承

agnostic

继承

React源码分析1-jsx转换及React.createElement

goClient1992

React

React Context源码是怎么实现的呢

flyzz177

React

CnosDB成为首个产品支持SQLancer的云原生时序数据库

CnosDB

时序数据库 开源社区 CnosDB 工程师有话说

在线头脑风暴软件Mural及其竞品分析

hongfei

思维导图 工具软件 头脑风暴

云计算未来 5 年发展方向大盘点

亚马逊云科技 (Amazon Web Services)

人工智能

用javascript分类刷leetcode17.栈(图文视频讲解)

js2030code

JavaScript LeetCode

对比开源丨Prometheus 服务多场景存储压测全解析

阿里巴巴云原生

阿里云 开源 云原生 Prometheus

面试官:限流算法有哪些?

王磊

java面试

React源码分析(二)渲染机制

goClient1992

React

JavaScript刷LeetCode心得

js2030code

JavaScript LeetCode

前端工程师leetcode算法面试必备-简单的二叉树

js2030code

JavaScript LeetCode

FL Studio最新发布21中文正式版本下载

茶色酒

FL Studio 21

React源码分析(三):useState,useReducer

goClient1992

React

ReactDOM.render在react源码中执行之后发生了什么?

flyzz177

React

应对ChatGPT,中国AI需要这三种能力

脑极体

百度 飞桨 文心

「 Java基础-链式调用 」Java开发中如何让你的代码看起来更优雅?试试链式调用?

小刘学编程

Java 设计模式 建造者模式

快速制作一个chrome插件

JYeontu

chrome Vue chrome扩展 Chrome插件

欠下“技术债”,谁负责?_语言 & 开发_Dan Brioli_InfoQ精选文章