Andrea Angella, Software is my passion.: Learnings from software development coaching sessions

Back in November 2013 I wrote a post sharing with you my decision of being mentored by a friend and agile coach Matteo Baglini with the goal of exposing myself to agile engineering practises and become a better developer.

At the time, I promised to write posts about my learning but ultimately I didn't. So, it is time to start now!

First of all, I wish to thanks my manager Dom Smith in Red Gate Software to offer me the opportunity to have these sessions during working hours. This really offers me the ability to have sessions regularly every week.

In this post I will condensate the learning of the last few months of mentoring with links to the various resources that I read since then.

We started discussing TDD and the approach described by Kent beck:

Write new code only if an automated test has failed
Remove duplications

Duplication is the most important code smell and it can be hard to see. For this reason, sometimes it is useful to write verbose code just to help you find duplications.

I did the full Money example in the book TDD By Example exactly how Kent did it (with few changes as I did in C#) and deeply reflected on each step. I spent a full day to do it but it was worth the effort.

Learning well a refactoring tool like ReSharper is very important. However it is important to consider that the biggest advantages of a refactoring tool is not merely productivity:

Avoid the human error
Remove the context switch between using keyboard and mouse
Shorten the feedback loop by decreasing the time needed to refactor a piece of code
You can answer quickly questions like: Is the new design better?

Doing a kata multiple times without changing the solution to just focus in how you code and use refactoring tools is a very useful technique.

Here is a collection of very useful advices:

Check the error message when a test fail
Run tests often
After a refactoring run the tests
Avoid copy & paste as much as possible
When you find something to do, don't stop your current task. Add a note and do it later.
Don't stop the flow only to rename a method or a property! Add a note and do it later.
Primitive obsession can be often removed by introducing Value Objects
Sometimes you can add a test and comment it out in order to do necessary refactoring
Don't be too confident! Always use tests to validate what you are doing
Keep tests as stupid as possible. Limit test logic as much as possible!
In case of regression (red bar) never change test logic otherwise you won't know what was right
If you lose control, just slow down or discard changes and restart
Don't restrict yourself in a Top Down or Button up approach.
The code guides you. TDD is a feedback tool.
Consider adding code even if it is not strictly required to improve readability or simply to add symmetry
Some tests are simply tests to support you during development. You can remove them when other tests cover the same functionalities. Don't be afraid.
Consider the "Copy Type" ReSharper command
The production code tests the tests!
Extract Method is a powerful refactoring tool
It is sometimes useful to make a private internal method public just for the sake of temporary writing unit tests but don't submit that code! Use it only to increase your knowledge about the problem.
Learn how to do small steps when needed.
A test is done only when duplication is eliminated!
Consider writing a test to force the creation of an object that we expect to need late but attention of not doing upfront design
Relying on the compiler can be a useful technique
If it takes a lot of time to make a test green... reflect!
Prefer static methods to factory classes when implementing the factory pattern
Getters are smells. Pay attention to not use objects as mere data structure.
Resist the temptation of not creating new classes... try, get feedback and see!
Observe the frequency of change. Change should be distributed among classes.
Use the Single Responsibility Principle to see pattern of change
The class who own the data should do the operation: Tell, Don't Ask!
In designing API it is best to offer a single way to do something. Make it simple!
Use the history in SCM to get insight about your project
Analyse temporal correlation of class changes
If you feel that something is annoying in the code base that is a sign of poor design.
Remain at the same level of abstraction within a test
Write a high level test and when you see the need to cover a lot of cases go down of one level of abstraction and write more specific unit tests.
You will often be pushing tests up and down between different levels of abstraction
Remember to not look inside the object when you do testing even on individual classes! Test the behaviour so that you can easily change the instance of the class with a new class but keep the tests intact.
Do not use TDD as a way to get permissions to write production code (that is cheating).
Do not be too enthusiastic about new technologies or methodologies. Slow down and reflect. There will be always a hype and later a fall. If you are pragmatic you can fall less.
Consider writing the assertion first

The essence of object orientation is thinking about behaviours

TDD test are always behavioural and at different level of abstraction. TDD can be done at different levels of zoom: it is sort of a dance between them. Unfortunately TDD has been often misunderstood and even attempts were made to fix this with ATDD and BDD. But these methods have often been identified with tools and things like Cucumber only create a new layer without bringing much value: having the on-site customer is far better than executable requirements that are a dream.

Pair programming helps a lot to keep focused and the role of navigators is supporting drivers in maintaining discipline and avoiding distractions

I and my mentor discussed many times about the Theory of Constraints and the importance of identifying bottlenecks in order to remove them. It is quite interesting to note that also humans can be a bottleneck and therefore an issue that can be addressed by increasing sharing. This can be done both with pair programming or with the Expert in Earshot pattern.

Quotations:

I never known exactly how to achieve high cohesion and loose coupling regularly until I started writing isolated tests, Kent Beck

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong. Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we’ll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order. Kent Beck

Resources: