January 8, 2011

...Learn TDD with Codemanship

H.O.R.I.D.D. Design Principles For Refuctoring

Today's TDD workshop (day #2 tomorrow) has jogged my memory about Mortgage-driven Design Principles. Just as refactoring is underpinned by design principles for good, clean code, refuctoring has it's own underlying principles that can help guide our efforts to make code less maintainable.

They are:

Heterogeneity - the more paradigms, mixed metaphors and different languages and frameworks we can cram into our code, all the better for making it incomprehensible.

Obfuscation - making class, method and variable names meaningless is a classic refuctoring strategy. Appreviate widely-known words (e.g., "World" can be abbreviated to "Wd") and then decorate them with apparantly meaningful annotations (e.g., "m_", "str", "obj")

Redundancy - in his excellent "Designer Code" workshop at SC2010, Chris Parsons includes some clever redundancies in his code. Expressions like "if(X && true)" (i.e., if(x)) can be useful in this regard. Better still when mixed with some indirection by hiding the "true" inside a maze of method calls.

Indirection - a very powerful tool in refuctoring. If the meat in the sandwich is actually in another sandwich, sandwiched between two more sandwiches, and the meat is actually a piece of paper with "This voucher can be redeemed for a slice of ham" written on it (in Serbo-Croat, in invisible ink), then you can rest assured nobody's going to be making any changes to that meat in a hurry. As long as you remember where the treasure's buried, that's the main thing.

Duplication - some software is just too small for what it does. Some judicious copying and pasting and carefully-applied inlining of expressions, methods and even entire classes (because it's so much better if the database connection code is in every data access object) can turn a slimline 50,000 LOC application into a 500,000 LOC headache.

Deception - why do some old folk hide their money in a jar labeled "Cookies"? Because surely cookies go in a cookie jar? Names imply a lot, so use names to put other developers off the scent. They're less likely to find the code for generating customer emails if it's hidden in a method called "validateCustomerPassword".

As an aide memoire, I use the acronym H.O.R.I.D.D., because code that obeys any or all of these principles most certainly is.

As Keith Bank-Account might say, "cushty".

Posted 7 years, 3 months ago on January 8, 2011