No one likes messy code, and everyone likes simplified code, so I was interested in learning more about refactoring. While the idea of enhancing code sounds fairly intuitive, I wanted to learn more about tips and practices to use when refactoring code. In the past, I’ve been guilty of leaving my code in rough shape, until after I finished. While my habits have improved, I still have a lot to learn in these regards. To help learn some refactoring methods and practices, I listened to episode of 78 of Full Stack Radio, with guest Ben Orenstein. Orenstein, dubbed “one of the refactoring guys”, formerly worked at Thoughtbot in Boston, and now offers a course on refactoring, as well as gives lectures on the subject.
What I really liked about this podcast with Orenstein is how direct he was with all his tips. None of his advice sounded complicated, because he used very simple, explicit language. In fact, this type of language demonstrated one of his tips: “make the implicit explicit”. For example, give full words when naming object. If there’s an intermediate equation in the middle of a method, leave comments or naming conventions that clearly state why it’s there and what it leads to. Too often, I’ve used vague abbreviations in my naming conventions. While in most small-scale programs, this isn’t an issue, I realize this could be very problematic on larger projects.
“first make the change easy, then make the easy change.”
One of the best tips I thought Orenstein offered during the podcast was preparatory refactoring, or to refactor code before making changes, rather than refactoring while making changes. In this regard, your preemptive changes can cause you to have to make less changes further down the line. He gave an example of once refactoring code prior to a new feature being implemented. In the end, the new feature was pulled and not implemented, but his refactoring in advance still improved the codes functionality.
I feel like I took a lot away from this, from small tips to things I never thought about. Something that caught me slightly off-guard was when Orenstein talked about not wanting to return null values but replacing them with empty arrays. I don’t recall ever learning about this, and they didn’t go into much detail about it, so I researched it a little further on my own. This podcast helped highlight the importance of refactoring and I’m sure I’ll continue to research more refactoring methods throughout my career.
From the blog CS@Worcester – Derek's Design by dereksspace and used with permission of the author. All other rights reserved by the author.