Declaration Driven Development: part 1

The day I started learning refactoring, I fell in love with it. I got so addicted to it that I have developed a new habit automatically which not only makes refactoring an easy task, but also saved a huge amount of time when I write some complex algorithm or business logic. It’s a refactoring-integrated process of programming.

So far, though I need more experience and data, the process is much faster than programming without refactoring (the thing we do in the first run). Because while you code this way, you only need to focus on one thing – either the overall picture, or a tiny unit of work. In addition, it saves the time that you would otherwise spend refactoring later in the code’s life-cycle. Because for that you will need to read the codes again, find out what to refactor, do some operations, remove duplicates, and write more test codes – and that’s so much that people do not want to refactor often.

Initially, I wanted to name it “template driven development”, but the template is already have been taken by one of my favorite design patterns – template method pattern. So, not to confuse readers with that one, I would like to call it “Declaration Driven Development”. It can also be called “Command Driven Development”.

Here is my habit:

  1. Whenever I see I have to write a single unit of work inside a “big method” (anything from and over a line can be big if, it’s too complex), many a time when I’ve already written a couple of lines of it, my fingers automatically deletes the lines and calls a new method which doesn’t exist. So, I have given a command before introducing it.
  2. Then I just right click on it and generate it without any actual body. Good IDEs are smart enough to generate dummy methods which are compile-able. It happens after the method “call” is written.
  3. Then I keep going on working on the old method. I don’t even move to the new method at all most of the time.
  4. And when I am finished with the old method, I check if the solution or algorithm makes sense to me.
  5. If everything looks good with the “big picture”, I just forget about it and jump into the dummy “unit” methods and write them without having to worry about the overall logic.

Okay, now you can say, the output is just a refactored code. Yes, indeed. But the way to produce the code is a new process. So, I am only talking about the very process which is different from the popular and obvious refactoring approaches.

The main advantage that I get from this process is that I only need to focus on one thing at a time. The single responsibility rule needs to add “focus” to its domain. Now it has become habitual of me and I do it without thinking.

There are 3 clear advantages of it

  1. The code is produced refactored.
  2. It helps to clearly see the logic behind a fat method.
  3. It’s faster as you need less stress in developing complex solutions.

I need more data to prove the advantages that I presumed. Please, let me know whether it works for you or not.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s