Code review: increased quality and knowledge sharing

In my earlier post "Make it better" I said we were starting with a more TDD similar approach. We have tried this now for more than a month. We have tried writing tests first, but this seem to be a futile attempt. Arguments used are "I tried, but it took too much time to make the test" and "It is too difficult to make the test and it was only a small change in the code". To these arguments I can say that they are true in our case. Much of our legacy businesslogic has been placed in beans which in our case are difficult to write tests for. Hopefully we will be able to make more tests totally new businesslogic rather than trying to make it for the old code.

This said, I would say that we have in this process learned a lot about our own code and its limitations. Placing the business logic in beans is not good for the ability to test the code. We will try not to blindly do as the one before us did. I figured a way to try to compensate for the lack of writing the tests and introduced mandatory code review before any code can be checked in to the subversion repository. This forces the developer to argument and discuss the code before it become a part of the solution. It gives the developer another perspective and thus enable both the sharing of knowledge and an increase of quality. As in TDD the idea is that one would think differently before coding because we write the test first, we in this case do the code review after the coding but still enable the developer to get comments on both the code and its quality.

At the last xp & agile meetup in oslo we had Robert C. Martin (uncle Bob) present his thoughts on craftmanship and ethics where he mentioned that if we checked in code that was just a little bit cleaner and better than when we checked out we would eventually increase the quality of the code. The code review is a good incentive for this practice.

To quote uncle Bob: "Never check in bad code!"