Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

When start/stop refactoring?

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My question is more philosophy than technical. heh. Well sometimes is hard to decide if we should start a refactor and once we've started is hard to decide when must stop. So how to know exactly the correct time to do that? Or always depends of the project and the moment (remembering that we're always with a lot of stuff to do, so the time is always crazy).
 
Sheriff
Posts: 16940
286
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ideally, refactoring should be done often and in small increments and you should try to do it as soon as a failing test has been made to pass. The main motivation for refactoring is to eliminate duplication and to clarify intent. Simplification is also a good goal.

Of course, getting into the habit of refactoring is kind of like flossing your teeth: you know you should do it often but many people only do it once in a while or not at all.

The way you asked the question makes me think that you're not doing refactoring very often and when you do, they tend to be large efforts with a lot of code being affected. This almost makes me think that you're not actually refactoring your code but rather you're reworking it.
 
Author
Posts: 63
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As Junilu indicated, the refactoring should be carried out continuously. It is relevant to mention the Boy Scout rule; the rule states that "Always leave the campground cleaner than you found it." In the same way, when you stop working on a file/class, you must leave the code cleaner than you got it.
 
Phelipe Maia
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:Ideally, refactoring should be done often and in small increments and you should try to do it as soon as a failing test has been made to pass. The main motivation for refactoring is to eliminate duplication and to clarify intent. Simplification is also a good goal.

Of course, getting into the habit of refactoring is kind of like flossing your teeth: you know you should do it often but many people only do it once in a while or not at all.

The way you asked the question makes me think that you're not doing refactoring very often and when you do, they tend to be large efforts with a lot of code being affected. This almost makes me think that you're not actually refactoring your code but rather you're reworking it.



I agree but sometimes you don't have time to refactor the legacy code. It's hard to say that I will take this because before implement the feature the legacy code must be refactored.
 
Junilu Lacar
Sheriff
Posts: 16940
286
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I seldom buy into the "no time to refactor" reason for not refactoring. Sticking with the dental analogy, it's like saying "I have no time to floss." Ok, but you'll definitely have to make time to get those infected gums and that cavity looked at. Sooner or later you'll have to pay for not taking care of your teeth and gums properly. Likewise, sooner or later, you or someone else will pay the price of not refactoring the code/design. The longer you put off refactoring, the more time and effort you'll have to eventually, and usually inevitably, spend to do it when you finally get around to it.

You do have to be prudent in your refactoring though. As I said before, refactoring should be done continuously and incrementally. You should try to avoid large refactorings when working with legacy code that is not covered by unit tests. Most code that hasn't been refactored can usually benefit from these refactorings:

1. Rename - to clarify/reveal intent
2. Extract method - to eliminate duplication and reveal intent
3. Compose method - to reveal intent

Probably 80% of the refactoring I do is one or more of these three. Most of the code that I find difficult to work with is just hard to understand. Spending some time to just clarify the code, eliminate duplication, and clean up abstractions can greatly reduce the effort to maintain it and it can help you find problems more easily.
 
Don't mess with me you fool! I'm cooking with gas! Here, read this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth
https://coderanch.com/t/751654/free-earth-friendly-heat-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic