Coding style 什么时候是正确的时间，什么时候是错误的时间来做快速和肮脏的解决方案？

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

这是从对我的问题的评论开始的：

---

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

在任何情况下，你都必须平衡用于解决问题的时间，然后平衡用于维护解决方案的时间。如果你所做的任何事情的生命周期都是漫长的，那么预先花在以正确的方式做事情上的额外时间大概会更容易维持，并且从长远来看会拯救你

---

但是，如果存在时间限制，则翻修的罚款可能远远超过维护成本。例如，如果您必须将某个产品推出，请立即执行一个快速而肮脏的解决方案，然后将其作为bug记录，以便稍后在修补程序或下一版本中进行修复。这需要你重新做这项工作，但正如我所说，这完全是一种平衡行为，而且往往是由成本驱动的。正确的答案是，现在决不是做快速而肮脏的解决方案的时候。 但有时（当有一个大的客户库和大量的程序在那里时）更好的是用一个Q&D来发布一个修复，它可能会破坏一些东西，但肯定会修复更多

---

我不知道我是否正确理解了这个问题，但我将把它放在这里。

就我而言，我在一个研发岗位上工作，在添加外部库时，我们需要一个漫长的审批过程

若代码被标记为实验性的，那个么将在转移到生产之前对其进行清理。我需要这个来做一个快速的实验，看看有些东西对我们来说是否有意义，是否需要快速处理数据。因此，快速而肮脏的方法是尽快完成任务的正确方法。如果我们决定进行实验，我将有时间适当地替换功能

在标准情况下，正如kdgregory在一个答案的评论中所说：

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

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

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

有一个任务关键的bug需要立即修复，而正确的解决方案实施起来非常复杂

这是一个内部应用程序，一些高层需要实现一个快速功能（嘿，你和你的客户都不使用它）

---

有时候你不得不用Q&D的方式做事。在这种情况下，您需要做的是通过将脏的实现隐藏在接口或适配器后面来保护自己

---

举一个例子，Sun.*包目前可以工作，但将来可能不会。好的然后将其封装在实现所需接口的适配器中。然后，当Sun更改API时（希望提供像Java.BASE64这样的永久性解决方案），您可以快速更新您的实现以应对更改。

在以下情况下，使用快速而肮脏的解决方案是正确的：

• 您需要快速的解决方案（假设不存在类似的专业解决方案），并且
• 你不会因为它脏而承担后果

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

在您的情况下，您无法快速引入新库。您确实有一个过程来降低使用实验代码的风险。只要这个过程是可靠的，并且您确信生产代码不会包含您的快速脏的解决方案，那么就继续吧

有一次，我的公司在一个贸易展上为一个演示程序努力获取一些代码。他们没时间了，离演示只有一天了。我建议他们硬编码一些选项，而不是使其可配置和动态

它起作用了——他们为第二天的节目做了演示。然后，当他们回到办公室，他们立即删除硬编码的部分，并完成其功能

---

如果你可以依靠替换快速和肮脏的黑客作为首要任务，那么快速和肮脏是合适的。在这种情况下，使用此解决方案通常是一个坏主意，这是非常罕见的。当满足以下三个条件时，我会快速地进行修复：

• 没有足够的时间来做适当的解决方案
• 修复程序及其范围是明确和包含的（很容易返回，知道修复程序解决了什么问题，可以很容易地删除，并由适当的实现替换）
• 修复是原子的或没有依赖项

---

“又快又脏”通常是“便宜又有效”的同义词，这通常是完成工作所需的全部。如果有人批评你的代码，最好的辩护就是说“是的，这只是一个快速而肮脏的解决方案”。这样，你的程序员同事会觉得比你高人一等，而你的头发尖尖的老板则在一旁看着你，默许地揉着下巴。

如果存在一个简单但不那么优雅的解决方案，它与代码库中其他地方使用的风格和技术非常匹配（因此，同事更容易理解），服用该药可能更安全