Monday, June 18, 2007
The Eye of the Beholder
No - I'm not talking about the Dungeons and Dragons game...
This article felt like a challenge to me. It would seem that Agile Methods are a little slow making inroads to embedded development (here's a short article). Ganssle's article was a throwback to my early Agile days, and it brought into stark clarity some of argument in favour of proper unit testing. I posted the following at the bottom of the New Code article:
Beauty is in the eye of the beholder. Every individual and team has its own unique style of coding. Anyone introduced to that code will find it ugly in some fashion or another - unless they can take on the culture and context of the original authors.
In other words, I agree that we'll spend most of our time working on legacy code, and that we'll invariably find it ugly.
What we really need is to capture the intent of the code - the reasoning behind it - in the unit tests. Subsequent generations of designers will have a better appreciation of what was done. They'll have the courage to refactor whenever necessary because they've got the tests to prove that their new code behaves exactly like the old code.
Does this apply only as we write new code? Absolutely not! Any adjustments to legacy code should be preceeded by the creation of a firewall of unit tests around the effected code, articulating and asserting its behaviour. The subsequent refactoring is then less prone to error, and ends with a fully tested section of code.
This article felt like a challenge to me. It would seem that Agile Methods are a little slow making inroads to embedded development (here's a short article). Ganssle's article was a throwback to my early Agile days, and it brought into stark clarity some of argument in favour of proper unit testing. I posted the following at the bottom of the New Code article:
Beauty is in the eye of the beholder. Every individual and team has its own unique style of coding. Anyone introduced to that code will find it ugly in some fashion or another - unless they can take on the culture and context of the original authors.
In other words, I agree that we'll spend most of our time working on legacy code, and that we'll invariably find it ugly.
What we really need is to capture the intent of the code - the reasoning behind it - in the unit tests. Subsequent generations of designers will have a better appreciation of what was done. They'll have the courage to refactor whenever necessary because they've got the tests to prove that their new code behaves exactly like the old code.
Does this apply only as we write new code? Absolutely not! Any adjustments to legacy code should be preceeded by the creation of a firewall of unit tests around the effected code, articulating and asserting its behaviour. The subsequent refactoring is then less prone to error, and ends with a fully tested section of code.
