Bla-bla driven development now prevails. Today, I want to introduce my own developing way: CDD(Checking-Driven Development).
CDD resembles TDD (Test-Driven Development) but is a little bit different on its soundness. As TDD generates code fastly and concisely otherwise CDD constructs the code on the strong ground. That is, CDD generates the code slower than TDD, but it can prevent most critical bugs in advance. Let me explain it further.
It focuses on checking and removing duplications including data dups and proc dups. You can check them in a ROUND. In every round, there are three steps to do:
1. Construct a small, unduplicated structure and test it within initial, medium and final state.
2. Search for dups out of the round.
3. Remove dups and replace it with better abstraction.
It seems like making a decision. When we have a meeting about some agenda, we firstly set a goal of the meeting. That really helps and propels the discussion but something would be missing: repetition of the same thing uselessly. Even though one thing is determined, that can be changed by other agenda (because we normally miss the relation among the subjects and they crash in some time).
I hate duplication and hope you too. Duplication may incur the breach of security rules and damage integrity. And I could avoid lots of dup-problems by CDD and couldn’t find any problem in it except keeping-deadline problem. In some business, it may not be a proper solution but I convince that it is a sort of cool methods to develop application.
