技术债务和技术投资

本文是翻译,版权归原作者所有

原文地址(original source):http://jamison.dance/12-31-2015/technical-debt-and-technical-investment/

作者(author): lexical NOPE(@jergason)

技术债务

技术债务,是软件工程讨论折衷方案时所用到的一种工具。当你遇到技术债务(注1)时,你就会堆积一些快速、肮脏的代码,它们更难以维护、或拉低了图中的效率曲线。随着时间的推移,和你一开始用正确的方式开发相比,维护快速、肮脏代码或基础架构的成本,要更高一些。你能够感受到此言不虚,因为我画了一张图。

一些人把技术债务的说法用作糟糕的代码。这不太正确。技术债务是某种原因导致的糟糕代码。有时候,你用错误的方式,以更快地完成工作;有时候更快速地完成,的确重要。当速度的好处超过维护成本或重构糟糕代码时,你会选择承担债务。

技术投资

技术债务的对立面是技术投资(注2)。对于技术投资而言,你当下放慢速度,是为了将来能够加快速度。或许你选择编程语言或 web 框架。你的团队花时间学习新工具,但是在某种程度上,如果你选择得当,它们就更有效率。下图是没有标数字的手绘图,它无可置疑地证明了这一点。

你需要投资

成功的产品,只会变得更加复杂。如果人们喜欢并使用你的产品,你将会增加更多功能和复杂性。对于人们愿意付费的、或大体上在使用的现有功能,是不可能移除掉的。

在最初原型阶段,工具和技巧是有生产力的,但是,有时候它会与较大型产品的复杂度发生冲突。如果你在处理复杂度方面不能投入,随着复杂度的增加,开发速度就会减缓。随着产品复杂度和团队成员的增加,技术投资能够规模化增加你的团队生产力。

风险

技术债务和技术投资均有风险。如果你低估了维护技术债务、或承担它所带来的好处,你的产品在长期收益方面将放慢脚步。如果你高估了技术投资的价值,你在短期内就会减缓进度,而没有长期加速。

好的技术投资所需条件?

如果你认同了技术投资,接下来的问题就成了「我该如何评判一项优秀的技术投资呢」?其答案可能和普通投资一样——你做不到的。你可以审核当前情况,并尽量预测未来趋势,但是,平心而论,这都是臆测。

技术上很难评判,因为我们经常期望看到立竿见影,如果我们看不到,就会放弃。计算机历史充斥着过早放弃的好思想,但是也长期散落着坏思想。

既然有了这些警告,下面给出一些预示,它们反映出 web 开发团队中属于好的技术投资。我不保证全部都是对的。

Elm、PureScript、或其它语言

静态类型的纯函数式编程是一种老思想了,它从未引起主流编程的注意。我认为,它是未来的一种方式,尤其对于客户端应用程序,更是如此。Elm(注3)和 PureScript(注4)正在解决文化和教育方面的问题,它们阻碍了类似语言赢得主流的使用,我觉得,在未来几年,它们当中一定会有一种语言赢得广泛的用户基数。

可观察对象

这包括了类似RxJS(注5)的技术、构建于 Cycle.js 之类的可观察对象之上的框架,还包括在 JavaScript 应用程序里使用可观察对象来管理状态和通信的通用实践。我认为,我们在管理客户端 JavaScript 方面还没找到有效的解决方案。可观察对象貌似成了更好方式的良好选择。

雇佣和指导初级开发人员

我可能要多谈一下这个问题,但是重点在于,人才市场的初级开发人员有着很低的薪水,他们常常为了找到工作而不顾一切。如果团队或公司能够和初级开发人员较有效率地协作,并帮助他们成长为高级开发人员,就会在雇佣方面获得巨大优势。

技术债务和技术投资

对于技术债务,你把代码搞得一团糟,随后需要自己擦干净屁股。对于技术投资,你预先理顺一切,以后你就能更有效率地工作。二者都可以被理智地使用,它们对于保持一种健康的工程师组织和文化也是必要的。

你对技术投资有什么看法?你有一些好的技术投资想法吗?

Jamison Dance 是 Kuali Co 的一名软件工程师。他喜欢小猫、让计算机更聪明、以及孩子们开怀大笑的魔力。他在 http://jamisondance.com 撰文,twitter 账号 @jergason,GitHub 账号 jergason。他还是 JavaScript Jabber 网站上的播客。

译文:《技术债务和技术投资 》|腊八粥

注释

原文注释翻译:对于术语「技术债务」,我所能找到的最早的引用来自于 1992 年 Ward Cunningham 写的文章,地址为:http://c2.com/doc/oopsla92.html。有意思的是,当 Ward 参与一个财务应用程序的工作时,这种想法就产生了关联。有时候,我们在和软件完全不相关的领域里,就能找到不错的比喻。

原文注释翻译:我是在几个月前和 Randal Bennet 的一次讨论时第一次听到技术投资的。

Elm 是一种函数式语言,可编译为 HTML、CSS 和 JavaScript。Elm 为函数式反应编程而设计,便于创建高可交互应用。http://www.oschina.net/p/elm

PureScript 是个小巧而强大的静态类型语言,可以编译成 JavaScript。purescript 主要是由 Haskell 和 PureScript 编写的。http://www.oschina.net/p/purescript

RxJS全名Reactive Extensions for JavaScript,Javascript的响应式扩展。响应式的思路是把随时间不断变化的数据、状态、事件等等转成可被观察的序列(Observable Sequence),然后订阅序列中那些Observable对象的变化,一旦变化,就会执行事先安排好的各种转换和操作。http://www.w3ctech.com/topic/1298

原文地址:https://www.cnblogs.com/wobushitiegan/p/12348652.html

时间: 2024-11-09 03:28:50

技术债务和技术投资的相关文章

技术债务可能是这样来的

看我技术博客的朋友可能有注意到,最近更新了一系列与CEF.PPAPI.Skia相关的文章.在研究它们的过程中,有一些有意思的经历,非常典型,可以从一个方面解释"技术债务"的由来. 接下来我会讲讲这次经历,并从此展开,看看形成技术债务的原因及应对策略. 选择容易的替代策略 因为业务需要,我得在PPAPI插件中显示另一个模块(已有模块,基于C++代码完成)传递过来的图像数据.那个模块提供的数据,图像格式是RGBA32,我在Intel Pentium主机上编译出的Skia库,默认的颜色类型是

技术债务

背景:最近一直在给研发团队强调一定要把产品平台关键的账号系统分离出来,而不是和业务产品线有瓜葛.但是因为涉及改动太大,业务线很忙迟迟得到不到执行.在这种情况下,我协调召开了研发的紧急会议,要求务必在近期解决这个问题,甚至不惜减慢业务线的进度.其实如果大家仅仅是因为时间紧.任务重无法改动我倒不担心,我最怕的就是大家认为这件事情并不严重,在我做技术的9年生涯中见证过太多次因为不重视这种情况.或者推迟修正造成的更大或者不可挽回的问题,那我们用2周或者更多时间来修正半年前犯下的错误是完全值得的. 为什么

技术债务偿还计划

英文原文:Technical Debt: A Repayment Plan 什么是技术债务? 许多团队都受技术债务困扰,不过,很少有团队能真正地设计一个计划从中挣脱出来.为了更好的理解如何才能摆脱债务,我们首先要正确地理解什么是技术债务. 技术债务是由团队为了短期的项目利益故意做了欠佳的技术决策而招致的.例如,为了使一个产品更快的投放市场,团队可能不会像面对一段棘手的代码 那样,编写深入的自动化测试.或者,他们可能会决定基于一个很快就会过时的框架构建项目,而不是花钱购买那个框架的一个经过升级.服

技术债务墙:一种让技术债务可见并可协商的方法

原文: The Wall of Technical Debt:A method for making technical debt visible and negotiable Published on 22 January 2020 by @mathiasverraes 翻译: 0x01 介绍 术语"技术债务"(Technical debt),是对软件设计中那些次优的.不再有效的.甚至错误的设计选择的隐喻.它们增加了软件进一步开发的成本.出来混的总是要还的,你今天选择的临时或山寨做法

技术债务(母鸡的遭遇)

技术债务,是指匆忙的实现一个功能,却对现有的程序库造成了破坏(在实现的过程中污染了代码库的设计),这对于一些项目经理/客户来说就像是天书奇谈.也许他们是明白的,只是不愿意承认罢了,我估计是这样的.不管怎样,我想起来一个小故事,当下次遇到这种情况,需要向他们解释增加某些新功能的代价时,也可用讲这个故事给他们听. 一个农夫有3只母鸡.每只母鸡每天下一个蛋.农夫跟当地的一个食品店老板做生意.食品店老板每天从农夫那里买2给鸡蛋放在店里出售.一切都很好,直到有一天,食品店老板出现在农夫家里: 食品店老板:

技术债务管理以及Firefox/Chromium的债务评价

现在的软件开发是在遍地敏捷,人人讲唯快不破的时代,哪有人有时间思考代码质量,设计的质量? 哪个又不是从一堆代码中杀出血路来实现另一个功能?一个产品都存活不了几年,何必考虑什么可维护性? 我们追求进度的时候,总是要牺牲些东西,或是破坏了一些东西等着后面补.这就是技术债! 管理不好,债台高筑,即使不破产,也是要拆东墙,补西墙的玩平衡.现实是残酷的,但不影响我们抬头看看这个世界. 技术债务 技术债务(Technical Debt)这个词,我最早是从InfoQ关于Uber的一个访谈中了解到的,正好也在思

Java代码中常见技术债务处理之Exception

写在前面 异常处理是代码中常见的处理,本文根据SonarQube在异常方面的规则和常见检查结果,选取说明了常见异常处理中的技术债务,提倡技术债务最少的编码方式. Exception handlers should preserve the original exceptions Either log or rethrow this exception. When handling a caught exception, the original exception's message and s

[译]技术债务中的人力成本

看到一篇讲技术债务中的人力成本的文章,显微阐幽,粗略译成中文,不求信雅达,但求不离原意太远. 原文地址为:http://www.daedtech.com/human-cost-tech-debt/ “技术债务”这个概念很值得去熟悉一下,如果你对这个概念还不熟悉的话:它不单是一个常见的业界术语,也是一个重要的概念. Ward Cunningham创造了“技术债务”这个词,这个词本身就意味着在如果今天在你的软件中走了捷径,那么不单是最后要还这个债,而且还要支付债息.换句话说,今天你在交付之前用一个全

AppCan CTO辩论会:移动开发者忠于技术or 背离技术

第一期CTO辩论会结束后,大家在微信群中讨论,学什么编程语言好.有位官人直呼"劳力者治于人,苦差,不学也罢". 在IT.科技变革世界的今天,移动开发者成为一个非常时髦的工种.就连老家的爷爷奶奶都知道,程序猿挣钱多,BAT待遇好,创业的孩子差不了. 但是,技术人已经不是单纯的工匠,他们正快速背离自己原本的身份,像更多元化的商业身份扩展:老板.管理者.商人等等.总之,在这个时代,技术人面临的诱惑和机遇爆发了. 热爱技术,享受技术带来的成就:也背负着技术,在每个难熬的关卡被技术所折磨. 忠于