我的 20 年职业生涯：全是技术债

|

如今，技术债无疑是最常用的流行语了。有人说：“我们正在快速开发 MVP，同时最大限度地减少技术债！”。他们在这里提到技术债听起来很酷。但我只是笑笑，因为这最终都会是技术债。

我的整个职业生涯都是关于现在流行的技术债的，或者说是关于代码被弃用的。

如果你不相信你的整个职业生涯也会是关于技术债的，你可能会在阅读完这篇文章后有同样的想法。在本文中，我将带你了解我 20 年职业生涯中的变化。

我的职业生涯始于 Visual Basic 6 的开发。从 1999 年到 2003 年，我构建了多个不同的应用程序。我想你可能会说，按照今天的标准，Visual Basic 6 中的任何东西都是技术债，或者早就被取代了。万岁，“下个错误再接再厉!”

我花了很多时间进行经典的动态服务器页面（ASP）开发。有一段时间，我还是一名在 Internet Explorer 6 和 Netscape Navigator 制作兼容网站的专家。这在简历上已经没有多大意义了！

Visual Basic、ASP、IE6 和 Netscape 都是早已被遗忘的技术了。正如Strong Bad当时所说的那样，“被骗了！”

过时的语言：Perl、Delphi、Fortran、FoxPro、ColdFusion

在过去的 20 多年里，除了 Visual Basic 6 之外，还有很多编程语言也都失宠了。很有可能，如果你用这些语言中的任何一种构建了任何的东西，人们都会想要找出重写它的方法，因为很难再找到使用这些语言的程序员了：Perl、Delphi、Fortran、FoxPro、ColdFusion。

还有使用这些语言的应用程序吗？你还能雇人来做吗？这很难。在大多数情况下，这些公司都必须要对旧的应用程序进行现代化改造并淘汰旧的。在 21 世纪初，人们认为 Adobe ColdFusion 是最热门的产品。你还记得它刚成为明星的时候吗？

Ruby on Rails 也正面临着被添加到这个列表中的危险。它已经失宠了，很难找到使用它的开发人员了。曾经使它独一无二的东西现在也可以在其他语言中使用了。

编程语言来来往往。开发人员不希望学习工作中不需要的技能。这永远保持供需平衡！开发人员跳槽的速度很快；他们总是希望自己的简历上有一些热门的新东西。

ActiveX、Java Applets、Flash 和 Silverlight 发生了哪些变化？

我最初开发的一些应用程序使用了 Internet Explorer 6 中的 ActiveX 控件。当时，需要用它们来做打印和其他一些非常不安全的黑客工作。PDF 在当时并不常见，用浏览器打印简直就是一场噩梦。

Java Applets 在很久以前也是一件大事。它们运行缓慢，并且在电脑上安装正确版本的 Java 总是一团糟。我永远不会忘记处理 Java 小程序网络防火墙的噩梦。我一点也不怀念它们，幸运的是，它消失了。

当然，我们都还记得 Macromedia/Adobe Flash！它一度是整个互联网的宠儿。Flash 游戏层出不穷，许多软件都是用 ActionScript 在 Flash 中构建的。一种名为 CheerpX 的产品现在允许使用 WebAssembly 运行旧的 Flash 应用程序。

微软推出了一个名为 Silverlight 的 Flash 竞品。对于 C#开发人员来说，这实际上是一个非常棒的框架。我的公司用 Silverlight 构建了一些非常棒的东西。

众所周知，苹果在浏览器中放弃了对 Flash 和 Silverlight 的支持，从而终结了它们。

这是十多年前我们在 VinSolutions 中使用 Silverlight 构建财务计算器的屏幕截图。Silverlight 现在早已不复存在，他们用完全的 JavaScript 重写了它，但它没有旧版本酷了！


我的第一个移动应用程序

在 2004 年，我开发了一个移动应用程序。这很难记起，但当时 iPhone 和 Android 还不存在。我为 Compaq PDA 编写了一个应用程序，用于跟踪汽车经销商的库存。它是用 C#编写的，用于在 Windows CE 上运行的.NET Compact Framework 中。

这个 PDA 有一个 100 万像素的摄像头。只要外面阴天遮住了刺眼的光线，这些照片就会糟糕些。😂 天哪，技术变了嘛！这个应用程序很早以前就被淘汰了，但在 2005 年时它还很前卫。

Swift、WebForms、MVC 与 Angular JS

Swift 是另一个很好地说明开发工具变化速度之快的例子。苹果公司发布 Swift 后，就很难再证明用 Objective C 编写代码是合理的了。我确信在某些用例中仍然需要用 Objective C。但 Swift 明显更易于开发，并且是向前迈出的重要一步。

我认为，任何用 Objective C 编写的应用程序现在都可能是技术债了。

在为构建 Web 应用程序编写了疯狂的内联脚本之后，我很乐意使用新的 ASP.NET Web 表单。它们的服务器端控件大大简化了开发。它们的目标是让创建 Web 应用程序变得像在 Visual Basic 6 中一样简单。它基本上是有效的！你可以在服务器端构建可重用的 UI 组件以呈现给浏览器。就像我们今天使用 100%的 JavaScript 所做的那样。

WebForms 并不完美，但它是一个相当大的提升。在 Ruby on Rails 出现并普及了用于开发 Web 应用程序的 MVC（Model-View-Controller，模型-视图-控制器）框架之前，它一直运行得很好。

MVC 很快就淘汰了我们制作的所有 Web 表单应用程序。任何网页形式的东西都绝对是技术债。（尽管如此，Blazor也有同样的想法。）

不知不觉中，每种编程语言就都支持 MVC 框架了。我们转而使用 ASP.NET MVC 做所有的新功能。它无处不在，包括 Django、Laravel、Symfony、Spring 等。

快进到今天，MVC 已经过时了。现在一切都是在 React、Angular、Vue 和其他框架中完成的。

在我们拥有这些框架之前，我们还有其他的 Javascript 框架。在Stackiy，我们使用了 Knockout，这是一个相当流行的前端框架。

你还记得这些框架吗？Knockout、Ember、Aurelia、Meteor、Backbone、Handlebars。

如果你使用过其中的任何一个，我敢打赌，所有这些代码现在都被认为是技术债并且已经失宠了。第一代前端框架输给了 React 和 Angular。

2015 年，Angular 由谷歌创建，并一炮而红。它迅速成为最受欢迎的前端框架。然后在 2016 年，Angular 进行了一次重大升级，不再向后兼容。猜猜这意味着什么？原始版本中的任何内容现在都是技术债了。我在我公司的项目中使用了旧版本的 Angular，这是我们必须升级的主要技术债。

过时的 SOAP 和 WCF

在 REST API 和 JSON 成为事实上的标准之前，另一种选择是 SOAP，它代表简单对象访问协议。它使得调用 Web 服务并通过自动代码生成代理类来正确调用服务变得更容易。它主要由基于 XML 的 Windows 通信框架（WCF）来使用。

它非常棒……直到它失败。我职业生涯中最糟糕的项目之一就是要弄清楚如何在我的公司和另一家供应商之间通过 WCF 和 SOAP 使用安全证书。SOAP 和 WCF 的承诺令人惊叹，但随着时间的推移，维护它简直是一场噩梦。

SOAP 和 WCF 是两个我不会错过的东西。微软决定不再在.NET Core 中支持 WCF。像 REST、gRPC 和 GraphQL 这样的东西现在是首选。尽管如此，有个社区项目最终使CoreWCF得以继续发展。

随着时间的推移，我们用来调用 Web 服务的技术类型已经发生了变化。旧的方式仍然有效，但大多数人可能更愿意淘汰它们。

主要语言版本

另一个常见问题是主要编程语言的版本更改。无论是 Ruby、PHP、.NET 还是其他语言。它们通常需要大量的代码更改甚至重写。

当.NET Core 刚发布时，它是专为在 Linux 上运行而设计的更新、更轻、更快的.NET 版本。基本的 C#代码都很容易移植过来，但没有人会在真实的应用程序中只使用基本代码。

然而，在复杂的企业应用程序中，在导航升级路径时存在许多潜在的问题。这就成为了一笔必须解决的重大技术债。否则，你最终会陷在一个古老的版本中。

这些主要版本的更新最终会成为重大的技术债项目。

我们在 Stackiy 遇到的最大挑战之一是卡在了旧版本的 Elasticsearch 上。有一次，它们对其工作方式进行了一些重大的更改，但这些更改并不完全向后兼容。我们用得非常重，所有的升级工作都变成了海量的技术债和升级项目。

我们一遍又一遍地把它踢到路边，最终远远落后了。这是另一个可能困扰公司的真实的技术债项目的例子。

开源替代方案淘汰了我的代码

在Stactify，我们为 6 种编程语言构建了自己的跟踪/测评分析库。这项工作的工作量令人难以置信。

好吧，现在OpenTelemetry出现了，使得我所有的工作变得毫无用处。

既然可以使用开源的行业标准，为什么还要自己管理呢？Stackiy 正在慢慢地消除那些我帮忙构建的.NET 测评分析器。

随着时间的推移，你会看到你创造的几乎所有的东西都会因为各种原因而被废弃和替换，或者现在就已经都是基于旧技术的了。

我在职业生涯早期开发的几个应用程序都已经被终止了，因为这些公司被收购了，并且决定使用完全不同的技术。

大多数软件的使用寿命都很有限，比你想象的要短。所有的代码最终都变成了技术债，每个人都想用更现代的方式重写，或者业务需求发生重大的变化。

诚然，在企业界，更有可能拥有似乎永远存在的内部应用程序。像铁路或大型银行这样的公司使用同样的基于大型机的软件已经有 40 年了。

我预测 WebAssembly 最终会超越当今的前端开发，一个全新的世界将不断发展。

技术债的本质

在做新项目时，人们总是希望将技术债降至最低。我理解。在让事情运转起来和努力让事情变得完美之间是要有平衡的。

然而，没有什么是不技术债，因为它并不完美。世上没有十全十美的这回事。随着时间的推移，今天完美的东西将来也会不完美。要学会与不完美共存。

技术债的另一面是，随着时间的推移，一切都会慢慢腐化。它要么在升级到最新版本方面存在重大问题，要么由于更新的操作方式而最终失宠。祝你好运，能为旧的技术栈招聘到人员。

一切最终都会变成技术债，否则项目就会夭折。如果幸运的话，你的代码能存活足够长的时间，从而成为别人的技术债。

如果时间足够长的话，你的所有代码都将被删除。🤷‍♂️

原文链接：https://blog.visionarycto.com/p/my-20-year-career-is-technical-debt

本文文字及图片出自 InfoQ

你也许感兴趣的：

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注