Comments on: Refactoring with red bar?!?!? http://www.responsive.se/thomas/2007/02/16/refactoring-with-red-bar/ Thomas on Responsive Development of Systems and Software Sun, 16 May 2010 13:37:36 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Thomas Grönwall http://www.responsive.se/thomas/2007/02/16/refactoring-with-red-bar/comment-page-1/#comment-764 Thomas Grönwall Tue, 24 Apr 2007 07:49:17 +0000 http://www.responsive.se/thomas/2007/02/16/refactoring-with-red-bar/#comment-764 I don't disagree with you. I am a pragmatic person. I just wanted to explain the idea behind the rule. One of the fundamental ideas behind agile development is to move in small steps. So, the "by-the-book" way of doing it would be: You create the one test, implement just a little, then you realize the need to refactor a little, before you move on to the next test. Another way of doing it is to realize the need to refactor before you even start to create the first test. But be careful, big speculative refactoring must be avoided, since you may have to refactor it again if you were wrong. The third situation, is the one you described. You realize the need for refactoring in the middle of it when you are sitting there with a failing test. Well, shit happens, I say. The situation will happen sometimes, and I would do as you, "disable" the test, refactor a little, enable the test, implement until the bar turns green. The difference between the three cases above is the time when the developer realizes the need to refactor. Pair programming is a tool for realizing it early in the process. But no rule in the any book can force you to realize it at one time or the other. It just happens. I don’t disagree with you. I am a pragmatic person. I just wanted to explain the idea behind the rule. One of the fundamental ideas behind agile development is to move in small steps.
So, the “by-the-book” way of doing it would be:
You create the one test, implement just a little, then you realize the need to refactor a little, before you move on to the next test.

Another way of doing it is to realize the need to refactor before you even start to create the first test. But be careful, big speculative refactoring must be avoided, since you may have to refactor it again if you were wrong.

The third situation, is the one you described. You realize the need for refactoring in the middle of it when you are sitting there with a failing test. Well, shit happens, I say. The situation will happen sometimes, and I would do as you, “disable” the test, refactor a little, enable the test, implement until the bar turns green.

The difference between the three cases above is the time when the developer realizes the need to refactor. Pair programming is a tool for realizing it early in the process. But no rule in the any book can force you to realize it at one time or the other. It just happens.

]]> By: thomas http://www.responsive.se/thomas/2007/02/16/refactoring-with-red-bar/comment-page-1/#comment-759 thomas Mon, 23 Apr 2007 21:18:13 +0000 http://www.responsive.se/thomas/2007/02/16/refactoring-with-red-bar/#comment-759 I don't agree. One essential function of refactoring is to improve the design. The issue I was trying to address in the article was the fact that I often want to redesign to be able to slot in the new functionality better, or even make the growth possible. I strongly belive in refactoring to allow functional growth as opposed to force new functionality in and then try to clean up using refactoring. I don’t agree. One essential function of refactoring is to improve the design. The issue I was trying to address in the article was the fact that I often want to redesign to be able to slot in the new functionality better, or even make the growth possible. I strongly belive in refactoring to allow functional growth as opposed to force new functionality in and then try to clean up using refactoring.

]]> By: Thomas Grönwall http://www.responsive.se/thomas/2007/02/16/refactoring-with-red-bar/comment-page-1/#comment-755 Thomas Grönwall Mon, 23 Apr 2007 06:38:02 +0000 http://www.responsive.se/thomas/2007/02/16/refactoring-with-red-bar/#comment-755 I think the idea behind the rule is to implement the functionality first, although you know that you will have to refactor it later. Then, when the when you have the green bar, go ahead and refactor it. I think the idea behind the rule is to implement the functionality first, although you know that you will have to refactor it later. Then, when the when you have the green bar, go ahead and refactor it.

]]>