Tuesday the monthly Agile Tuesday took place, my first one. Thanks to Mario Gadet who invited me a long time ago and made sure I didn’t forget about it. Already this put the bar quite high for me and I was quite nervous about it because I didn’t expect the typical tech audience. And it all turned out different than expected :).
I talked a bit about refactoring. I tried to summarize the hows and whys for it in order to get to the doing, right after the talk. And I picked the beautiful Tennis kata to refactor some stuff where some interesting things evolved.
And while at it we made a couple of interesting discoveries, let me share some with you.
The Evil of Native Constructs
A very interesting discussion spun off when we refactored the following switch
into this array
The valid arguments raised were that the explicitness of the `switch` gets lost in an implicit use of arrays, they are zero-indexed and therefore implicitly do the same as the switch, but it’s not “visible” as well as in the code before. From there we started discussing how much the source code shall rely on language specific constructs. Shall a piece of domain knowledge, here the mapping of 0 points to ‘Love’ and 1 to ‘Fifteen’ and so on, be hidden behind an implicit construct that actually does the same and allows for less code, but also reveals the intention less good?
Which raises a new question: what is the minimum level of language-specific knowledge required for the code to be maintainable, also by non-seniors? It’s just a fact that there is a gap in knowledge between the original author, the team and/or the future maintainers of this code. Should therefore the code be written by using less “difficult” constructs? Maybe even prevent certain language constructs that might cause traps?
I doubt that this helps. Depending on the domain the code is written for the code has to adapt. If the mapping of 0 to ‘Love’ and 1 to ‘Fifteen’ are core concepts of the business domain we are in, make those concepts clear to the (future) maintainers by writing more explicit code.
Artificially reducing a programming language’s feature set which sometimes just prevents that others have to learn new things, feels also very counter-productive and almost like trying to slow down evolution. A programmer just has to learn, constantly.
This led to an alternative construct we used, which makes the domain-level view more explicit. We write the relation between the numbers 0,1,2,3 and the according strings explicitly into the source code. We are not using a switch-case though.
The object-notation will be accessed just in the same way as the array above via `pointsMap[points]`. All participants have been really happy with this solution. So we all agreed to keep on moving forward from here.
A little bit later we touched code that looked something like this:
The mapping is very much like the one we handled above, but has a little twist to it, which is the case for all values from 3 upwards. First thing the crowd decided to do is move the map out of the function.
Then we tried to reduce the actual function down to this.
And the crowd was happy, I mean really happy, it seemed.
The discussion about explicitness led us to use an object instead of an array. If this hadn’t taken place we would never have seen the solution with the elegant `default` key in the object.
Doing all that in a mob-style fashion, which means discussing in the group and having one person execute the solution that had been agreed upon, is always again a fun experience and makes people engage and steer towards a good solution together, learning to accept opinions and find one (of the) best solutions.
Can we help your project?
We love to discuss code and tests, build strategies and help improving things. If you think this is something that should be done in your project/company/department please contact us! We are happily offering support and love to share our knowledge.
You can also find us at various events, we are always curious about learning new things and helping out if we can.
Sugar cubes image source