This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Design (Domain-, Test-, and Client-Driven)
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
Domain Driven Design in action: Time and Moneylibrary Java, open-source. Looks to have pretty complete unit tests, since it's written by Eric Evans, Martin Folwer and others, I expect most -- if not all -- of it was developed test-first.
An essay on Test Driven Development [aka Test Driven Design aka Client Driven Design] motivated by a cartoon that got it all wrong. Quotes:
...So let's just go over some of that conversation again, starting with a few quotes to warm up:
âThe act of writing a unit test is more an act of design than of verificationâ - Robert Martin
âTest-driven development seeks specification, not validation, letting you think through your design before you write your functional codeâ - Scott Ambler
âTest-Driven Development is a powerful way to produce well designed code with fewer defectsâ - Martin Fowler
âFewer defects, less debugging, more confidence, better design, and higher productivity in my programming practiceâ - Kent Beck
There's obviously a common theme here :)
... Test-Driven Development is about design. It might as well be called Test-Driven Design. It might as well be called Client-Driven Design. Let's try that...
In Client-Driven Design, you design your classes from the perspective of the client. ... This is fine-grained or detailed design. This is what Jack Reeves is talking about in his 1992 article in C++ Journal called What is Software Design (by way of Martin Fowler's June 200 article, The New Methodology).
... In Client-Driven Design you refactor the code when you realize a better way to do something. Once you've refactored, a good way to know if you've broken anything is to simply execute all the client code [tests] you've written to help you design your API. If anything is broken, you'll know immediately.
... We donât like big steps. We've just spent a career learning that coding non-stop for hours without validating our design leads to wonky design that will make the rest of the system that much more difficult to build and understand.
Scott Bellware also responds to the question "I'm having a heck of a time understanding how to thoroughly exercise my class ... a class with one public method, which performs the majority of its work ... in private methods ... A class that provides functionality that is highly dependent on the state of a larger process, in which my class only performs one logical unit of work ..." etc. These questions mostly stem from trying to work with bad designs (one public and lot of private methods is the "Iceberg Class" (or "God Class" design smell), and from failures of imagination, or lack of experience with design patterns (for reducing coupling). If it's hard to test, it's a bad design. TDD forces you to make code that is easy to test, and thus helps you create a good design.
...In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design.... Planned Design is a counter to this....
Now the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. The first fault is that it's impossible to think through all the issues that you need to deal with when you are programming... Now some of these requirements problems are due to not understanding requirements clearly enough. ... Many unforeseen requirements changes occur due to changes in the business. Those can't be prevented, however careful your requirements engineering process.... So all this makes planned design sound impossible...
... People who refactor their code in the disciplined manner suggested by XP find a significant difference in their effectiveness compared to doing looser, more ad-hoc restructuring. That was certainly my experience once Kent had taught me to refactor properly. After all, only such a strong change would have motivated me to write a whole book about it.
... At a conference dinner, Dave and I talked with a vocal opponent of XP. As we discussed what we did, the similarities in our approach were quite marked. We all liked adaptive, iterative development. Testing was important. So we were puzzled at the vehemence of his opposition. Then came his statement, along the lines of "the last thing I want is my programmers refactoring and monkeying around with the design". Now all was clear. The conceptual gulf was further explicated by Dave saying to me afterwards "if he doesn't trust his programmers why does he hire them?". In XP the most important thing the experienced developer can do is pass on as many skills as he can to the more junior developers. Instead of an architect who makes all the important decisions, you have a coach that teaches developers to make important decisions. As Ward Cunningham pointed out, by that he amplifies his skills, and adds more to a project than any lone hero can.
... In order to work, evolutionary design needs a force that drives it to converge. This force can only come from people - somebody on the team has to have the determination to ensure that the design quality stays high. ... This will does not have to come from everyone...
... If you're in the development team, then you sense whether design is happening by the quality of the code base. If the code base is getting more complex and difficult to work with, there isn't enough design getting done. ... A project that does healthy refactoring will be steadily deleting bad code. If nothing's getting deleted then it's almost certainly a sign that there isn't enough refactoring going on - which will lead to design degradation.
Previous Topic
