Saturday, June 7, 2008

Not forgetting routine

Jett Atwood written a blog about The Greatest Invention in Computer Science and taking it from Steve McConnell, highlighted that routines is one of them. Reading the comments, it seems that not many supported his opinion. Personally, I will not debate on that as I think the scope is just too wide for Computer Science. But I will like to add some of my experience with them.

Learned about routines in the mid 90s when I first started programming in C, I am still religiously using them today in my OOP code. I think the article about routine brought out their importance which I have almost forgotten about them even I use them day in and day out in my code.

Recently, I was doing a lot of code review and was surprise that the concept of routines have been over shadowed by design patterns. Working on project that follows the Test Driven Development (TDD) Technique with a team that is pro to design pattern, some team members have similarly fallen into the design pattern panacea experienced by the author of the Refactoring to Patterns:
The power of patterns led me to lose sight of simpler ways to write code. After learning that there were two or three different ways to do a calculation, I’d immediately race towards implementing the Strategy pattern, when, in fact, a simple conditional expression would have been easier and faster to program-a perfect sufficient solution.

The pro here mean using design pattern without refactoring and doing it up-front with no added advantages that each pattern is suppose to promote. Logic is all coded into one single routine which not only violates the Single Responsibility Principle (SRP) and also increases the difficulties in unit testing. Therefore, I highlighted such code should be refactor into few routines with each routines having it own responsibility. I believe this is the basic of programming and should be practice before any use of design pattern.

I was also thrown interesting debate such as when writing everything in one routine instead of breaking them into a few routines, the call to a routine will not be duplicated. With further discussion, what was going to be duplicated after the refactoring will be one line of code. But this increases the chance of reuse.
Example: A routine that calculate value A and B using a complex formula which B is derived from a complex repository and value A is an input parameter. The calculation and the complex repository are all written in one routine. To separate the added responsibility, the derived of value B should be separated into another routine and probably pass into the calculation routine. But with this, if more than 2 places that need to call the calculation routine will also need to call the routine to derive the value B before the calculation routine. The call to the routine to derive the value B will be duplicated in these 2 places with one single line of code. But imagine the reuse of the calculation routine with a different derived value such as value C.

Writing many lines of codes in a single routine with multiple responsibilities, makes code reading, future refactoring and testing more difficult. So do not forget the basic concept of routine programming over the so called “flexible, sophisticated and elegant” of design pattern.

No comments: