Flexible enough, but not too much
June 18 2009
as usual, switching to a new project, i like to perform a code review on my own or while pairing, looking for un-emerged design or simply for duplications; that’s really the funniest thing for a design-maniac like me. sometime nice hints do come, sometimes don’t (probably because the design is good enough given actual goals).
so, last week i’ve moved to an existing codebase, and while pairing i noted down on paper some complexities i found on code; later, with all green bars, we tried to simplify a bit. what mainly come out was a revisited model-view-controller triad for a reporting system.
my preferite part was the formatting stuff: some nested complex loops became a composition of Formatters, each taking care of a small amount of rows (details, total) or columns (descriptions, calculations, and the like).
as we started a new story, i paid attention to how much code was reused: not as much as i supposed, and that was really a shame, even if code was clearer. today was our payoff.
we found a bug on a report. given a collection of aggregates, we expected to see details for first aggregate, then a summary for its total, followed by details for second aggregate, then second summary, and so on. instead, result was all details followed by all summaries. there was something wrong with how Formatters where composed. fortunately, that wiring was in one single point.
so, it turned out that it was just a matter of composing Formatters in a different way. from today journal:
we fixed a bug on rows order moving from a composite with two section formatters (details, summary) to a section formatter with a composite (details, summary). flexibility powered by OO.
day by day, i’m learning the difference between flexibility and generality (as Wake’s Refactoring Book helped me understand).
moreover, it now seems it’s also easier for us to estimate tasks, having clearer boundaries and reusing code. and, off course, knowing more about domain logic.
being honest, there’s a lot of noise due to Java generics! if only we could use .NET implementation..
Make it clearer
March 29 2009
good naming is first step for understanding domain you work into.
today i was looking at a session foused on learning from the master, in any creative field. Philippe pointed out some good advice from Beck’s “Smalltalk Best Practice Patterns” book; first of all is “good naming is not important, is crucial”. choosing a good vocabulary, focusing on roles, is step one to conquer complexity.
ok, but when is the right time to choose names?
Beck’s book, as Philippe states, teaches how to make good micro-decisions, every few minutes, while coding: that’s what Beck later called “implementation patterns”. yep, but coding is not the only right time to name things.
refactoring is another.
when i first studied Refactoring book what was clear to me was the distinction between refactoring as a noun (a modification which improve design but doesn’t change behaviour) and refactoring as a verb (the activity of modifying design). then, question is: when do you refactor, and what is the goal? let’s see..
last week, at least twice, my pair and i were in the middle of understanding which object was in charge of some new functionalities. when we found a “good” place where to start, first step was extracting a bunch of code into a new class to better focus on existing behaviour. moving code let us reflect on roles: does the “old” owner still have the same role? and what about the brand new class, which is its role? names should be choosen accordingly. refactoring can be applied before adding new functionalities, in order to make it simpler to add.
finally, a very good advice is to refactor code while doing code reviews. sometime, i found very useful to checkout a codebase from scratch, start looking at some code i don’t master and rename classes and methods as i understand roles. useless code and duplications emerge during this process. same strategy should be applied while pairing, after each green bar.
last advice for today: kids, don’t do this at home without an automatic tests suite!