有许多不同的不良做法，例如内存泄漏，很容易在意外中滑入程序中。有时，他们甚至可以一起陪审你的程序。
我现在正在做一个项目，如果我故意在我的代码中放置内存泄漏，它就会起作用。如果我把泄漏出来，代码就会崩溃。显然这很糟糕，需要（并且将会）尽快修复。
我的问题是，如果没有这些不良做法就无法及时发布代码，那么您什么时候决定在这种状态下交付代码？
samoz
问问题
359 次
10 回答
7
如果可以合理预期该问题对系统实际使用的影响不会或可以忽略不计，并且交付日期不能推迟，并且可以在问题影响变得可以忽略不计之前的时间范围内修复，则发货.
显然，这并不理想，甚至不推荐，但此时您显然被推到了一个角落。有时没有好的选择，但实用主义必须战胜形式上的正确性。如果应用程序发生内存泄漏，但我们可以合理地预期应用程序将被回收或机器重新启动或在泄漏成为真正问题之前发生的任何事情，有时这比延迟交付要好。这取决于协议的条件和客户。
至少尝试推迟交货日期总是更好，但我假设您已经尝试过，这不是一个选择。
应用程序交付后通常会忽略技术债务并继续前进。开发人员有责任向利益相关者清楚地传达偿还部分债务的重要性，尤其是在这种情况下。
然而，鉴于客户似乎更关心交货日期而不是正确性，一旦你上线，任何人都不太可能被说服偿还任何债务。这是一个糟糕的情况。只有掌握所有事实的人才能做出正确的选择。
于 2009-03-16T01:11:00.963 回答
6
“我的问题是，如果没有这些不良做法就无法及时发布代码，你什么时候决定在这种状态下交付代码？”
绝不。
相反，你要做的是：优先考虑和专注。
如果你的工作是真正的高优先级，而你设计错误，那么就必须牺牲一些低优先级的东西。通常，必须延迟某些功能，以便让您有时间专注于不起作用的高优先级功能。
如果你正在做的事情真的是低优先级的，你必须问为什么你不做更高优先级的事情。而且您仍然必须集中精力并确定优先级。有时必须牺牲优先级很低的东西。
当你不能做“所有事情”时，你必须选择你可以做的事情，这将是合理的无错误的。
于 2009-03-16T01:23:22.027 回答
2
您可能对技术债务的概念感兴趣。
于 2009-03-16T01:13:56.370 回答
2
假设开发人员数量固定：功能、质量和发布日期，在发布软件时你只能转动三个旋钮，打开一个意味着其他的被拒绝。
软件开发中最困难的事情之一就是在构建您的产品时，旋钮设置得恰到好处。例如，永远的毁灭公爵（Duke Nukem Forever）将功能和质量旋钮调到 11 位，并将发货日期旋钮扔出窗外。微软似乎经常将发货日期旋钮粘在适当的位置并根据需要调低功能旋钮，然后解开发货日期旋钮，将其向上转动一点，将其粘回并继续旋转另外两个。似乎有无穷无尽的产品一直在发布，但从未加入成功所需的功能。
最后，如果你不交付，你就不会得到报酬。从长远来看，质量差会严重伤害你；声誉很难重建。几乎总是正确的做法是在有太多错误的情况下削减功能。总是。
但是，错误分类与功能开发一样重要。我们在这里谈论什么样的泄漏？你在泄漏一个字节吗？一个小物件？一千个物体？整个DLL？在某些情况下，泄漏一点可能比未能交付产品更好。
你说的泄漏是什么意思？您的应用程序是否有明确定义的生命周期？您在启动时分配一次然后在进程终止之前永远不会释放它的地方？那么您的流程运行多长时间？您是否希望运行您的流程的多个副本？
显然，您永远不想泄漏，您应该努力开发将泄漏降至最低的最佳实践，但最终您必须做出判断。也许您可以向您的客户解释错误，解释影响，他们无论如何都会购买。也许你可以在一周后修补它。也许你真的需要修复它。但我们需要更多地了解它才能给出好的建议。
我会说我过去曾运送过已知的泄漏。我不会说什么产品或公司，但我有一个错误，即 DLL 依赖项和疯狂的生命周期管理使得我们几乎不可能在加载后正确释放对某个 DLL 的引用，所以最后我们只是泄露了它。而且我仍然认为这是正确的做法。其他时候，我看到故意泄露的东西是为了防止错误编写的第三方代码崩溃（尽管这是一个完全独立的争论）。
但最后我相信这种情况很少见，一旦你确定了内存泄漏的来源，修复它应该不会超过一天。实际上，我很少会附带已知的内存泄漏和已知的修复程序。它必须是需要进行重大重新架构的事情，涉及更改线程模型或重构大量代码，并且实际上必须在一两天后才能发布产品。那时我可能只是泄漏内存并承诺在对重新架构师进行适当测试后会在弱中提供补丁。
于 2009-03-16T01:40:27.927 回答
1
于 2009-03-16T01:14:06.917 回答
1
也许，当您以后不打算维护代码时，您就不会关心您的客户/雇主，并且您的代码的任何后果都不会影响您。
换句话说，在你的职业编码生涯中，这从来都不是一个好主意。
如果您为比您更不关心代码质量的人工作，并且只是希望您不惜一切代价完成代码，那么我可以看到您将处于困境中。完成得更快但更差会让你立即获得奖励。您应该记住，即使未能满足您的雇主/客户对里程碑的期望只咬了你一次，你糟糕的代码可能会继续咬你到未来，不仅因为维护它的困难，还因为其他人的负面印象可能会形成你的轨道。
于 2009-03-16T01:36:17.453 回答
0
如果它是一个单一的（或有限的）内存泄漏，并且它没有增长，并且说它只会在关闭时导致崩溃（这种情况最常见的情况），那么它取决于。如果它是一个客户端/桌面软件，并且用户每次出去时都会崩溃，我会把它作为一个超高优先级。如果它的服务器，并且唯一运行该服务器的是您，并且其他一切正常，我会说可以进入测试版。但是，如果泄漏增加，或者可能在“随机”时间导致崩溃，则需要尽快修复。
于 2009-03-16T01:15:24.027 回答
0
为了超越一个内部里程碑，这是有争议的，尽管仍然没有什么可采取的。
释放，永远。它总是回来咬你。如果您的软件处于如此糟糕的空间中，以至于一个糟糕的设计将使其超出界限，那么您将面临更大的问题
于 2009-03-16T09:53:17.103 回答
0
永远不要，除非你不关心那些将在之后维护你工作的可怜的开发人员。
于 2009-03-17T21:20:57.733 回答
0
最终，这样的决定应该由客户或项目经理做出。个人开发人员不应单独做出此类决定，或将这些信息保密。
告诉他们问题是什么，以及不解决问题的后果是什么。如果他们希望您按时运送损坏的产品，那是他们的决定。
如果你不想为接受劣质产品的人工作，那是你的决定，但认为开发人员有某种职业责任忽视他们的客户和老板的质量/成本/时间优先级是错误的。
如果你发布了糟糕的软件，有人可能真的死了，那么不要这样做，但如果最坏的情况是有人每天必须重新启动几次，那么按照你的指示去做或找到另一个工作。
于 2010-08-07T19:09:05.223 回答