I attended Day 1 of YOW! Sydney 2013 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.
Hadi Hariri is a Developer and Technical Evangelist at JetBrains. He spoke at YOW! about refactoring legacy codebases.
Hadi started by offering reasons for refactoring:
- increase the understandability of the code
- decrease the impact of change
- reduce the cost of change
He described how refactoring relies on culture: buy-in from the team, a desire for clean code, collective code ownership, less ego, buy in from business (which needs to have the ROI explained), and consistency.
He said a good book for learning about refactoring in depth is Working Effectively with Legacy Code by Michael C. Feathers.
Refactoring Tips for Legacy Codebases
He briefly introduced the ideas of seams and sprouts from the book. From what I could gather, these ideas are about adding testing to an existing code base, with a ‘seam’ being a layer in your code at which it is easy to start introducing tests, and ‘sprouts’ being some patterns of various ways to introduce tests for new functionality added to the code without having to write tests for all the existing code first.
He recommended favouring integration tests over unit tests with stubs, and said he stays away from mocks because he considers them white-box testing.
He proposed renaming as the most important refactoring, due to it being the most important way to improve the understanding of the code.
He said a good example of bad code is a function that does two completely different things based on Boolean parameter.
He complained about the practice of appending a pattern name to a class name. I have to say that I disagree pretty strongly with Hadi on this one. The purpose of a class’ name is to communicate succinctly the responsibility that objects of that class take on. If a class is implementing a pattern, be it Adapter, Decorator, Facade, Flyweight, Observer, or whatever, naming that pattern in the class name communicates a lot about the class’ responsibility, and using only a single word, which is a good thing. If readers of the code don’t recognise the pattern (do you know the flyweight pattern?) then naming it in the class can prompt them to go and look it up.
He brought up the problem of naming tests by the methods they are testing, which I have seen quite a bit and is a terrible idea. He showed an example of such a test then gave it a BDD-style name that went off the screen. Though we don’t follow BDD at Tyro, we have been using BDD-style test names for quite some years now and I can recommend it as making a huge difference to the readability of a test suite.
He showed an example of having too many dependencies in a class and talked about how it almost definitely indicates failure of single responsibility.
Want to learn more?
The slides from Hadi’s talk are available on the YOW! website.
Image credit: ‘Refactor stickers‘ by Dave DeSandro