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

编写一个黑客失败的测试用例。

策略1(几乎从未选择):不要执行kluge。甚至不要让别人知道这是可能的。第一次就用正确的方法去做。正如我所说,由于时间限制,这一个几乎从未被选中。

策略2(不诚实):撒谎和欺骗。告诉管理层黑客程序中存在漏洞,这些漏洞可能会在以后造成重大问题。不幸的是,大多数时候,管理者只是说等到bug成为问题,然后修复bug。

策略2a:与策略2相同,只是确实存在bug。同样的问题。

策略4:等待重写。继续等待。迟早(可能是晚些时候),有人将不得不重写这件事。那最好马上做。

下面是一篇关于 technical debt .

最糟糕的债务是类似于信用卡债务的小额债务。。。每个人都不会受伤,但很快你就进入了贫困家庭。

另一个可行的选择是在跟踪框架中添加一个bug.feature(您确实有一个,对吗?)来详细说明返工。这样,它是可见的,并可能在某个时候迫使问题。

您必须计算开发人员的时间成本。如果软件需求得到满足,唯一的错误就是代码在幕后令人尴尬,那么它就不值得修复。

整个公司都可能倒闭,因为过于热心的工程师们在感到不安时,坚持每年左右都要重新设计一次架构。

如果它没有bug并且满足要求,那么就完成了。发货。继续前进。

[编辑]

仅仅因为看源代码就会让你生病。

你不需要临时解决方案。

有时我认为程序员只需要被告知这一点。

对此很抱歉,但说真的——一个黑客解决方案是毫无价值的,即使在第一次迭代中,也要比正确地完成部分解决方案花费更长的时间。

请不要把你的垃圾代码留给我维护。只要总是把代码写对。不管花多长时间,不管谁对你大喊大叫。

即使你不认为自己是一名优秀的程序员,也要尽力做到最好,永远不要走捷径——正确的做法不会花费你任何时间。如果你不相信我,我可以为这句话辩护。

如果你在诅咒它,为什么它在待办事项列表的底部?

• 如果它正在影响你,那么这是一个现在需要解决的问题。

• 我要确保我能直言不讳地说出长期解决方案的优先顺序,尤其是在短期解决方案实施之后。
• 视情况而定,我甚至可能会在其中注入一些最坏情况下的恐惧。“如果这条安全线断裂,整座桥都可能倒塌!”
• 我负责提出一个长期的解决方案,并确保它得到部署

这是一个艰难的决定。我个人做过黑客,有时是因为你 有

像这样的问题通常是由于与管理层或客户沟通不畅而引起的。如果解决方案对客户有效,那么他们认为没有理由要求对其进行更改。因此,他们需要事先了解您所做的权衡,以便在您实施快速解决方案后,他们可以计划额外的时间来解决问题。

如果解决方案不好,因为它有风险或不稳定,那么你真的需要和做计划的人谈谈,并计划一些时间尽快解决问题。

祝你好运根据我的经验,这几乎是不可能实现的。

我能想到的唯一例外是,如果黑客完全阻止您实现客户所需的另一项功能。那你别无选择,只能重新做工。

教育那些负责做出最终决定的人,从长远来看,为什么黑客的做事方式是不好的。

• technical debt .

基本上,不懂软件的人不会有重温已经起作用的东西的概念。从他们的角度来看,开发人员就像机械师,每次有人想添加功能时,他们都想不断地拆卸和重新组装整个汽车,这听起来很疯狂。

我们使用Java和Hudson进行持续集成。”“临时解决方案”必须注明:

// TODO: Better solution required.

每次Hudson运行构建时,它都会提供每个构建的报告 待办事项 因此,我们有一个最新的,高度可见的记录,任何未完成的项目,需要改进。

我发现需要解决的问题通常只是问题的一个子集。注意,需要紧急修复的客户不需要解决整个问题,只需要解决问题的一部分——无论是小问题还是大问题。这有时使我能够创建一个解决方案,它不是解决整个问题的解决方案,而只是解决客户的子集,并允许我在问题跟踪程序中保留更大的问题。

当然,这可能根本不适用于您的工作环境:(

年 .

有人可能会说,唐没有把CTool修好,这是他应得的惩罚。我唯一的观点是说你应该 在现实世界中,破解一个解决方案可能是不合理的。但如果你是要做这件事的人,那就要小心行事。

• 以书面形式(电子邮件)收到。因此,当它成为一个问题以后,管理层不会“忘记”它应该是暂时的。

• 使其对用户可见。危机越明显,人们就越不可能在危机结束后忘记回去,以正确的方式去做。

您针对自己的“修复程序”提交了第二个非常描述性的bug,并在受影响的区域中添加了一条待办事项注释,内容是:“此区域需要大量工作。请参阅缺陷#555”(当然,请使用正确的编号)。那些说“不要进行黑客攻击”的人似乎不理解这个问题。假设你有一个系统现在需要启动和运行,你的非黑客解决方案是8天的工作,你的黑客是38分钟的工作,黑客在那里为你买时间做工作,而不是在你做的时候赔钱。

引入快速修复的真正代价是,当其他人需要引入第二个快速修复时,他们将基于您自己的快速修复来引入它。因此,快速解决方案实施的时间越长,它就越根深蒂固。通常,一次黑客攻击只需要比做正确的事情稍长一点的时间,直到你遇到第二次黑客攻击,它建立在第一次黑客攻击的基础上。

因此,显然,有时(或似乎)有必要引入快速修复方法。

假设您的版本控制支持,一个可能的解决方案是在您进行此类攻击时从源代码引入fork。如果鼓励人们避免在这些特殊的“完成”fork中编写新特性,那么最终将新特性与fork集成的工作将比摆脱hack的工作更多。不过,更有可能的是,“好”叉会被丢弃。如果您离发布还有足够远的距离,以至于制作这样一个fork是不实用的(因为不值得做上面提到的双重集成),那么您可能根本不应该使用hack。

一种非常理想化的方法。

一个更现实的解决方案是将程序分割成尽可能多的正交组件,并偶尔对一些组件进行完全重写。

一个更好的问题是为什么黑客的解决方案不好。如果这是因为它降低了灵活性,那么忽略它,直到你需要灵活性。如果它是坏的,因为它影响程序的行为,忽略它,最终它将成为一个错误修复,并将得到解决。如果因为它看起来很丑而不好,那么忽略它,只要黑客是本地化的。

• 用注释标记它 HACK XXX
• 每周运行一份自动报告,并通过电子邮件发送给那些关心该报告的人,该报告统计了该报告的次数 乱劈 出现评论
• 在bug跟踪系统中添加一个新条目,其中包含行号和正确解决方案的描述(这样在编写hack之前从研究中获得的知识不会丢失)
• 编写一个测试用例,演示黑客是如何失败的(如果可能的话),并将其检查到适当的测试套件中(例如,这样它会抛出错误,最终会有人想要清除)
• 一旦安装了hack且压力关闭,立即开始使用正确的解决方案

这是一个极好的问题。当我获得更多经验时,我注意到一件事:黑客给你带来的时间非常短,而且往往会让你付出更大的代价。与此密切相关的是“快速修复”,它解决了你认为是问题的东西——但当它爆炸时,却发现根本不是问题。

抛开关于你是否应该这样做的争论,让我们假设你必须这样做。现在的诀窍是以一种将远程影响降至最低的方式进行操作,它很容易在以后被撕掉,并使自己成为一个讨厌的东西,所以你要记得修复它。

撕下的部分可能很容易:我喜欢这样做,在子例程名称后面放上乱七八糟的内容。这使得更新更容易,因为您将代码划分为多个部分。当您得到永久解决方案时,您的子例程可以实现它,也可以是不可操作的。有时,子类也可以很好地解决这个问题。不过,不要让其他人依赖于你的快速解决方案。在不了解情况的情况下,很难推荐任何特定的技术。

如果代码的其余部分很好的话,最小化长程影响应该很容易。始终查看发布的界面,等等。

试着让生意人清楚地知道黑客攻击的成本。然后他们可以做出明智的决定。

您可以故意以过度限制和单一目的的方式编写,并且需要修改重新编写。

自白:

为了在其他代码层中读取数据,我使用C++中的“定义私有公共”。它作为一个黑客进入,但工作良好,修复它从来没有成为一个优先事项。现在是三年后了。。。

黑客没有被移除的一个主要原因是在修复黑客时引入新bug的风险。(尤其是在处理TDD之前的代码基时。)

1. 测试驱动开发

2. 重构的小单元

4. 良好的配置管理

不用说,你必须得到利益相关者的支持才能正确地完成这些任务。但是,有了这些产品,您就有了正确的工具和流程,可以自信地以主要方式快速更改产品。有时,您的变更能力就是您管理变更风险的能力,从开发角度来看,这些工具/技术为您提供了更可靠的基础。