If you have to add a new feature to an existing code base, you’ve likely already experienced an uncomfortable truth: Nobody has thought about your use case. Nothing in the existing code base fits your goals. This isn’t because everybody wanted you to fail, but because your new feature is in fact brand new to the software and responsible software developers stop working on a code as soon as their work is done (while obeying the project’s definition of done).
So you try to shoehorn your functionality into the existing code. It’s not neat, but you get it working. Are you done? In my opionion, you haven’t even started yet. Your first attempt to combine your idea of the best implementation of your functionality and the existing system will be cumbersome and painful. Use it as a learning experience how the system behaves and throw it away once you get a working prototype. Yes, you’ve read that right. Throw it away as in undo your commits or changes. This was the learning/exploration phase of your implementation. You’ve applied your idea to reality. It didn’t work well. Now is the time to apply reality to your idea. Commence your second attempt.
For your second attempt, you should make use of your refactoring skills on the existing code. Bend it to your anticipated and tried needs. And once the code base is ready, drop your new feature into the new code “socket”. Your work doesn’t need to be cumbersome and painful. Make yourself comfortable, then make it work.
Here is a example, based on a real case:
An existing system was in development for many years and worked with a lot of domain objects. One domain object was a price tag that looked something like this:
interface PriceTag {
PriceCategory category();
TaxGroup taxGroup();
Euro nettoAmount();
Product forProduct();
}
Well, it was a normal domain object giving back other normal domain objects. The new feature should be an audio module that could read price tags out loud. The team used a text-to-speech synthesizing library that takes a string and outputs an audio stream. No big deal and pretty independent from the already existing code base.
But the code that takes a price tag and converts it into a string, aka the connection point between the unbound library code and the existing system, was ugly and undecipherable:
String priceTagToText(PriceTag price) {
return price.forProduct().getDenotation()
+ " for only "
+ CurrencyFormatter.format(price.nettoAmount())
+ " with "
+ String.valueOf(price.taxGroup().percentage())
+ " % VAT in the "
+ price.category().getDenotation()
+ " section.";
}
This is how it looks if somebody tries to combine two building blocks that aren’t meant for each other. To test this method, you’ll have to mock deep into the domain objects.
If two building blocks aren’t matching naturally, maybe it’s an idea to add some lubrication code between them. This code isn’t exactly doing anything newfound, but adds a requirement seam that point towards the existing system:
interface ReadablePriceTag {
String denotation();
String netto();
String vatPercentage();
String category();
}
You can probably already see where this is heading. Just in case you cannot, I will take you through all parts of the code.
First we can write a priceTagToText() method that reads a lot nicer:
String priceTagToText(ReadablePriceTag price) {
return price.denotation()
+ " for only "
+ price.netto()
+ " with "
+ price.vatPercentage()
+ " VAT in the "
+ price.category()
+ " section.";
}
The second and complementary part is the implementation of the ReadablePriceTag interface that is given a PriceTag object and translates the data for the new methods:
class PriceTagBasedReadablePriceTag {
private final PriceTag price;
PriceTagBasedReadablePriceTag(PriceTag price) {
this.price = price;
}
@Override
public String denotation() {
return this.price.forProduct().getDenotation();
}
@Override
public String netto() {
return CurrencyFormatter.format(this.price.nettoAmount());
}
@Override
public String vatPercentage() {
return String.valueOf(
this.price.taxGroup().percentage()) + " %";
}
@Override
public String category() {
return this.price.category().getDenotation();
}
}
Basically, you have a lot of existing code that is using PriceTag objects and some new code that wants to use ReadablePriceTag objects. The PriceTagBasedReadablePriceTag class is the connector between both worlds (at least in one direction). We can definitely argue about the name, but that’s a detail, not the main point. The main points of all this effort are two things:
- The new code does not suffer in quality and readability from decisions made at a different time in a different context.
- The code clearly models these contexts. If you are aware of Domain Driven Design, you probably see the “Bounded Context” border that crosses right between PriceTag and ReadablePriceTag. The PriceTagBasedReadablePriceTag class is the bridge across that border.
If you express your context borders explicitely like in this example, your code reads fine on any side of the border. There is no notion of “old and fitting” and “new and awkward” code. It seems like additional work and it surely is, but is pays off in the long run because you can play this game indefinitely. A code base that gets more muddied and forced with time will reach a breaking point after which any effort needs knowledge in archeology and cryptoanalysis.
So, my advice boils down to one thing: Make yourself comfortable when adding new code to an existing code base.
And then, think about your type names. PriceTagBasedReadablePriceTag is most likely not the best name for it. But that’s a topic for another blog post. What would be your name for this class?
Schneide Blog 