The Testing Spring Boot Applications Masterclass is a deep-dive course on testing your Spring Boot applications. You'll learn how to effectively write unit, integration, and end-to-end tests while applying Spring Boot's excellent test support. 

Up until the 21st of March, you'll get two bonuses (book & additional course) at no extra charge when enrolling for the Masterclass.

Have you come across the dreaded OutOfMemoryError, yet? If you've been spared so far, this won't last forever. At some point it will come and you will wonder which of the 300.000 lines of code is responsible for the memory leak.

In this new article, Pratik explains how to create and analyze a heap dump to find the memory leak.

As software developers, we're painfully aware of technical debt. 

Usually, we curse our predecessors for taking shortcuts, making wrong decisions, and for just not working professionally in general.

That's unfair, of course. Whoever wrote a piece of code that is technical debt in our eyes had to work with the knowledge and in the constraints of the time when they wrote that code. There probably were time constraints and technical constraints (among other constraints) that we have collectively forgotten about today.

But still, when we get the chance to start a new codebase or a new module within a codebase, we say to ourselves that we're going to do it better. We're going to build something that our successors will praise us for. We even proudly put our name in the header of the source files!

But then the constraints hit us. People start asking us when it's done. The API we're using turns out to suck and we need to build workarounds.

That's life. We can't control everything. But that's not a reason to give up on the things that we can control.

When we start something new, we have a responsibility to make things as good as we can, in the constraints that we can't control. If we skimp on the things that we can control, our successors are right to accuse us of being unprofessional. 

Some things that we can usually control when starting a new codebase or module are:

• documenting the decisions why we did what we did
• explaining the high-level architecture with a diagram and some text
• structuring our code into modules 
• leaving a README in the repository
• doing another polishing pass over the code to improve things like readability and naming
• explaining the domain model in comments
• ...

Every line of code we're creating is legacy code for the next developer. Take the time and review your own code after a day or two and ask yourself what you would want the code to look like if you had to work on it a year from now.

Chances are that your successors will still curse you for the things that you didn't have control over, but at least you can sleep at night.