You Should Always Be Refactoring

So as part of my quest to read the "Classics" of software development  I've found at least one common thread.  It is that you should always be refactoring, but it's not the same definition of refactoring I would have thought of previously.

I had always thought of refactoring as trying to improve existing code, but that doesn't need to be the case.  You can and frankly should refactor the code you are writing right now.  Now, I've done code cleanup all along, but usually, it'd be something I'd do if I had enough time because I finished functionality early.  Now, I'm going to make refactoring a priority and allocate time for it up front.

Obviously, you're always trying to write the cleanest code you can, but one can't put the thought into perfect naming and optimal logic on the first try.  Coding is often about getting the ideas out of your head as a stream, so you can't stop the stream to optimize.  However, once you've completed that flurry of creation you need to step back and do the touch-up work.

I believe that before you check your code in, you should stop and give yourself a code review.  First take a break to clear your mind. Then, take a step back and really try to check everything with an objective eye.  Try to tear it apart to make sure the naming is obvious, the logic is sound and that the needed tests are in place.  Does it follow the DRY principle, are the edge cases covered, will a 19-year-old intern be able to understand what it's doing 6 months from now?  Then repeat the whole thing again until you are sure you've removed all the code smells you know how to find.

While you are refactoring your new work you should also make sure you are following the Boy Scout Rule on any existing code you work with.

Now, here's where things get interesting.  You can refactor parts of your life outside of software development.  You name it, sleep, diet, exercise, career, interactions with family or co-workers.  You can take a step back and evaluate what your goals/expectations are and check that your habits are set up to achieve them.  If not, you can begin to make incremental changes, but just as in software it will work best if you have test coverage.

With New Years resolution season coming up, this might be a good time to work on some life refactoring.  This is where refactoring can really shine.  Instead of deciding that January 2 you are going to do a "rewrite" to  "change all the things", pick out a small change and test it out.  If it works, do another small refactor and so on.  You are likely going to have better success with refactoring than with a rewrite.

If you do a "rewrite", where you try to do a complete change of everything all at once, most likely it won't be successful and you'll end up going back to the original program (with no improvements and with a bitter taste of failure), but if you make changes incrementally you'll find out what you can and can't change and have an understanding of why.