该项目包含一个11,000行代码文件 The project with a single 11,000-line code file-CSDN博客

该项目包含一个11,000行代码文件 The project with a single 11,000-line code file

发布于: 4/3/2022
发布在: https://austinhenley.com/blog/11000lines.html

在这里插入图片描述
A long time ago at one of my first software jobs, I received a bug report for a internal product that I didn’t even know existed.
很久以前，在我的第一份软件工作中，我收到了一份内部产品的错误报告，我甚至不知道它的存在。

It turned out to be an application that serves up basically every form that any employee within the company might need. Essentially a catch-all resource. Do you need to report someone to HR? There is a form for that. Do you need a contract for a new client? There is a form for that.
它是一个应用程序，基本上提供了公司内任何员工可能需要的所有表单。基本上是一种资源。你需要向HR报告某人吗？有一个表格。你需要一个新客户的合同吗？有一个表格。

The responsibility of maintaining the project had been bounced from team to team over the years. Apparently it belonged to my team. And by my team, I mean me.
多年来，维护该项目的责任一直在团队之间转移。显然是我的团队的。我说的团队，指的是我。

Oh, the horror. 哦，太恐怖了。

It was a single code file with over 11,000 lines of VBScript.
它是一个包含超过11，000行VBScript的单一代码文件。

Countless people had made changes to this file over the years. But they did not appear to be software developers. Their roles ranged from IT support to business analyst. I’m shocked at how little value the project was given considering how many employees used these forms each day.
这些年来，不知道有多少人对这个档案做过修改。但他们似乎不是软件开发人员。他们的角色范围从IT支持到业务分析师。考虑到每天有多少员工使用这些表格，我对这个项目的价值如此之小感到震惊。

It looked like the entire file would execute through from top to bottom, although I never actually confirmed it. The code followed a rough pattern of fetch some data about the user, check if some conditions are met, then do some action which repeated a thousand or so times. The conditions were often as simple as:
看起来整个文件将从上到下执行，尽管我从未真正确认过这一点。代码遵循一个粗略的模式，即获取有关用户的一些数据，检查是否满足某些条件，然后执行一些重复了一千次左右的操作。条件往往很简单：

If (usrrps = 5) And (wauth <> "") Then

What came next was usually a combination of displaying a form, accessing a file on a shared drive, running a SQL query on who know whose database, and sending an email to a hardcoded address.
接下来通常是显示表单、访问共享驱动器上的文件、在谁知道谁的数据库上运行SQL查询以及向硬编码地址发送电子邮件的组合。

Now, I had never used VBScript before (and haven’t since then), but many variables appeared to be unused. The names were indecipherable. Synonyms were littered throughout.
现在，我以前从未使用过VBScript（从那以后也没有），但许多变量似乎都没有使用。这些名字难以辨认。同义词到处都是。

Something I found hilarious is that a variable might be used on lines 200-210 and then again on line 8544. No where else.
我发现有趣的是，一个变量可能会在200-210行使用，然后再次在8544行使用。没有别的地方。

Much of the logic appeared redundant. Probably copy and pasted at some point then later diverged. Like, how many times does the user need to be authenticated in one code file? Once I dared to clean this up and reuse the authentication response, but it broke everything. I never figured out why. To this day I sometimes lie in bed wondering what could have caused this.
许多逻辑似乎是多余的。可能是复制和粘贴在某个时候，然后后来分歧。比如，在一个代码文件中，用户需要进行多少次身份验证？有一次我敢于清理这个问题并重用身份验证响应，但它破坏了一切。我一直不知道为什么直到今天，我有时躺在床上，想知道是什么导致了这一点。

There was no version control. The only context about code changes was in the bug tracker and in the code comments, though I learned the hard way to not trust those.
没有版本控制。关于代码更改的唯一上下文是在bug跟踪器和代码注释中，尽管我学会了不相信这些东西的艰难方法。

There was no test environment. If I made a change, I had to test it in “production”. All of the program’s state was based on the user’s privileges so we would impersonate whoever reported the bug such that we could see what they saw.
没有测试环境。如果我做了更改，我必须在“生产”中测试它。程序的所有状态都基于用户的权限，所以我们可以模拟报告错误的人，这样我们就可以看到他们所看到的。

There were no unit tests. If I made a change that caused some other “feature” to break, there was essentially a 0% chance I would know about it until a week later when Jeff in marketing would report a bug.
没有单元测试。如果我做了一个改变，导致其他一些“功能”中断，基本上有0%的机会，我会知道它，直到一个星期后，当杰夫在市场营销将报告一个错误。

What is the moral of the story?
这个故事的寓意是什么？