原文：Austin Z. Henley - 2022.04.03

很久以前，在我的第一份软件工作中，我收到了一份内部产品的错误报告，而我甚至不知道这个产品的存在。

结果发现这是一个应用程序，它基本上提供了公司员工可能需要的所有表格。从本质上讲，这是一个包罗万象的资源。你需要向人力资源部举报某人吗？这里有一份表格。你需要为新客户准备一份合同吗？这里也有一份表格。

多年来，维护项目的责任一直在各个团队之间辗转。显然，现在它属于我的团队。而我说的我的团队，实际上就是我一个人。

哦，太可怕了。

这是一个单文件的项目，包含超过 11000 行的 VBScript 代码。

多年来，无数的人对这个文件进行了修改。但他们似乎并不都是软件开发者。他们的角色从 IT 支持到业务分析师不等。考虑到每天有多少员工使用这些表格，我对这个项目被赋予的价值之低感到震惊。

看起来整个文件会从头到尾执行，尽管我从未真正确认过。代码大致遵循一种获取用户的一些数据，检查是否满足一些条件，然后执行一些操作 的模式，这个模式重复了大约一千次。这些条件通常很简单，比如：

' 如果 usrrps 等于 5，并且 wauth 不等于空字符串，执行 ...
If (usrrps = 5) And (wauth <> "") Then

接下来通常是显示一个表格、访问共享驱动器上的文件、在不知道谁的数据库上运行一个 SQL 查询，以及向硬编码的地址发送邮件的组合。

我以前从未使用过 VBScript（后来也没再用过），但许多变量似乎都未使用过。变量名难以解读，同义词散布在各处。

“有趣”的是，一个变量可能在 200-210 行被使用，然后再在 8544 行被使用。除此之外，别无他处。

许多逻辑看起来是冗余的。可能在某个时候被复制粘贴，后来又发散开来。比如，用户在一个代码文件中需要被认证多少次？有一次我冒险清理这些并重用认证响应，但结果是一切都崩溃了。我从未弄清楚原因。直到今天，我有时躺在床上还在想，到底是什么原因导致了这种情况。

当时没有版本控制。关于代码更改的唯一上下文只存在于错误追踪器和代码注释中，不过我也从中学到了不能相信这些。

项目没有测试环境。如果我做了改动，就必须在“生产”环境中测试它。程序的所有状态都基于用户的权限，所以我们会模拟报告错误的人，这样就能看到他们看到的内容。

如果我做了一个改动，导致其他一些 “功能” 被破坏，我基本上没有机会知道，直到一周后市场部的 Jeff 报告了一个错误。

那么，这个故事的寓意是什么呢？

  • 用户并不关心技术或代码。
  • 开发人员确实关心。
  • 技术债务是真实存在 的，并且可能带来高昂的代价。
  • 人们的聪明才智是惊人的。

我也不知道 🤷‍♂️。