One topic I’ve never found a perfect solution for is “how to document the architecture?”.
I’ve recently started a Spring Boot local meetup here in Frankfurt. We already had a great start with a talk about “Moving from Java to Kotlin with Spring Boot”. It was great to get first-hand experience from devs who already work with the Kotlin-Spring Boot combination.
DRY is another principle and commonly riding along the other two. DRY stands for don’t repeat yourself; meaning “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” aka writing that piece of code, schema, whatever once for the entire system and re-use. Don’t duplicate code if it’s logically related.
Another true principle of our craft is YAGNI - You ain’t gonna need it.
One of the key principles we devs violate way too often. We devs love complex systems too much.
For those unfamiliar with the acronym and principles. It stands for Keep it simple, stupid.
I am a firm believer that anyone should have a side-project. It does not matter if it is for pure learning purposes, fun or with the goal of making money.
Sometimes, we have to measure the execution time of certain code blocks. The traditional way would be to capture start and stop time with System.nanoTime() and print out the difference.
Works, but gets messy when you try to capture more than one time.
I bet your answer will be something like “yes, definitely, or are you crazy?”.
I’ve started helping out on a pretty old legacy system. It’s in its second decade and probably not far away from 20 years of existence. It went through many developer hands, everybody leaving its mark on it, myself included. There have been several attempts to reinvent it or at least parts of it, but none has been really successful so far. It is a mess, but it still works.
I covered properties handling in Spring Boot a while ago in my Learnletter. This page summarize all emails to make it easier for you to dive into the topic.