什么时候必须使用糟糕的设计来完成一个项目？

Question

有许多不同的不良做法，例如内存泄漏，很容易在事故中插入程序。有时候，他们甚至可以将您的计划一起评审。

我正在研究一个项目，如果我故意在我的代码中放入内存泄漏，它就可以工作了。如果我把漏出，代码崩溃了。显然这很糟糕，需要很快（并将会）修复。

我的问题是，你什么时候决定在这种状态下交付代码，如果没有这些不良做法就无法及时发布代码？

Answer 1

如果问题对系统实际使用情况的影响可以合理地预期为无或可忽略不计，并且交付日期不能推迟，并且可以在问题影响变得可忽略不计之前的一段时间内修复发货。

显然这不是理想的甚至是推荐的，但是你现在明显被推到了一个角落。有时候没有好的选择，但实用主义必须胜过正式的正确性。如果应用程序有内存泄漏，但我们可以合理地预期应用程序将被回收或重新启动机器或在泄漏成为真正问题之前的任何事情，这有时可能比迟到更好。这取决于协议的条件和客户。

至少尝试推迟交付日期总是更好，但我假设你已经尝试过，而且这不是一个选择。

通常，一旦应用程序被发送以忽略technical debt并继续前进。开发商有责任向利益相关者清楚地告知偿还部分债务的重要性，特别是在这种情况下。

然而，鉴于客户似乎更关心交货日期而不是正确性，因此一旦您上线，任何人都不太可能会相信偿还任何债务。这是一个糟糕的情况。只有拥有所有事实的人才能做出正确的选择。

Answer 2

“我的问题是，你什么时候决定在这种状态下交付代码，如果没有这些不良做法就不可能及时发布代码？”

从不。

你做了什么：优先考虑并集中注意力。

如果您正在进行的工作确实是高优先级的，并且您错误地设计了它，那么必须牺牲一些低优先级的东西。通常，某些功能必须延迟，以便您有时间专注于不起作用的高优先级功能。

如果您正在进行的工作实际上是低优先级的，那么您必须问为什么您没有处理更高优先级的事情。而你仍然需要关注并优先考虑。有时必须牺牲优先级低的东西。

如果你不能做“一切”你必须选择可以做的事情，这将是合理的无错误。

Answer 3

您可能对technical debt的概念感兴趣。

Answer 4

在发运软件时，您只能使用三个旋钮，假定开发人员数量固定：功能，质量和发货日期，并且启动一个意味着其他人被拒绝。

软件开发中最困难的事情之一就是使用恰到好处的旋钮来构建您的产品。例如，Duke Nukem Forever的家伙已将功能和质量旋钮调高到11，并将发射日期旋钮抛出窗外。微软经常似乎将发货日期旋钮固定到位并根据需要调低功能旋钮，然后解开发货日期旋钮，将其向上旋转一点，将其胶合回来并继续将其他两个旋转。并且似乎有无数的产品一直在发货，但从未投入成功所需的功能。

最后，如果你不送货，你就不会得到报酬。从长远来看，质量差是非常伤害你的;声誉很难重建。如果你有太多的错误，几乎总是正确的做法是削减功能。总是

然而，错误分类与功能开发同样重要。我们在这里谈论什么样的泄漏？你漏了一个字节吗？一个小物件？一千件物品？整个DLL？在某些情况下，泄漏可能比不能交付产品更好。

泄密是什么意思？您的应用程序是否具有明确的生命周期？你在启动时分配一次，然后在进程死亡之前永远不会释放它的地方？那么你的过程需要多长时间？您希望运行多个流程副本吗？

显然，你从不想要泄露，你应该努力开发最小化泄漏的最佳实践，但最终你必须做出判断。也许你可以向客户解释这个错误，解释其影响，他们无论如何都会购买它。也许你可以在一周后修补它。也许你确实需要解决它。但我们需要了解更多有关它的建议。

我会说我过去发过已知的泄漏事件。我不会说什么产品或公司，但我有一个错误，DLL依赖和疯狂的生命周期管理几乎无法在加载后正确地释放我们对某个DLL的引用，所以最后我们只是泄露了它。我仍然认为这是正确的做法。其他时候，我已经看到故意泄露的东西，以保持第三方代码不正确地写入崩溃（虽然这是一个完全独立的辩论）。

但最后我相信这种情况很少见，一旦你确定了内存泄漏的来源，就不应该花费一天多的时间来修复它。我确实很少发送已知的内存泄漏并且已知修复。它必须是需要一个主要的重新架构师，需要改变一个线程模型，或重构大量的代码，并且它必须在产品发布前一两天。那时我可能会泄漏内存，并在重新架构后进行适当的测试后承诺补丁。

Answer 5

我会非常不舒服地发布这样一个已知的错误。它可能以另一种方式发生。

您尚未指定您的环境或语言，但我建议您查看使用内存检查工具，例如：

Purify（可提供试用版）

BoundsChecker

Valgrind

甚至是免费的，Visual Leak Detector

Answer 6

也许，如果您以后不打算维护代码，则不关心您的客户/雇主，您的代码的任何后果都不会对您产生影响。

换句话说，在您的专业编码生活中，它从来就不是一个真正的好的想法。

如果您正在为那些不太关心代码质量的人工作，并且只是希望您不惜一切代价完成代码，那么我就能看出您是如何处理困难的。完成得更快但更差会立即获得奖励。你应该记住，即使未能满足你的雇主/客户对里程碑的期望只咬你一次，你的糟糕代码可能会继续咬你到未来，不仅是因为维持它的困难，而且还因为他人的负面印象可能会形成你的轨道。

Answer 7

如果它是单个（或有限的）内存泄漏，并且它没有增长，并且说它只会在关闭时导致崩溃（这种情况最常见的情况），那么它取决于。如果它的客户端/桌面软件和用户每次出门都会崩溃，我会把它作为一个超高优先级。如果它的服务器，并且唯一一个运行服务器的服务器就是你，而其他一切正常，我会说它可以进入测试阶段。但如果泄漏增加，或者可能导致“随机”时间崩溃，则需要尽快修复。

Answer 8

要想通过一个内部里程碑，这是有争议的，尽管仍然无法采取任何措施。

要发布，永远不要。它总会回来咬你。如果你的软件处于如此糟糕的空间，以至于一块糟糕的设计会让它越过界限，那么你就会出现很多更大的问题

Answer 9

从不，除非您不关心那些将在以后维护您的工作的可怜开发人员。

Answer 10

最终，这样的决定应该由客户或项目经理做出。个别开发者不应单独做出这些决定，也不应将这些信息留给自己。

告诉他们问题是什么，以及解决问题的后果是什么。如果他们希望你按时发货，那就是他们的电话。

如果你不想为那些接受伪劣产品的人工作，那就是你的号召，但认为开发商有某种职业责任忽视他们的客户和老板的质量/成本/时间优先级是错误的

如果你运送不良软件可能会导致某人死亡，那么就不要这样做，但如果最糟糕的情况是某人每天必须重新启动几次，那就按照你所说的去做吧或找另一份工作。