Linux 之父出席、干货分享、圆桌讨论,精彩尽在 OpenCloudOS 社区开放日,报名戳 了解详情
写点什么

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

  • 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:003226

评论

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

Spark 开源新特性:Catalyst 优化流程裁剪

华为云开发者联盟

sql spark 开源 Catalyst 优化器

ZooKeeper 分布式锁 Curator 源码 04:分布式信号量和互斥锁

程序员小航

Java zookeeper 源码 分布式锁 zookeeper分布式锁

Chaos Mesh 助力 Apache APISIX 提升稳定性

Apache APISIX 中国社区

lua 网关 APISIX Chaos Mesh

去中心化薄饼交易所开发|PancakeSwap去中心化交易所搭建方案

Geek_23f0c3

交易所开发 去中心化交易所系统开发 PancakeSwap交易所

记一次真实的JVM性能调优过程

北游学Java

Java JVM 性能调优

又一数据库高危漏洞爆出,数据安全如何有效保障?

华为云开发者联盟

redis 漏洞 GaussDB(for Redis) 开源Redis 数据库安全

校友资料登记平台小程序开发笔记二-云数据库设计

CC同学

校友录小程序 校友资料小程序

入门必读 |《TcaplusDB数据库常见问题解决及诊断技巧集锦-信息咨询类-2》

tcaplus

TcaplusDB

利用亚马逊云科技Direct Connect和Transit Gateway轻松构造企业混合云解决方案

亚马逊云科技 (Amazon Web Services)

区块链不是一个风口,而是一个时代

CECBC

看焱融云CSI动态感知如何扩展Kubernetes Scheduler

焱融科技

云计算 技术 云原生 高性能 分布式存储

带你了解WDR-GaussDB(DWS) 的性能监测报告

华为云开发者联盟

数据库 数据 GaussDB(DWS) WDR 负荷诊断报告

应届女生美团Java岗4面,一次性斩offfer,我受到了万点暴击

Java 编程 程序员 架构师 计算机

抖音快手短视频获客软件开发系统

还在使用NoSQL数据库?为IoT选择TSDB

数据库 大数据 时序数据库 tsdb 数据智能

丰富 TF Serving 生态,爱奇艺开源灵活高性能的推理系统 XGBoost Serving

爱奇艺技术产品团队

开源 优化 tensorflow serving 推理

SaaS市场百花齐放:厂商数量已达4500家,用户数量已达915万家

海比研究院

kafka日志存储以及清理机制

泽睿

kafak

一周信创舆情观察(7.12~7.18)

统小信uos

哪类技术助力了隐私计算的工业化?如何“组装”发挥更大价值?

EasyRecovery软件帮你快速恢复图片数据

淋雨

EasyRecovery 文件恢复 硬盘数据恢复

入门必读 |《TcaplusDB数据库常见问题解决及诊断技巧集锦-数据库使用类-1》

tcaplus

TcaplusDB

测试开发之系统篇-安装KVM虚拟机

禅道项目管理

虚拟机 测试开发

Java的这个强大功能,很多人都不知道

华为云开发者联盟

Java c++ jdk 算法 jni

Cassandra的调优总结

林一

分布式数据库 Cassandra

Go语言:new还是make?到底该如何选择?

微客鸟窝

Go 语言

13张图,深入理解Synchronized

程序猿阿星

synchronized java 并发 锁机制 锁升级

棒极了!可以让你Java程序快上180%以上的阿里性能优化笔记

Java架构追梦

Java 阿里巴巴 架构 面试 性能优化

网络研讨会|为什么在开发流程中应用静态代码分析工具?

鉴释

在线研讨会 静态代码分析

从 Web 图标演进历史看最佳实践

百度Geek说

大前端

GPU容器虚拟化:用户态和内核态的技术和实践详解

GPU容器虚拟化:用户态和内核态的技术和实践详解

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