说一个问题有两种可能的解决方案：第一种是快速但笨拙的。第二种是可取的，但实施起来将需要更长的时间。您需要快速解决问题，因此您决定尽快解决该问题，并计划在以后开始研究更好的解决方案。问题是，一旦问题得到缓解，它就会急剧下降到待办事项清单中。您仍然计划在某个时候提供更好的解决方案，但是很难证明现在就实施它是合理的。突然之间，您发现使用了效果不理想的解决方案已经花费了五年时间，并且诅咒了一段时间。
这听起来很熟悉吗？我知道在我工作的地方不止一次。一位同事描述，故意制作不良的GUI，以便长期使用它不会偶然。您有更好的策略吗？
Answers:
编写一个测试案例，说明黑客失败。
如果您无法编写一个测试失败的测试，那么说明该黑客毕竟没有问题，或者您的测试框架不够完善。如果是前者，请先逃之on，然后再浪费不必要的优化工作。如果是后者，则寻求另一种方法（标记黑客或测试...）
策略1（几乎从未选择过）：不要实施合并。甚至不要让人们知道这是可能的。第一次就用正确的方法做。就像我说的那样，由于时间限制，几乎从未选择过此选项。
策略2（不诚实）：说谎和欺骗。告诉管理人员黑客中存在错误，以后可能会引起重大问题。不幸的是，在大多数情况下，管理人员只是说要等到漏洞成为问题之后再修复漏洞。
策略2a：与策略2相同，但确实存在错误。同样的问题。
策略3（以及我个人最喜欢的策略）：尽可能设计解决方案，并做得很好，以至于实习生或代码猴子都可以做到。证明花少量代码猴子钱比证明自己的薪水要容易，因此它可能就完成了。
策略4：等待重写。继续等待。迟早（可能稍后），某人将不得不重写该东西。那时也可以这样做。
在进行截止日期驱动的工作时，这是一个主要问题。我发现添加了关于为什么选择这种方式的非常详细的注释，以及一些有关如何进行编码的提示。这样，人们在查看代码时就可以看到并保持最新。
另一个可行的选择是在跟踪框架中添加一个bug.feature（您确实有一个吧，对不对？），详细说明返工。这样一来，它就可见了，并且可能会在某个时候强制问题。
唯一可以证明修复这些问题的理由（因为它们并没有真正损坏，只是丑陋）是在您拥有涉及相同代码部分的另一功能或错误修复时，您不妨重新编写它们。
您必须对开发人员的时间成本进行数学计算。如果满足软件需求，并且唯一的错误是代码在幕后令人尴尬，那么就不值得修复。
整个公司都可能倒闭，因为过分热心的工程师每年都会在遇到麻烦时坚持进行重新架构。
如果它没有错误，并且满足要求，那就完成了。装运它。继续。
[编辑]
当然，我并不是要提倡所有时间都被黑客入侵。您必须在开发过程的正常过程中仔细设计和编写代码。但是，当您遇到需要快速完成的黑客攻击时，您必须进行成本效益分析，以了解清理代码是否值得。如果在应用程序的整个生命周期内，您花费在纠缠的hack上的编码时间要多于修复该代码的时间，那么当然要修复它。但是，如果不是这样的话，仅仅因为查看源代码会使您感到不适，重新编码一个可以正常运行的，没有错误的应用程序将非常昂贵且冒险。
您不做临时解决方案。
有时我认为程序员只需要被告知这一点。
对此感到抱歉，但很严重-hacky解决方案毫无价值，即使在第一次迭代时，也可能比正确完成一部分解决方案花费的时间更长。
请不要再给我留下您的废话代码来维护。只要总是正确就可以了。无论花多长时间，谁会对你大吼大叫。
当您坐在那里，在其他人调试他们的愚蠢骇客的早期交付后，不停地抽签，您会感谢我的。
即使您不认为自己是一个优秀的程序员，也要始终努力做到最好，绝不要走捷径-这样做不会花费您任何时间。如果您不相信我，我可以证明这一说法是正确的。
这是很难的。我个人做过一些骇客活动，有时您不得不将产品推销到客户手中。但是，我照顾它的方法就是做到这一点。
告诉项目负责人，您的老板或客户：有一些地方需要清理，并进行更好的编码。我需要一个星期的时间来做，现在要花更少的钱，然后从现在起六个月后，当我们需要在子系统上实现扩展时。
通常，此类问题是由于与管理层或客户的沟通不畅而引起的。如果该解决方案适用于客户，则他们认为没有理由要求对其进行更改。因此，需要事先告知他们要进行的权衡，以便他们可以在计划了快速解决方案之后计划额外的时间来解决问题。
如何解决它取决于它为什么是一个不好的解决方案。如果您的解决方案不好，因为很难更改或维护，那么第一次您必须进行维护并且有更多时间，那么这是升级到更好解决方案的正确时机。在这种情况下，如果您告诉客户或老板您首先选择了一条捷径，将很有帮助。这样，他们知道他们不能期望下一次快速解决方案。弄乱用户界面是确保客户回来修复问题的好方法。
如果由于风险或不稳定而导致解决方案不好，那么您确实需要与进行规划的人员交谈，并计划一些时间来尽快解决问题。
祝好运。以我的经验，这几乎是不可能实现的。
一旦由于压力而走上了实施骇客的湿滑之路，那么您很可能会习惯于一直生活。无论内部实施多么糟糕，几乎都没有足够的时间来对已经可以工作的东西进行重新设计。是什么让您认为您会“在以后的某个时间”神奇地拥有更多时间来修复该hack？
我能想到的唯一例外是，黑客是否完全阻止您实施客户所需的另一项功能。然后，您别无选择，只能进行返工。
我尝试构建该hacky解决方案，以便可以尽可能轻松地将其长期迁移。假设您有一个正在SQL Server cuz中建立数据库的家伙，这是他最强大的数据库，但是您的公司标准是Oracle。使用尽可能少的不可转让功能（例如Bit数据类型）构建数据库。在此示例中，不难避免使用位类型，但是这使以后的转换更加容易。
教育负责最终决策的人，从长远来看，为什么这种行事方式不好是坏事。
基本上，不了解软件的人不会重新审视已经起作用的事物。从他们的角度来看，开发人员就像是机械师，他们希望每次有人想要添加功能时都要拆开并重新组装整个汽车，这听起来很疯狂。
它有助于对日常事物进行类比。向他们解释，当您制作临时解决方案时，如何做出适合快速构建而不是稳定，可维护等的选择。这就像选择使用木头而不是钢材来构建，因为木头更容易切割，因此，您可以更快地构建临时解决方案。但是，木材根本无法支撑20层建筑的基础。
这使我想起了“ CTool”的故事。最初，我们的一位开发人员提出了CTool，我称他为Don，这是解决我们遇到的问题的一种可能方法。作为认真工作的类型，唐插入了电源并交付了工作原型。你知道我要去哪里。一夜之间，CTool成为了整个公司部门工作的一部分。在第二天或第三天，关于CTool缺点的抱怨开始泛滥。用户质疑唐的能力，承诺和智商。Don的抗议从未被认为是生产应用程序，对此置若de闻。这持续了多年。最终，在Don离开后很久就有人来重写应用程序。到了这个时候，名称CTool变得非常讨厌，以至于无法命名为CTool version 2。甚至为CTool举行了一场正式的葬礼，有点让人想起Office Space中的复印机（或者它是打印机？）执行现场。
有人可能会说唐不配吊索和箭，因为它不能正确地修复CTool。我唯一的一点是，说你应该永远砍出一个解决方案可能是真实世界中不合理的。但是，如果您是这样做的人，请谨慎行事。
您针对自己的“修复”提交了第二个非常有描述性的错误，并在受影响的区域中添加了待办事项注释，其中说：“该区域需要大量工作。请参见缺陷＃555”（当然请使用正确的数字） 。那些说“别客气”的人似乎并不理解这个问题。假设您有一个现在需要启动并运行的系统，您的非骇客解决方案需要8天的工作时间，您的骇客需要38分钟的工作时间，这种骇客可以让您有时间进行工作，而不会因此而亏钱你在做。
现在，您仍然必须让您的客户或管理层同意，除了现在需要修复的N分钟外，还安排N * 100分钟来进行真正的修复。如果您必须在达成这样的协议之前拒绝实施hack，那么也许这就是您必须要做的，但是我在这方面与一些了解的人一起工作。
引入快速修复的实际价格是，当其他人需要引入第二快速修复时，他们将根据您自己的快速修复进行介绍。因此，快速修复的时间越长，它就越牢固。通常，骇客只比做正确的事情花一点时间，直到遇到第二个以第一个为基础的骇客为止。
因此，显然有时（或似乎是）有时需要引入快速修复。
假设您的版本控制支持它，一种可能的解决方案是每当您进行此类黑客攻击时，从源头引入一个fork。如果鼓励人们避免在这些特殊的“完成任务”分支中编写新功能，那么与将新功能与分支进行集成相比，最终的工作要比摆脱黑手多。但是，“好”叉子更有可能被丢弃。而且，如果您离发行版还有足够的距离，那么制作这样的fork将不切实际（因为不值得进行上述的双重集成），那么您可能甚至不应该使用hack。
一种非常理想的方法。
一个更现实的解决方案是将您的程序分成尽可能多的正交组件，并偶尔完全重写某些组件。
一个更好的问题是，为什么hacky解决方案不好。如果由于降低灵活性而不好，请忽略它，直到需要灵活性为止。如果由于影响程序行为而造成不良影响，请忽略它，最终它将成为一个错误修复程序并将得到解决。如果由于外观难看而不好，只要将hack本地化即可将其忽略。
我过去见过的一些解决方案：
HACK在代码中用注释标记（或类似的方案，例如XXX）HACK评论出现的次数这是一个很好的问题。随着越来越多的经验，我注意到的一件事：骇客为您节省了很短的时间，并且常常使您付出更多。紧密相关的是“快速修复”，可以解决您认为的问题-只是在发现问题根本不是问题时才发现。
撇开是否应该这样做的争论，让我们假设您必须这样做。现在的诀窍是以使远程影响最小化的方式进行操作，以后很容易将其删除，并使其自身成为麻烦，因此您记得要对其进行修复。
令人讨厌的部分很容易：每次执行kudge时都发出警告。
撕开的部分很容易：我喜欢这样做，是将kudget放在子例程名称的后面。由于您划分了代码，因此更新起来更容易。当您获得永久性解决方案时，您可以在子例程中实施该解决方案，也可以成为无操作人员。有时，子类也可以很好地工作。但是，不要让其他人依赖您的快速解决方案。不看情况就很难推荐任何特定的技术。
如果代码的其余部分很好，则最小化远程影响应该很容易。始终通过发布的界面，依此类推。
自白：
为了从其他代码层读取数据，我在C ++中使用了'#define private public'。它以hack的形式出现，但效果很好，而且修复它从来都不是优先事项。现在是3年后...
无法删除黑客的主要原因之一是在修复黑客时引入新错误的风险。（特别是在处理TDD之前的代码库时。）