什么时候不应该重构? [英] When should you not refactor?

问题描述

我们都知道重构是好的，我和下一个人一样喜欢它，但是您是否有实际案例，不重构更好?

诸如时间关键的东西或同步之类的东西?技术或人为原因同样受欢迎.真实案例场景和经验加分.

编辑:从目前的答案来看，看起来不重构的唯一原因是钱.我的问题主要与这样的事情有关:假设您想执行提取方法"，但是如果您添加额外的函数调用，则会使代码速度稍慢并阻碍非常严格的同步.只是为了让您了解我的意思.

我有时听到的另一个原因是习惯了当前代码布局的其他人会因您的更改而烦恼".当然，我怀疑这是一个很好的理由.

解决方案

为了加强另一个答案(并触及您提到的问题):不要重构代码的一部分，直到它被all完全覆盖em> 相关种类的测试.这并不意味着不要重构它"——重点是添加必要的测试"(正确地进行单元测试可能需要一些重构，特别是引入工厂 DP 和/或依赖注入 DP代码现在牢固地绑定到具体的依赖项).

请注意，这确实涵盖了您的第二段的问题:如果代码的一部分对时间要求严格，它应该被负载测试"很好地覆盖(就像更常见的类型，正确性测试，应该涵盖两个特定的单元 [尽管在性能方面——正确性检查是其他测试的业务！-)] 和端到端操作——如果谈论的是正确性而不是性能，则相当于单元测试和集成测试).

带有微妙同步问题的多任务代码可能是一场噩梦，因为没有任何测试可以真正让您对它充满信心——没有其他重构(这可能会以任何方式影响现在似乎正在工作的任何脆弱的同步)在旨在使同步更加健壮和健全之前被考虑(通过保证线程安全的队列进行消息传递是我最喜欢的在这方面的设计模式；-).

We all know that refactoring is good and I love it as much as the next guy, but do you have real cases where is better not to refactor ?

Something like time critical stuff or synchronization? Technical or human reasons are equally welcome. Real cases scenarios and experiences a plus.

Edit : from the answers thus far, it looks like the only reason not to refactor is money. My question is mostly relative to something like this: suppose you would like to perform "extract method", but if you add the additional function call, you will make the code slightly less faster and hinder a very strict synchronization. Just to give you an idea of what I mean.

Another reason I sometimes heard is that "others used to the current code layout will get annoyed by your changes". Of course, I doubt this is a good reason.

解决方案

To reinforce the other answer (and touch on issues you mention): do not refactor a part of the code until it's well covered by all relevant kinds of testing. This doesn't mean "don't refactor it" -- the emphasis is on "add the necessary tests" (to do unit-tests properly may well require some refactoring, particularly the introduction of factory DPs and/or dependency injection DPs in code that's now solidly bolted to concrete dependencies).

Note that this does cover your second paragraph's issues: if a section of the code is time-critical it should be well covered by "load-tests" (which like the more usual kind, correctness-test, should cover both specific units [albeit performance-wise -- correctness-checking is other tests' business!-)] AND end-to-end operations -- the equivalent of unit tests and integration tests if one was talking about correctness rather than performance).

Multi-tasking code with subtle sync issues can be a nightmare as no test can really make you entirely confident about it -- no other refactoring (that might in any way affect any fragile sync that just appears to be working now) should be considered BEFORE one intended to make the synchronization much, MUCH more robust and sound (message-passing through guaranteed-threadsafe queues being BY FAR my favorite design pattern in this regard;-).

这篇关于什么时候不应该重构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！