【译文】我是一个糟糕的程序员

程序员| 2023-12-26

我是个糟糕的程序员。你可能会认为，我做了将近 25 年的程序员，现在应该很在行了。但不是的，我还是会在代码中出现错误，使用错误的变量或子程序参数类型，忘记进行正确的库调用，弄乱 if 语句中的表达式，诸如此类的错误一直持续了 25 年。

有时代码无法编译，我可以立即修复这些错误，但其他时候，我必须实际运行程序才能意识到我的失误。如果我 “幸运 “的话，程序会启动，然后在一片错误信息的光辉中崩溃。如果我不那么幸运，程序会启动，然后几乎立即退出（假设这不是它应该做的），或者进入 “啦啦乐园”，既不做它应该做的事，也不退出。

或者更糟糕的是，程序看起来运行得很好，只有当我研究到程序功能的某个角落时，才会出现一些微妙的问题–有时甚至微妙到一段时间内都不会被注意到。当然，还有一些非确定性错误，只有当一连串事件（可能源于程序外部）在特定时间间隔内以特定顺序发生时，它们才会显现出来。程序可能会在 1000 次中正确运行 999 次，但第 1000 次运行可能会锁死整个系统。(我就遇到过这种情况，发现了vendor 库的漏洞）。

不过，关于我设计和编写的程序，最奇怪的是，一旦它们交付给客户或作为基线版本发布，它们通常都能正常运行，这似乎令人吃惊，因为它们是由一个如此糟糕的程序员编写的。我的意思是，我通常会按时交付系统，提供所需的功能，而且很少出现错误。

那么我的秘诀是什么呢？

嗯，就是这些伪禅宗编造出来的古代软件大师的秘诀之一：

除非你承认自己永远是一个糟糕的程序员，否则你永远不会成为一个伟大的程序员。

正如你在第一句话中看到的，我完全承认我是一个糟糕的程序员。既然我热爱编程，这也是我选择的职业，我就必须面对它。

幸运的是，我有很多办法可以掩盖我是个糟糕的程序员这一事实：

1) 如果我可以为某个程序挑选编程语言，我的 “首选 “语言就是 Ada。是的，我知道如今除了国防工业之外，Ada 语言几乎无人问津，即使在国防工业中也是举步维艰，但要向糟糕的程序员指出他们到底有多糟糕，Ada 语言却鲜有匹敌者。有了 Ada 语言的所有类型和运行时检查，程序员不喜欢 Ada 也就不足为奇了，因为 Ada 会不断指出他们代码中的错误！

如果我不能使用 Ada，那么 Java 就是下一个最佳选择，因为它也有很多内置的错误检测功能。

但是，请不要再让我使用 C++ 了，它绝对是糟糕的程序员自我意识的助推器。它允许大多数事情通过，所以 a) 我对代码编译干净并 “大功告成 “感觉很好，b) 在经过 Jolt 助推的马拉松式调试后，我的自尊心得到了极大的提升，而这正是让程序成功运行的必要条件。

2) 我经常使用编程断言。如果某个变量永远不会为空，我会断言它不是空的，即使 Grady Booch 在一堆 UML 标准上发誓它永远不会为空。这就是我被发现的偏执程度：即使我控制了接口的两边，我也会断言数据提供者提供的数据是有效的，并断言接收者接收的数据是有效的。为什么？因为众所周知，我在更改接口的一侧时会忘记更改另一侧，所以断言会立即帮我发现这些问题。

3) 做一个测试受虐狂，即无情地破坏自己的代码。没有哪个程序员喜欢这么做，我们通常很高兴能让测试用例数据按正常方式运行，为什么要自找麻烦呢？我承认，有意尝试破解自己的代码是一种精神挑战，但如果我不这么做，别人也会这么做，我这个糟糕程序员的秘密身份就会暴露。

4) 让其他程序员检查我的代码。尽管我做了很多，但作为一个糟糕的程序员，我的代码中仍然会有 bug。因此，我需要其他程序员，尤其是其他伟大的程序员，来检查我的代码并找出这些错误。我对这些检查是认真的，我不希望只是粗略地看一眼，确保我包含了正确的文件头信息，我要的是检查，该死的检查！有一次，我不得不对我的一位检查员大加指责，因为他没有记录下他发现的所有缺陷，是在 “帮我的忙”，因为他不想让我 “感觉不好”。听着，作为一个程序员，我没有自我形象，所以 “感觉不好 “并不是我在意的事情。我需要写出优秀的代码，所以作为一个糟糕的程序员，我需要一切可以得到的帮助！

有了这些和其他糟糕的程序员混淆技术，我的代码往往看起来就像是由一位出色的程序员编写的。在我的职业生涯中，我曾有机会从事飞行模拟的实时执行和航空数据分析工作，对一个主要国防系统的指挥和控制规划系统进行了清一色的重新设计，独自负责重新托管一个大型指挥和控制系统，在另一个大型国防系统的 XML 框架中进行数据挖掘和事件关联，并将传统的战争游戏操作员控制台替换为以网络为中心的版本。日常工作之余，我还编写开源软件（用 Ada 编写！），其中一些已被一家为欧洲航天局提供支持的公司采用。(我要去月球了！”。）

因此，到目前为止，我一直成功地掩盖了自己是个糟糕的程序员这一事实，我需要确保自己能在这条职业道路上一直走下去，直到退休。听了汉-索罗的告诫（”好小子，别得意忘形。”），我们来看看第二句假禅老软件大师的斜体箴言：

只有当你承认自己仍然是一个糟糕的程序员时，你才能继续成为一个伟大的程序员。

多年来，我学会了更多隐藏自己编程失败的方法。其中一种技巧是：让程序崩溃–这招很管用，请跟我来。我曾参加过一个开发项目，最初的开发人员遇到了很多运行时异常的问题，于是他们干脆开始加入 “空异常处理程序”，即捕获所有意外异常，抑制它们，然后继续运行。不用说，系统会正常运行一段时间，有时甚至几个小时，然后慢慢开始……嗯…… “偏离轨道”。

当我有机会重新设计系统时，我立即禁止使用无效异常处理程序（尽管允许使用处理程序处理公认的异常情况）。如果出现异常，我希望它能一直传播下去，直到导致应用程序宕机，这样我们就能知道它的存在，并在第一时间进行修复。我如愿以偿，但在此过程中差点被发现。项目经理得知我们在测试过程中发现了很多系统崩溃的问题，他想知道为什么重新设计的系统崩溃的频率比替代的系统要高得多。解释说我们正在发现错误并立即修复，而且修复得很好，但这并没有给他带来他想要的温暖，因为最后期限快到了，而报告的错误率并没有像他希望的那样快速下降。但团队还是坚持了这一做法，当我们按时、按预算完成工作后，系统在轻负载和重负载情况下都能可靠、正确地运行数天。

对我来说，这巩固了我作为一个糟糕程序员的自我形象。如果我能够实现这样一个系统，满足它的所有要求、预算和进度限制，只需在最终产品中有意识地应用一系列技术来揭示我在编程方面的缺陷，那么我知道，在我余下的职业生涯中，我将能够伪造它。

现在，如果你看了我的代码，你可能会发现它非常糟糕，这很正常，几乎所有程序员在看了其他程序员的代码后，都会认为它是一堆内脏，然后宣称修复它的唯一办法就是重写。(我想知道这是为什么？）

但如果你愿意坐下来和我一起检查我的代码，并告诉我它的问题所在，那么我想我们可以一起解决这些问题，使它成为真正优秀的代码。谁知道呢，也许你最终会成为和我一样糟糕的程序员。

本文文字及图片出自 I Am a Terrible Programmer