During the last 15 years I worked for a few different organisations of different sizes.
Some of them had more or less formal code reviews as part of their software development process. In my current job for example we have a very rigid code review process that says that every bit of code should get reviewed. But why?
I guess code reviews are considered as a way to improve code quality. It's believed to have a learning effect for less experienced developers as they have to review other's code and their code is reviewed and they should get valuable feedback on their code.
That's all nice in theory but my experience is different.
In a real world project it's unlikely that you have enough understanding of other parts of the code to do really useful code reviews. (I know collective code ownership is something that we should try to aspire for but again - I have still to see that.)
So most code reviews end up with advises like: add some JavaDoc there, don't forget to cleanup imports and format the code (Yes. I know what save actions are for. Thank you!)
All of this stuff (and much more) can be done easily by PMD, FindBugs and CheckStyle. Done properly by an continuous integration server it's automatic and easy. Additionally it's much easier to accept feedback like this from an automatic system than it's to accept from the JavaDoc Nazi next door.
The saved time can be invested into stuff that really improves the code. You could start to do pair programming for at least the important modules. That's really something that creates collective code ownership and makes it possible to have more than one person that really know what's going on inside these core parts. Additionally less experienced developer can learn from the other's and the experienced developers learn how the other's think and code.
But I'm still trying to get this into the heads of my coworkers and managers.
2010-05-29
2010-05-08
My two favorite programming related books
There are a lot of programming related books available. Some are good, some are - well - not so good.
But there are two books that I really, really like.
The first one (my number one) is "Clean Code: A Handbook of Agile Software Craftsmanship".
There was nothing totally new in there for me but I personally agree with 99% of everything the author says. It's not a book that teaches you how to write code but it tells you how to write good code. My favorite statement is that software development is a craft, not a science and that's what I ever believed. The only problem was that it seemed that nobody else was thinking the same. But fortunately the craftsmanship thing is now quite popular and we all know by now that we should be proud of being a good craftsman. There clearly is a demand for computer science but software development is something totally different. So in my opinion: "software development != computer science". And this book helps you to become a good craftsman.
The other book is "Code Complete: A Practical Handbook of Software Construction".
I think it's much more low level than the other book. If "Clean Code" is about writing good code this book is just about writing code that actually works. It's a lot of stuff that everyone should already know but I think it's good to have a book like this. While you are reading the book you always think "Hey, I recall this one".
Subscribe to:
Posts (Atom)