-Now I want to conclude this discussion on refactoring by telling you - -2
-when you should not refactor. One first clear case is when - -3
-your code is broken. I want to make it very clear, refactoring - -4
-is not a way to fix your code in terms of its - -5
-functionality. It's a way to improve the design of your code. - -6
-So if your code does not compile or does not run - -7
-in a stable way, it's probably better to throw it away - -8
-and rewrite it rather then trying to refactor it. By definition refactoring - -9
-should maintain the functionality of the - -10
-system. It should be behavior preserving. - -11
-So if the code was broken before, it, it's probably going to be broken - -12
-afterwards as well. You may also want to avoid refactoring when a - -13
-deadline is close. Well, first of all, because refactoring might take a long - -14
-time and therefore might introduce risks of being late for the deadline. - -15
-And also, because of what we said before about introducing problems, you don't - -16
-want to introduce problems that might take you time to fix right before a - -17
-deadline. So if the deadline is too close, you might want to avoid - -18
-refactoring the code at that point. And finally, do not refactor if there - -19
-is no reason to. As we said before, you should refactor on demand. You - -20
-see a problem with the design of your code, with the structure of your - -21
-code, it's okay to refactor. If the code is fine, there is no reason - -22
-to refactor. I know that refactoring is fine, but you don't want to do - -23
-it all the time. The next thing I want to discuss, after discussing when - -24
-not to refactor, is when to refactor without an indication that will tell us - -25
-that it's time to refactor the code. And that leads us to the discussion - -26
-of a very interesting concept. -- cgit 1.4.1