I'd like to take a brief break from my discussions around Inversion of Control and the various design patterns we employ whilst applying the concept. Instead I would like to have you ponder with me the beauty of Test Driven Development (TDD).
The pun behind the title of this blog entry might not become apparent until the penultimate paragraph, but I would encourage you to stay with me (so to speak) throughout the essay and hopefully you will draw the same conclusions as I do with respect to why and how TDD results in beautiful, organic code.
Sometimes we know instinctively just how our implementation will turn out (for example if there is a well known pattern which we can apply) but yet still we must be unyielding in our approach. We must forget all of our preconceptions and we must drive out, through tests, the final implementation. We must go through all of the hoops: write a failing test and run the tests, write code to pass the test and run the tests, refactor the code and run the tests -my own personal mantra for this is Break It, Fake it, and Make It.
We are almost certain to end up with an implementation which "looks and feels" like the one we had in mind, but we are also almost certain to find that what we end up with is not exactly how we had envisioned the solution. What we actually end up with is just enough code to provide the solution, which also means that we have just enough of a pattern implemented as is needed to provide the solution. If the pattern in its entirety is not needed, it (the pattern) will not emerge in its entirety.
For this author, TDD is the most beautiful and organic methodology for writing code; this is because the process of TDD and Emergent Design can be likened most similarly to the process of Evolution and Natural Selection. Our code evolves over time, in much the same way as an organism (albeit at a highly accelerated rate of mutation!). Our tests represent the environmental forces acting upon the organisms, encouraging them to evolve along a particular path: And as in all living creatures for example, where various patterns are common (visual system, nervous system, auditory system, reproductive system, et al.); so we find common patterns (Fly-weight, Bridge, Adapter, Factory, etc.) among the various software systems upon which we find ourselves working.
At some point more than fifty years prior to Charles Darwin's publication of On the Origin of Species, William Paley presented a rather alluring hypothesis that the complexity of living organisms is evidence of the existence of a divine creator. In his thesis Paley drew a parallel with the existence of a watch compelling the belief in the existence of an intelligent watchmaker. In Paley's world the watchmaker is God, and in our world of software engineering, the watchmaker is the Solution Architect.
Many years (almost a couple of centuries) later, Richard Dawkins took William Paley's thesis as an eponymous starting point for his book The Blind Watchmaker, in which the blind watchmaker is analogous to the evolutionary process, perhaps then we could say that to us the blind watchmaker is analogous to TDD and a more fitting name for us (should we write the book) would be The Blind Architect.
The pun behind the title of this blog entry might not become apparent until the penultimate paragraph, but I would encourage you to stay with me (so to speak) throughout the essay and hopefully you will draw the same conclusions as I do with respect to why and how TDD results in beautiful, organic code.
Sometimes we know instinctively just how our implementation will turn out (for example if there is a well known pattern which we can apply) but yet still we must be unyielding in our approach. We must forget all of our preconceptions and we must drive out, through tests, the final implementation. We must go through all of the hoops: write a failing test and run the tests, write code to pass the test and run the tests, refactor the code and run the tests -my own personal mantra for this is Break It, Fake it, and Make It.
We are almost certain to end up with an implementation which "looks and feels" like the one we had in mind, but we are also almost certain to find that what we end up with is not exactly how we had envisioned the solution. What we actually end up with is just enough code to provide the solution, which also means that we have just enough of a pattern implemented as is needed to provide the solution. If the pattern in its entirety is not needed, it (the pattern) will not emerge in its entirety.
You have heard of Emergent Design, and this is exactly what is meant; we do not have a design to start with, but after going through the test driven process our code will begin to resemble something which was designed; mainly this is because of the way in which well known patterns will become apparent, or emerge, as part of the refactoring process.
For this author, TDD is the most beautiful and organic methodology for writing code; this is because the process of TDD and Emergent Design can be likened most similarly to the process of Evolution and Natural Selection. Our code evolves over time, in much the same way as an organism (albeit at a highly accelerated rate of mutation!). Our tests represent the environmental forces acting upon the organisms, encouraging them to evolve along a particular path: And as in all living creatures for example, where various patterns are common (visual system, nervous system, auditory system, reproductive system, et al.); so we find common patterns (Fly-weight, Bridge, Adapter, Factory, etc.) among the various software systems upon which we find ourselves working.
At some point more than fifty years prior to Charles Darwin's publication of On the Origin of Species, William Paley presented a rather alluring hypothesis that the complexity of living organisms is evidence of the existence of a divine creator. In his thesis Paley drew a parallel with the existence of a watch compelling the belief in the existence of an intelligent watchmaker. In Paley's world the watchmaker is God, and in our world of software engineering, the watchmaker is the Solution Architect.
Many years (almost a couple of centuries) later, Richard Dawkins took William Paley's thesis as an eponymous starting point for his book The Blind Watchmaker, in which the blind watchmaker is analogous to the evolutionary process, perhaps then we could say that to us the blind watchmaker is analogous to TDD and a more fitting name for us (should we write the book) would be The Blind Architect.
No comments:
Post a Comment