Aladdin Biyabangerd
WritingJava

What good backend code looks like to me

Written byAladdin BiyabangerdPublished:4 min read

It is nice when code looks good. Clean classes, well-named methods, a tidy package structure — all of that matters.

But the more real systems I build, the clearer it gets that good backend code is not only made of those things.

The code you will read tomorrow

To me, good code is code that tells you what it does quickly — tomorrow, when I open it again, or when another developer does.

  • A method name should say what it does.
  • The business rule should not be hidden.
  • Why a database operation happens should be obvious.
  • An exception should say more than “something went wrong”.

Above all, the code should not hide the behaviour of the system.

Not everything needs an abstraction

The longer you work with Java, the easier abstractions are to create.

  • You create an interface.
  • You create an implementation.
  • You add a factory.
  • You add a strategy.

And then a simple operation has you walking through five classes.

If an abstraction did not come out of a real need to change something, it sometimes just makes the code harder to read.

I am more careful with abstractions now. The problem comes first, the pattern second. Not the other way round.

Clean code means something else to me

For me, clean code is not short methods or fewer lines. Clean code is code that does not hide the business rule.

If a developer can work out from the code why a reservation could not be created, that is good design as far as I am concerned.

If finding out why an operation failed means following five separate layers, I see a problem there — even when the code looks technically “clean”.

Code is written to be changed

One of the most useful lessons I have had is this: code is not written only to work today.

  • Tomorrow a new requirement arrives.
  • A new field gets added.
  • The business rule changes.
  • Another service is connected.
  • Another developer opens the same code.

So the main property of good backend code, for me, is that it is not afraid of change. Looking tidy is good. Being changeable tomorrow matters more.