I can only recommend Feathers' Working Effectively With Legacy Code, which far expands on OP's themes, notably OP is missing tests - how can you improve on existing code when you don't even know that it works like it says it works?<p>In some cases it shows its age (especially when it comes to rolling your own mock testing, most languages have automated frameworks for that now), but it's still a great overview of the techniques you can employ.
All professional programmers should continually read Martin Fowler's "Refactoring", in the same way English professors read Shakespeare.<p>"Refactoring" does not mean "previous programmer was an idiot". Often, the understanding of the problem and the way the code is used change over time. Refactoring is a way of bringing the out-of-control weeds back into healthy symbiosis with the larger garden of code.<p>I stopped telling clients a long time ago that I'm "refactoring" and instead I just add some extra time to all tasks to account for refactoring on legacy code.
I know this code is just an example, but it seems like it's entirely backwards. The "bad" code at the beginning is immediately clear in what it's doing, but the refactored code is significantly longer and hard to understand.
Sandi Metz talk "All the Little Things"[0] is amazing for understanding the general concepts around refactoring OOP code. It's ruby centric, but the concepts are applicable to all OOP languages. The most interesting part is the fact that during the refactoring process you should actually increase the amount of code and complexity to eventually consolidate and aggregate it down. This as opposed to simply trying to delete/mutate code.<p>[0] - <a href="https://www.youtube.com/watch?v=8bZh5LMaSmE" rel="nofollow">https://www.youtube.com/watch?v=8bZh5LMaSmE</a>
<p><pre><code> if( masterList[z].list2 != NULL && masterList[z].list2.length() > 0 )
{
for( Integer y = 0; y < masterList[z].list2.length(); y++ )
</code></pre>
The if-statement is a good summary of what is wrong with Java. The author doesn't even notice that the second argument of && is redundant and keeps it in the "refactored" version as well...
#1 If there are existing test cases
- Run them
- make sure they pass
- make sure it looks like they have good coverage<p>#2 if there are no good test cases, write them and go to #1
<<So-Called "Programmer">> is the name of the blog; the title of submitted post is "Refactoring: How do I even start?". Could mods change this please?