您如何处理故意的错误代码？

关于故意错误代码的故事很多，不仅在TheDailyWTF上，而且在SO上。典型的案例包括：

• 具有无用的浪费时间的构造（例如，空循环计入了巨大的价值），因此程序员可以轻松地通过在任务执行时删除应用程序来“加速”应用程序。
• 提供故意误导，错误或没有文档的文档，以产生昂贵的支持请求。
• 即使一切正常，也容易产生错误，或更糟糕的是，即使应用程序运行良好，也会锁定应用程序，因此需要昂贵的支持电话才能解锁。

这些观点显示出或多或少的恶意态度（即使有时是偶然的），尤其是第一点经常发生。

一个人应该如何处理这样的结构？忽略问题，还是仅删除有问题的代码？通知他们的经理，或与介绍“功能”的人交谈？

最糟糕的代码是由于缺乏理解，解决方案是教育。

故意的不良代码是完全不同的，这是由于某些东西完全与编码人员的经验或项目的其余部分无关。因此，您必须找出为什么他们故意破坏代码并处理该问题。这通常意味着办公室政治，这对任何人来说都不是一件令人愉快的情况。

我在政治方面的处理方式取决于许多（上面未说明）的情况。我将如何处理代码，首先要确保我不是一个误会（它确实是不好的代码），然后解决明显的缺陷。如果有合理的可能，请编写测试以确保错误的代码将失败。仔细检查我已正确理解的含义是与编写代码的人交谈。应当以一种非常友善，礼貌的方式来完成此操作，而无需假定意图，这可能有助于找到以后需要的潜在（政治）原因。

运输比象牙塔的完善更为重要，但有两点需要解决。解决明显的缺陷可以用20％的精力来获得80％的结果，而这种低落的果实很少值得忽略。但是更重要的是，如果您不解决潜在的（政治）原因，则很可能会故意编写不良代码并引起进一步的问题-并可能阻止发货。

我从未（有20多年）遇到过有意的错误代码，但您引用的示例（至少对我而言，但对IANAL而言）似乎是企图欺骗雇主或客户，因此您可能拥有合法的向您的经理指出的义务。

取决于公司的文化。通常，修复和清理所有不良代码根本不是您的工作。

杰米·扎温斯基（ Jamie Zawinski）从《在工作中的编码人员》一书中提出的过度工程思想，也可以应用于这种情况：

在一天结束时，运送该死的东西！重写代码并使其更加整洁是一件很不错的事，到第三次它实际上会变得很漂亮。但这不是重点–您不是在这里编写代码；您在这里运送产品。

那里有很多不良的编码器和代码，只是在您遇到问题时尝试全部修复它们，而以当前的项目/任务为代价，如果产品“正在运行”，则可能根本不值得。很多时候，我们都是管道胶带程序员。

另请参阅Joel Spolsky的文章：Duct Tape Programmer

这种态度是更糟的征兆。

• 管理层是否在鼓励开发商的竞争？

• 团队合作精神在哪里？

• 任务是由团队本身分配的吗？

• ...

无论如何，仅仅删除有害代码是不够的。向他的经理抱怨当然不会帮助改善团队合作精神。

我会尝试直接与该人交谈，并通过问很多问题而不去评判他来理解原因。整个团队都必须做到没有侵略性。

在大多数情况下，这种建设性的行为可以将真正的问题（更糟的问题）暴露在外，然后您可以进行解决。

如果真的不起作用。从团队中删除该开发人员。

如果我认为这是故意的，我可能会开除那个人！如果这是由于某人不够优秀的程序员而导致的，那么我将致力于他的技能。如果从上面推开它，我可能会开始寻找新工作。

一个人应该如何处理这样的结构？忽略问题，还是仅删除有问题的代码？通知他们的经理，或与介绍“功能”的人交谈？

根据上下文，其中任何一种可能都是最合适的。其他可能性包括，要求转移到其他项目，获得新工作以及道德和/或合法性令人怀疑的各种行为。

但是，由于我们不了解真实的事实和所涉及的真正的人，因此您所描述的职位上的某人绝对不会对我们的建议/ 2美分的价值给予高度关注。

如果您正在谈论的是真实情况，可能值得与您的经理保持沉默，并向他们的经理询问您应该做什么。如果可能，尝试就您可以/应该做什么进行对话，而不是指责。如果可能，不要命名。您的经理很可能已经暗示了这个问题。

但另一方面是，您可能会夸大其词。在做任何事情之前，请三思而后行。考虑后果，包括您采取的任何步骤都可能适得其反的后果……严重。