This episode is about failure to refactor because of trying to rush to the next step of Triangulation and taking too bigger steps. I sometimes use bigger steps, but I don’t feel comfortable because it can happen that I get stuck and then I revert. In this way I lose a lot of time. I usually prefer to go slower but make sure I have progress.<\/p>\n
Consider this episode an example of how NOT to refactor.<\/em><\/p>\n Rushing to refactor can lead to a good result, but most often it leads to a situation where tests fail and we don’t know why. Most often the programmers I work with are rushing to refactor and don’t even observe the side-effects they introduce when they change the code. So they are not refactoring, but instead they are introducing defects because of taking too bigger steps. The most important aspect in this situation is that when I run the tests during the refactoring rush they are most often red<\/strong>. After being on red for 20-30 minutes I feel more and more pressure and I need to take a break. I don’t know what to do next, I feel stuck.<\/p>\n The most common reason of getting stuck or having red tests after finishing a refactoring is not using preparatory refactoring<\/a><\/strong><\/em>.<\/p>\n Refactoring flow means I always see a few next steps ahead. Also the most important aspect is that after each small change I run the tests and the tests are always green<\/strong>. Being in a flow feels good, and I often even forget what the time is.<\/p>\n So this episode, coincidentally or not it has the number 13, shows refactoring failure because of rushing and not preparing the refactoring. Please watch it and make sure you don’t do the same at home. Next episode will show you a better way to work, in contrast with this one.<\/p>\n Check the video below with the codecast:<\/p>\nRefactoring Rush vs Refactoring flow
\n<\/strong><\/h2>\nFailure<\/h2>\n
Video<\/h2>\n