Tom*_*ert 79 language-agnostic
假设问题有两种可能的解决方案:第一种是快速但是hacky; 第二个是可取的,但需要更长的时间来实施.您需要快速解决问题,因此您决定尽可能快地解决问题,并计划在之后开始研究更好的解决方案.麻烦的是,一旦问题得到缓解,它就会直接下降到待办事项清单.你仍然计划在某个时候提出更好的解决方案,但现在很难证明它的实施.突然间,你发现你已经花了五年时间使用不那么完美的解决方案,诅咒它.
这听起来很熟悉吗？我知道我工作的地方不止一次.一位同事描述故意制作一个糟糕的GUI,以免长期意外采用.你有更好的策略吗？
Ste*_*sop 37
写一个黑客失败的测试用例.
如果你不能编写一个hack失败的测试,那么黑客攻击没有任何问题,否则你的测试框架是不合适的.如果是前者,在你不必要的优化浪费生命之前快速逃跑.如果是后者,寻求另一种方法(标记黑客,或测试......)
Joh*_*azo 17
策略1(几乎从未选择):不执行kluge.甚至不要让人们知道这是可能的.只是第一次以正确的方式做到这一点.就像我说的那样,由于时间的限制,这个几乎从未被选中.
策略2(不诚实):谎言和欺骗.告诉管理层黑客中存在错误,以后可能会导致重大问题.不幸的是,在大多数情况下,管理人员只是说要等到错误成为问题,然后修复错误.
策略2a:与策略2相同,除了确实存在错误.但是同样的问题.
策略3(以及我个人最喜欢的):尽可能设计解决方案,并且做得好,实习生或代码猴可以做到这一点.花费少量代码 - 猴子资金比证明你自己的薪水更合理是更容易的,所以它可能就完成了.
策略4:等待重写.继续等待.迟早(可能是晚些时候),某人将不得不重写这件事.不妨那么做吧.
Cra*_*aig 14
在进行截止日期驱动的工作时,这是一个主要问题.我发现添加非常详细的评论,说明为什么选择这种方式,以及一些关于如何编码的提示有帮助.这样看待代码的人就会看到并保持新鲜感.
另一个可行的选择是在跟踪框架中添加一个bug.feature(你有一个,对吗？)详细说明了返工.这样它是可见的,并可能在某些时候强迫问题.
Eri*_*ard 13
唯一一次你可以证明修复这些东西(因为它们并没有真正破坏,只是丑陋)就是当你有另一个功能或错误修复触及相同的代码部分时,你也可以重新编写它.
您必须对开发人员的时间成本进行数学计算.如果满足软件要求,并且唯一不对的是代码在引擎盖下尴尬,那么它并不值得修复.
整个公司可能会倒闭,因为过度热心的工程师每年都会在他们变得烦躁时坚持重新架构.
如果它没有错误并满足要求,那就完成了.装运它.继续.
[编辑]
当然,我并不主张一切都被黑客入侵.您必须在开发过程的正常过程中仔细设计和编写代码.但是当你最终得到必须快速完成的黑客攻击时,你必须对是否值得清理代码进行成本效益分析.如果在应用程序的整个生命周期中,您将花费更多的时间来编写一个混乱的黑客,而不是修复它,那么当然要修复它.但如果不是这样,那么重新编写一个有效的,无错误的应用程序的代码就太昂贵了,因为查看源代码会让你生病.
你不做临时解决方案.
有时我认为程序员只需要被告知这一点.
对此抱歉,但严重的是 - 一个hacky解决方案毫无价值,即使在第一次迭代时也可能需要比正确执行部分解决方案更长的时间.
请停止给我保留你的垃圾代码.总是有责任改正.无论需要多长时间,谁会对你大喊大叫.
当你在早期交付之后坐在那里捏着拇指,而其他人都在调试他们的愚蠢黑客,你会感谢我.
即使你认为自己不是一个优秀的程序员,也要始终尽力做到最好,永远不要走捷径 - 任何时候你都不需要花费时间.如果你不相信我,我可以证明这一说法.
突然间,你发现你已经花了五年时间使用不那么完美的解决方案,诅咒它.
如果你在诅咒它,为什么它在TODO列表的底部？