One of the things that I was not expecting when I started refactoring other people’s code was that I started to see improvements in the way I wrote my own code. I didn’t make those same mistakes.
Refactoring other people’s code has taught me a great deal about things to do and things not to do in software. We learn through imitation and unfortunately, good example code can be hard to come by. Example programs in books and frameworks tend to be simplistic and it can be hard to see how simple examples can scale up to enterprise systems.
Many developers that I meet tend to shy away from working with legacy code but I find that when I work with legacy code I learned a tremendous amount and my skills as a developer improve significantly. This is one of the reasons why I advocate for other developers to spend some of their time cleaning up legacy code.
A lot of refactoring is rote and it would be no fun at all except for the fact that modern IDE’s have many refactorings that are automated so when I’m working in Java or C#, I find that I can quickly and easily refactor my code with a few clicks of my mouse. In fact, I do a lot of my development with my mouse alone (or hotkeys) by selecting refactoring options to emerge my designs piece-by-piece. This can be a lot of fun but when I’m in more of a hurry then I resort to using the keyboard.
Having the automated refactorings that are available in IDEs is like Eclipse, IntelliJ, Visual Studio, and Code allows me to quickly and easily start simple with a design and emerge it as I wish. I first put the functionality I want into a method and then I extract that method into its own class and then I make that class abstract and add a Strategy Pattern, and so on. I find that this is a fun and safe way to build software.
I learn a lot by reading other people’s code. I haven’t found many good sources but of course, there is a lot of code on GitHub. One can learn a lot by reading other people’s code but only to a point. I wish there were more publicly available examples of good code, especially examples of large systems but unfortunately, there aren’t (or I haven’t found them yet). I’ve seen a lot of examples of big systems both good and bad that are the major systems in production today but most people don’t have access to that information.
A lot of the software that’s publicly available in repositories are not the best examples of high-quality code but there’s still much that can be learned from them. More and more resources are becoming available for learning about more advanced developer practices. I find that there are a lot of sources available for beginners and a few resources that are available for intermediate developers but virtually no resources are available for advanced software developers. This is a gap that I’m trying to fill while at the same time trying to boil down advanced practices to their simplest components so anyone can understand them.
Every once in awhile I will come across a project on GitHub that is beautifully written. I love to read elegant code. It makes my day. But honestly, I learned equally as much now when I read code that’s poorly written because I get clearer and clearer on the techniques that I want to avoid.
This not only concludes my seven blog posts on helping you justify refactoring, but it also concludes nine series of blog posts, each consisting of eight posts for a total of 72 blog posts that dive into strategies related to the nine practices from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I hope you found it interesting and informative, and if so, consider reading my book.
Previous Post: « Refactor to Clean Up Before Moving On
Next Post: Summary of Seven Strategies Series »