Taking Out The Trash

We've all been in the position where we have no choice but to have something smelly in our code base.

We may have to integrate with a 3rd party library, we may have inherited some legacy code to cover some complicated piece of custom logic or we may be butting up against a badly implemented section of the OS were running on.

No matter what the source of the smell is we need to try and isolate its impact on the nice clean code we're so proud of.

Let us approach this from the point of view of the impact this sub-optimal code has on our architecture or design.

Its more than likely that this code also contains defects but in most of these situations we aren't able to fix it because we don't have or maybe don't fully understand the source code.

Get It Behind An Interface

One of the biggest impacts this trashy code can have on our code base is by having a badly designed interface.

This bad interface is the conduit through which the smell can spread into the rest of our code, bad practice in the interface leads to bad practice everywhere the interface is used.

It may even be that the developers of the smelly code didn't use an interface driven design, meaning not only is the code bad but it reduces the testability of the code that depends on it.

Get the bad code behind an interface that we can control, this will enable us to craft this interface properly resulting in every class that depends on it being clean and smell free.

Their may well need to be a wrapper class to implement the interface but here we can hide the hacky-ness required to use the bad code in one place so it isn't infesting the rest of the code.

Isolate The Smell

Its important that the bad code isn't spread through out our code base, it needs to be in as smaller a number of locations as possible, and these locations should be closely related.

Ideally the smell would be isolated to one layer of your code and arranged so that as few are classes as possible directly depend on it. We should be looking to put distance between the important logic in our code base and the bad code.

This distance allows us to filter the smell as it moves up the layers such that the air is fresh once we get to the critical parts of our code.

Plan To Rip It Out

In many cases it may not be possible to remove the bad code, we have to use this 3rd party, we have to deploy to this OS or we don't have time to re-factor that legacy code.

Even so taking the approach of planning to remove it well help in isolating its impact.

Once were at a point where we could switch out that smelly class we'll know we've done all we can.

The chances are if we get to this point we've ensured the rest of our code base remains testable, despite the bad code, and we've ensured that the clean code is as loosely coupled to the bad code as possible.

Its an important life lesson for all developers that not everyone takes as much care over things as you, some people do it wrong. An effective coping mechanism for dealing with this situation is an important skill.

Whenever you know you will have to integrate with someone else's code assume the worst and plan to protect your code from something you didn't design.