Monday, November 28, 2016

Don't Repeat Yourself... Really!

...And I hope that someday
That you, you people will all have the chance
To read The Helping Friendly Book
And experience the wisdom
Of the great, the great and knowledgeable
Man who wrote The Helping Friendly Book 
Because he is, the great and knowledgeable
He is the one, the only author of The Helping Friendly Book
He is the man
The great man
The only, the special
His name is
The author of The Helping Friendly Book
He is the great
The knowledgeable, the one and the only
The great, the knowledgeable
Person who wrote The Helping Friendly Book
His name could only be
The one, the only, the only, the special
The author of The Helping Friendly Book...
-Excerpt from Icculus by Phish
There are few mantras that are as universally agreed upon by Software Engineers as Don't Repeat Yourself or DRY.  It rings deeply and globally true that any form of code duplication is at best a compromise, at worst, an abominable trap.  Writing and maintaining code is difficult enough without doing it many times.  So if we all know this, and we all agree, then why is it that the industry's preferred architectural best practices embrace duplication?

If you've ever built a controller, a repository, a service layer, a data access provider, or anything remotely like one of these things, you know exactly what I'm talking about.  Duplication is what you do.  You copy the logging code.  You copy the query strategy.  You copy the update methodology. You copy the attributes and data structures. You copy the exception handling pattern.  "That's how it was shown to you by smart people, so it must somehow be right," you think as you faithfully type away, all the while wondering if you've become little more than a digital version of a truck driver.

Like the proverbial cliff all your friends jumped off of according to your mother, it doesn't matter how bad of architecture you have seen, there is another, better way... so stop it!  But perhaps you're so used to following your lemming-like friends that you don't know how to escape the allure of duplication?  I'll offer some suggestions.

Existing Hooks and Abstractions

I've seen many applications that duplicate logging and exception handling, while being built in frameworks that provide easy to implement hooks for just these things.  At a minimum, know your tools.

Frameworks

There are new frameworks every day.  Most of them encourage repetitious coding practices and should be avoided, but some aim to automate patterns and escape the madness.  Don't use a framework just because everyone else is doing it, and if you do, at least learn how to extend it.

Aspect Orientation

Aspect Orientation or AOP is an approach that calls for applying on-the-fly code generation or similar to automate all similar patterns.  For instance, an AOP-based framework would be one which allows you to define once how logging is performed, and apply that across all service calls.  Note that Aspect Orientation isn't synonymous with code generation, there are clever ways to accomplish the approach using composition hooks or code injected at runtime.

Data Access Platforms

Most repetition in today's applications seems to revolve around data access.  It seems somehow accepted that most aspects of applications can be automated, but not data access.  Granted, it may seem difficult to orchestrate and automate proper concurrent access of data across all layers, but there are platforms like Dataphor have solidly proven that all aspects of data access, from user interface to storage, can be completely automated.  If your platform or frameworks do not automate it, don't settle.

Conclusion

Regardless of what you do, say no to pattern duplication and begin enjoying your work again.  Do it for the lemmings; do it for your mother!

No comments: