何时是正确的时间和错误的时间来做快速和肮脏的解决方案？

Question

何时是正确的时间，什么时候采取快速和肮脏的方法与适当的优雅解决方案是错误的时间？

这是从我对我的问题的评论开始的：Decode Base64 data in Java。

我想要一种只使用内部Java或我写的东西的方法。唯一内置的方法是使用不受支持的sun。*包。那么什么时候才是正确的时间，何时采取这种方法是错误的时间呢？

Answer 1

在我看来，使用快速而肮脏的解决方案（又称黑客）的唯一“正确时间”是...

1. 有一个任务关键型错误需要立即修复，正确的解决方案实现起来非常复杂。
2. 这是一个内部应用程序，一些高层需要实现快速功能（嘿，您和您的客户都不会使用它）。

Answer 2

在任何情况下，您都必须平衡解决问题所花费的时间，然后平衡维护该解决方案所花费的时间。如果你所做的任何事情的生命周期都很长，那么预先花费的额外时间以正确的方式做事可能会更容易维护，并且从长远来看会节省你的时间。

但是，如果有时间限制，过度处罚可能远远超过维护成本。例如，如果您必须将产品推出市场，请立即执行快速解决方案，然后将其记录为错误，以便稍后在修补程序或下一版本中修复。这将需要你重新完成工作，但就像我说的那样，这都是一种平衡行为，并且往往是由成本驱动的。

Answer 3

正确的答案是永远不会时间来做快速而肮脏的解决方案。 但有时候（当有一个庞大的客户群和大量的程序时）最好发布一个Q＆amp; D的修复程序可能会打破一些东西，但是确保修复更多。

我不知道我是否理解这个问题，但我会留下这个问题。

Answer 4

如果存在一个简单但不太优雅的解决方案，与代码库中其他地方使用的风格和技术非常匹配（因此，您的同事更容易理解），那么采取这种方式可能更安全 - 与从学术角度来看，这个解决方案是完美的，但如果您从未碰巧阅读过该特定论文，则难以理解。

同样，一个小的变化可能比优雅的解决方案基本上需要的重大重构努力更安全。这在任何缺乏单元测试的世界中尤为重要。

Answer 5

如果项目是“概念证明”工作而不是生产实施，那么可能是一个快速而肮脏的解决方案的合适时机，它可以完成工作，说明某个系统的特定部分是多么容易或困难。我在想一个人可能想要测试一个新的ERP或CRM系统的地方，只是想看看它的机制，而不需要花费大量的时间和金钱来获得更真实的原型。

在大多数其他情况下，这是一个权衡问题。有多少缺陷会被释放到野外？只是没有showstoppers错误确定或是否只有少数只剩下一些小的或化妆品错误。如果某些项目经理或业务部门想要快速但不一定完全正常工作，那么如果那些要求了解风险的话，快速而肮脏的解决方案可能会起作用。在某种程度上，这就像在做出诊断之前医生应该进行多少次检查的问题：你是否应该通过各种不同的能量波从头到脚进行检查，例如： X射线，CT扫描，MRI等。或者医生可以看看你在做什么，并知道House博士不时会做出什么错误。

Answer 6

在我看来，由于业务规则的突然变化（而不是说虽然没有发生！），但由于缺乏规划而更加经常需要快速和肮脏的解决方案。任何人都没有得到适当的工具来完成他们的工作，有人大大低估了某些事情需要花费的时间，或者有人过于依赖过于复杂的功能。在大多数情况下，最好推迟发布或缩减发布中的功能。

如果 必须由您无法控制的业务优先级（例如法律问题），那么您需要尽快将其发布出去。但是你应该为下一个版本更好地修复它！

Answer 7

现在是时候使用快速而肮脏的解决方案了：

• 您需要快速解决方案（假设不存在大致相同的专业解决方案）和
• 你不会因为它变脏而受到影响。

在某些方面，这是一个轻率的答案，但确实涵盖了它。

在您的情况下，您无法快速引入新库。而且您确实有一个流程可以降低使用实验代码的风险。只要该流程可靠，并且您确信生产代码不包含您的快速和肮脏的解决方案，然后继续。

一旦我的公司努力让一些代码在贸易展上为演示工作。他们的时间不多了，演示只有一天之后。我建议他们硬编码一些选项，而不是让它们可配置和动态。

它奏效了 - 他们在第二天的节目中运行了演示。然后，当他们回到办公室时，他们立即删除了硬编码部分并完成了他们的功能。

如果你可以依赖于更换快速＆amp;肮脏的黑客是最优先的，然后快速＆amp;脏可以是合适的。它很少是最重要的，使用这个解决方案通常是一个坏主意。

Answer 8

正如tj111和其他人所指出的，有时优雅解决方案的风险大于快速和肮脏的风险。即，你提供了一些美丽的东西，但到那时客户不再需要它，想要不同的东西，或者生气。

可以肯定的是，做一个快速而肮脏的解决方案总会带来长期成本，而且必须为管理层提供一个坚定而有力的“道路”。此外，快速和肮脏变得像管理层经常不知道或不关心优雅与肮脏之间的区别（特别是当它在引擎盖下时）。直到事情开始变得地狱，即使这样，固定压力也会被释放到倒霉的（通常是新的）技术团队。

所以是的，有时你必须这样做是因为美元和时间的考虑，但不要掩盖或忘记它，努力并在危机消退时尽快重新考虑因素。

Answer 9

记住很多应用程序都是基于他们的原型构建的。

我们总是想要抛弃它的代码。但它会增长！

Answer 10

在我的案例中，我在研发部门工作，在添加外部库时我们有一个很长的流程来获得批准。

如果代码被标记为实验代码，则会在转移到生产之前进行清理。我需要这个来进行快速实验，看看是否有什么东西对我们来说是有意义的，并且需要快速进行数据处理。所以快速而肮脏的方法是尽快完成工作的正确方法。如果我们决定进行实验，我将有时间正确更换功能。

在标准情况下，kdgregory将其放在一个答案的评论中：

  

Bzzt。在专业的环境中，   使用不受支持的，未记录的   功能永远不是正确的决定。   在企业环境中，   “实验”成为“生产代码”   没有机会修复黑客攻击。

我认为他是正确的，当你在一个甚至怀疑它可能投入生产的位置工作时，这不是合适的方法。唯一的例外是，如果你没有时间进行适当的修复，但可以在一些可见的公共场所（bug跟踪器）将其标记为高优先级问题，并且肯定能够在将来的版本中修复它。

Answer 11

有时，快速而肮脏的解决方案与无法维护的解决方案同义。其他时候它只是意味着解决你实际拥有的（简单）问题，而不是解决那个问题的（更复杂的）概括。我是一名从事生物信息学研究的研究生，我经常需要编写一些小程序来做简单的事情，比如重新格式化或总结几百兆的数据。偶尔我需要写一些每天的应用程序。如果我为这些写了“正确的”解决方案，我就永远不会做任何事情。

解决一般情况（不是快速和肮脏）意味着制作一个应用程序可以强有力地处理错误，可供我以外的人使用，可配置等等。这将解决许多我没有的问题。我可能是唯一一个会使用这些程序的人。我需要的所有可配置性是一些命令行选项和根据需要编辑源文件的能力。我需要的所有错误处理都是显示一个不错的错误信息，并在出现问题时退出。

当然，有时这些程序会变得更重要，有时我最终会重用它们的代码。可维护性很重要。即使在快速而肮脏的解决方案中，幻数不应该是硬编码的，变量不应该被命名为“foo”，“bar”和“stuff”，并且程序不应该被写成一个巨大的400行{{1}功能。我学到了很多东西。

Answer 12

有时你必须以Q＆amp; D方式做事。在这种情况下，您需要做的是通过将脏实现隐藏在接口或适配器后面来保护自己。

要使用引用的示例，Sun. *包现在可以使用，但将来可能不会。精细。然后将其包装在实现所需接口的适配器中。然后，当Sun更改API（希望提供类似Java.BASE64的永久性）时，您可以快速更新您的实现以应对更改。

Answer 13

当满足三个条件时，我会做一个快速而又脏的修复：

• 没有足够的时间来做出正确的解决方案
• 修复及其范围清晰且包含在内（很容易返回，知道解决了哪些修补程序，可以轻松删除并替换为正确的实现）
• 修复是原子的还是没有依赖性

Answer 14

“Quick and Dirty”，通常是“廉价但实际上有效”的代名词，这通常是完成工作所需的全部内容。如果有人批评你的代码，那么最好的辩护就是说“是的 - 这只是一个快速而肮脏的解决方案”。这样，你的编码员同事可以感觉优于你，而你尖尖的老板看着，默默地批准他的下巴。