There are many books and manifestos or even books about those manifestos :-) the aim of which is to teach you how to be more efficient. They provide you with diverse recipes and tools to be more efficient as a person, as a developer but also as organizations.
All those writings also have another important thing in common; they all say that in order to be more efficient you constantly need to focus on delivering value or even steadily adding value.
I did a presentation during a Paris Software Craftsmanship Meetup, where I tried to define what exactly value is and the kind of things you could put in place (and things to avoid!) to bring it down to your code or even within your tests.
Here you go!
Yesterday I went to the second Extreme Programmers Paris Meetup (#XProPa)
It started with an application code appreciation exercise. The idea behind this is was to go through some code and see how the developer who wrote it tried to be as clean as possible.
The code we went through has been presented by its author himself! Clément Boudereau brought his nice HardMock legacy code mocking framework’s code and explained us why he wrote it that way.
We needed first some explanations on what HardMock is all about before going deep into the code itself! Hardmock is a mocking framework that can produce integration test based mocks. It will work as a behavior recorder that will store the generated mock on a file on your hard drive. All you need to do is to write a complete integration test that might have to connect to a DB through DAL calls, or call any external services, and then extract all the interfaces for any dependencies needed and record the corresponding behaviors. HardMock seems to be a nice way to be able to refactor big balls of mud without having the need to spend as much time on refactoring hard to maintain unit tests as refactoring the legacy code itself!
Now that we knew a bit more about HardMock’s domain and its vocabulary it was time to see the code! Clément strived to make it as clean as possible: he made use of pretty well named variables and methods; he tried to be as SOLID as possible but at the same time he managed find the right balance between the need of abstraction and readability (like providing more than one constructor to users so they can directly call the one with the most common implementation)
At the end we saw a lot of well written code but the conclusion was that code was not like literature! Even if you know the domain, you can strive to be as clean as possible; it will be always hard to understand the whole story just by reading the code. And as Clément said, your code will never get clean enough; it’s an everlasting improving story!
The second part of the meetup was made of open space discussions about different topics people would like to speak about. I joined the Mob Programming discussion group where Thomas Pierrain told us the way they run their #SORLunchBox project and I also spoke about our own Mob Programming experience at my company.
As often during meetups, it was an open-minding night sharing thoughts with very talented and interesting people! Don’t wait no more and find out what meetups are next to you! See you there?