DEV Community

Discussion on: How do you schedule time for code refactoring?

Collapse
leightondarkins profile image
Leighton Darkins

TL;DR: I clean as I go. If I have to touch a dirty piece of code, I clean it and verify it's existing functionality before I start adding anything new.


The way I refactor is a good example of the type of "transferrable" skill you hear people harp on about constantly (myself included).

I worked in the kitchen of a restaurant for a couple of years after high school, and the single most valuable thing I learned was to always start with a clean workspace. Even if you didn't make the mess, clean it up. Once you're done making bread, clean up so when you start cutting vegetables, they don't get all covered in flour. If there are pots and pans lying all over the place, put them back in their rightful place, or throw them into the dish area. Taking a few minutes to clean up your workspace does wonders for actual productivity.

When I dive into some code, my first action is to assess it's structure and test coverage (i.e. can I read this? Can I tell what this does?). I don't add anything to it unless I'm happy with both of those factors first.

I'm careful not to let myself get bogged down in rabbit holes though. I keep the scope of my refactoring to the class or function that I'm looking at right now. If I see that the next function down is also dirty, I'll leave it for another time. I generally won't mark things for refactoring later because, in my experience, that does nothing to motivate anyone (including myself) to fix anything.