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.
As you may notice above, I have decided to open up the newsletter for sponsors. This edition is the first sponsored edition. This will help me to keep up with my goal of one quality article per week - if there's one thing I learned in the last year, it's that good content costs time and money :).
I'm very mindful of choosing sponsors that bring value to you, though, so I'm hoping that you will find the sponsoring ads interesting rather than annoying. Let me know if you think otherwise!
If you have something interesting to say to the 2500 Java developers on this mailing list, feel free to reach out and we'll have a chat.
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.
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.
37 Mountain View Cr. NSW, 2125 West Pennant Hills Australia
You received this email because you signed up on our website or made a purchase from us.