The original article is at the Agile In A Flash blog, and has slightly different wording. We adopted the phrasing from c2.com's page.
I was pretty jazzed about having this card in our project, because it really does capture almost all of the code values and most design principles all in four little rules. It has always been profound in its simplicity. I wish we were able to make all of our cards and articles as concise and deeply applicable.
My idea of a great teaching program would be to start with this card, a testing library, and a programming language. We would do some exercises following these rules. After doing some projects to get our testing and refactoring skills up to par, I would bring in the four big ideas one at a time, so we could see how to better focus our work. Then probably I would bring in the seven code virtues and SOLID. Then we would call it "a good start" and I would go home. The class could pick up books on continuous integration and refactoring, and probably be able to run on their own indefinitely.
Learning the language, frameworks, and operating system quirks would be the other side of the coin. Ideas and ideals sound simple until you get to some ugliness in the OS or the web server or browser oddities. That's when you go back to this card. With simple design, you can weather some pretty amazing technical crapstorms.
This card is one part checklist, one part process. The rules are in priority order (just like "make it run, make it right, make it fast, make it small"), and also in process order. Cool stuff, huh?
So, run all your tests. Write a new test. Make it pass. Look for duplication, and kill it. Do you and your current pair programming partner agree that it makes good sense as-written? If not, fix it. Now, do you have any leftover bits that you don't need, any architectural artifacts you can live without? Unnecessary round-trips? Extra "cool" technology you can do without? Run all your tests. Start over.
was here
ReplyDelete