Language agnostic 如何阻止临时解决方案永远持续下去？

假设一个问题有两种可能的解决方案：第一种是快速但不易处理的；第二种方法更可取，但需要更长的时间才能实现。你需要快速解决这个问题，所以你决定尽快解决这个问题，然后计划开始更好的解决方案。问题是，一旦问题得到缓解，它就会在待办事项清单上直线下降。您仍计划在某个时候采用更好的解决方案，但现在很难证明实施它是合理的。突然间，你发现自己花了五年时间使用了这个不太完美的解决方案，一边诅咒它

---

这听起来熟悉吗？我知道这在我工作的地方不止一次发生过。一位同事描述说，他故意制作了一个糟糕的GUI，这样它就不会被意外地长期采用。你有更好的策略吗？

这是在完成期限驱动的工作时的一个主要问题。我发现添加关于为什么选择这种方式的非常详细的注释和一些关于如何编码的提示会有所帮助。通过这种方式，人们可以看到代码并保持其新鲜

---

另一个可行的选择是在跟踪框架中添加一个bug.feature（您确实有一个，对吗？）来详细说明返工。通过这种方式，它是可见的，并且可能会在某个时候强制解决问题。

这是一个艰难的决定。我个人曾做过黑客行为，有时你必须将产品推出门外，送到客户手中。然而，我处理这件事的方法就是去做

---

告诉项目负责人、老板或客户：有一些地方需要清理，并进行更好的编码。我需要一周的时间来做这件事，而现在做这件事的成本会更低，那么6个月后就可以做了，当我们需要在子系统上实现扩展时。

• 我确保我能说出长期解决方案的优先顺序，尤其是在短期解决方案实施之后。
• 我详细说明了为什么这是一个黑客攻击，而不是一个好的长期解决方案，并使用这些解决方案获得利益相关者（经理、客户等）为了理解为什么需要根据具体情况进行修复，我甚至可能会在其中注入一些最坏情况下的恐惧。“如果这条线路安全断开，整座桥可能会倒塌！”
• 我负责提出一个长期解决方案，并确保它得到部署。
策略1（几乎从未选择）：不要实施kluge。甚至不要让别人知道这是可能的。第一次就用正确的方法去做。正如我所说，由于时间限制，这一个几乎从未被选中
策略2（不诚实）：撒谎和欺骗。告诉管理层黑客程序中存在漏洞，这些漏洞可能会在以后造成重大问题。不幸的是，大多数时候，管理者只是说等到bug成为问题，然后修复bug
策略2a：与策略2相同，只是确实存在bug。同样的问题
策略3（也是我个人最喜欢的）：尽可能地设计解决方案，并且做得足够好，让实习生或代码猴子都能做到。比起证明你自己的薪水，证明花了一小笔代码猴子的钱更容易，所以它可能就这样完成了

---

策略4：等待重写。继续等待。迟早（可能是晚些时候），有人将不得不重写这件事。最好马上做。
像这样的问题通常是由于与管理层或客户沟通不畅而引起的。如果解决方案对客户有效，那么他们认为没有理由要求对其进行更改。因此，他们需要事先了解您所做的权衡，以便在您实施快速解决方案后，他们可以计划额外的时间来解决问题
如何解决这个问题在一定程度上取决于为什么它是一个糟糕的解决方案。如果您的解决方案不好，因为很难更改或维护，那么第一次您必须进行维护并有更多的时间，那么这就是升级到更好的解决方案的正确时间。在这种情况下，如果你告诉客户或老板你一开始就走了捷径，这会有所帮助。这样他们就知道，他们不能指望下一次会有一个快速的解决方案。修改用户界面是确保客户回来修理东西的好方法

---

如果解决方案不好，因为它有风险或不稳定，那么你真的需要和做计划的人谈谈，并计划一些时间尽快解决问题。
好问题。这也让我很烦恼——大多数时候，我是唯一一个负责在我自己的项目中优先处理问题的人（是的，小企业）
我发现需要解决的问题通常只是问题的一个子集。注意，需要紧急修复的客户不需要解决整个问题，只需要解决问题的一部分——无论是小问题还是大问题。这有时使我能够创建一个解决方案，它不是解决整个问题的解决方案，而只是解决客户的子集，并允许我在问题跟踪程序中保留更大的问题

---

当然，这可能根本不适用于您的工作环境：（
您不需要临时解决方案
有时我认为程序员只需要被告知这一点
对此很抱歉，但说真的——一个黑客解决方案是毫无价值的，即使在第一次迭代中，也要比正确地完成部分解决方案花费更长的时间
请不要把你的垃圾代码留给我维护。只要把它编对就行了。不管花多长时间，不管是谁对你大喊大叫
当你在提前交付后坐在那里玩弄你的大拇指，而其他人都在调试他们愚蠢的黑客时，你会感谢我的
即使你不认为自己是一名优秀的程序员，也要尽力做到最好，永远不要走捷径——做对这件事不会花费你任何时间。如果你不相信我，我可以为这句话辩护
突然你变了

// TODO: Better solution required.