When refactoring really small projects I start with pen & paper and wrote down all classes, variables and methods.
It’s a good way to review code. I read headers one after another, decide whether methods are organized logically or not. Should I move some higher, or lower to improve overall readability. Also it’s great moment to stop and think about changing names to more accurate, deleting unnecessary things, or hull out classes from bigger ones. Here’s my example refactor sketch for MPD-helper application:
As you can see all refactoring is part of MainWindow class, where I highlighted functions I doubt.
Yellow color is used to schow unnecessary variables, or moving one from class to class.
Red color outlines functions for new Solver class, which contains sorting algorithms.
Blue one designates functions for Plotter class. One who prepares solution plot.
It went to that:
It’s still far from perfect, and it can be troublesome to other developers to read (eg. what the hell is getTimeFromMashinePlotting and why I call it in every function that ISN’T connected to plotting? Or too many arguments in drawSolutionPlot) especially because I focused on making new classes than making it clean. But I think I’m on my way to something readable (:
And I’m pretty confident I should invent refactor method more suited for big projects.