Hello all. I am curious about something. I've been handed an old code base which I have been wading through for the past six months or so. It's pretty old with some patch work here and there. Some features are pretty new and some too old to remember when they were implemented. I was also handed this by a person who (despite the fact that they built the entire code base) was essentially teaching himself how to code it. Suffice it to say, there are plenty of issues with the code. I've noticed many and corrected some. My question is simple. How do you go about refactoring your code base? Do you schedule it? Do you clean as you go? Do you keep lists of bugs and fixes you know you need to implement but might not be urgent at the moment. Just curious about what the people smarter than me do. Thanks for reading!
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (9)
Many text editors and IDEs recognize comments with certain labels:
and highlight them differently or even provide a special search shortcut that only lists notes to your future self, although a manual search is of course not that much more complicated.
In general if I'm working in a file and am not especially pressed for time I'll take a little bit to clean things up and organize the code if it seems like it needs it it. Logging refactoring tasks in an issue tracker doesn't seem to happen consistently if at all. "Google time" to hack at things you'd like to do but couldn't otherwise justify is an interesting possibility too, if you can swing it.
To add to this OP, if you're using atom, you can use this package. atom.io/packages/todo-show
Generally, I'll mark an issue with the refactor tag as I am working on new features or fixing bugs.
I try to dedicate Fridays for refactoring, unless there's some time sensitive work to be done.
Depends on each situation, the overall plan is to do as you go, for many reasons (better return of investment of time, no production down time .. I wrote more about how I do it on my blog )
But if you are requested to make a big feature improvement on a module that doesn't support it (the time to add the new fuctionality is longer than a refactor and to add it), you have to plan the refactor then do the task.
I usually don't keep a list of TODO, the ones you will hit more often (count the courses per module), is most likely to get refactored quicker. For the bigger refactors we put in the planning tasks, a big technical debt tasks and tell the manager to make it a pre-requirement before any big task on that module.
ReFactor Fridays.
I always schedule a 4 hour chunk every Friday afternoon for code sanity. Despite the name, it doesn't always involve refactoring, sometimes it's just cleaning up a couple comments or hacks or other code janitor things.
I try to avoid writing new code though, and just work on making sure that it's not going to be embarrassing to show it to someone else.
That's what a few people have suggested. I was thinking about doing the same thing. I believe doing that may help keep it all up. Especially since it's just me!
It's definitely an investment that pays off, especially if you're working on multiple projects with different architectures and logic streams.
General rule of thumb for me is that if you're working on code that you're not going to touch on a regular basis every couple of months, it might as well be written by someone else - so comment and restructure it the way you're want it to be for you as if someone else had written it. The developer you are today is not who you're going to be 6 months from now.
Scheduling time is important though, otherwise it gets buried as just one more task that you'll get to "eventually". The bonus for scheduling it Friday afternoons is you avoid those Friday afternoon meetings because you're booked as "busy"
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.
It depends if your Org allows you to go back and refactor.