Software Design
In addition to architecture, another thing that I’ve recently begun to love talking about & researching is generally software design. I just honestly strive for the best I possibly can, such as reducing cyclomatic complexity. I know, a fancy word, right? In plain ol’ English it means reducing the amount of logical operations in a given body of code. These days I try to ensure that I try to make my code almost as readable as a book, within reason of course.
An example of some simple ways in which you can increase the cleanliness, simplicity & consistency of your code is by taking advantage of ideas such as a guard clause. You could, in theory have some design pattern in place where you have some process(es) that have some guard property, this could be injected via dependency injection, etc. This mechanism alone can make your code more concise & much cleaner, by using a guard clause, you could quite literally abstract some set of logic from a complex method or set of methods. This alone is a technique that I personally like since it can make your code-base so readable, so simple, almost elegant.
One significant advantage to keeping your code clean, concise & simple is that it makes it super duper easy to test, plus it also means that your code coverage can go up like no tomorrow with quite little effort. Another little trick I have up my sleeve is by using tools like Lombok, it allows you to implement the likes of entity classes or DTO classes without all the bloat of having getters & setters implemented manually. I also love how easy it is to implement the likes of builders, which I also find improves the cleanliness of the code-base, since you can chain methods & whatnot.
I find that following design patterns also improves the quality, since developers do, or at least should know what functionality is associated with what class based on the name alone. If you’re utilising very generic names & if you’re not utilising real/proper design patterns, then in my honest opinion you’re ultimately setting yourself up for failure to some extent or another. An example being the use of the worse service i some class name, depending on the context, a service can mean different things, whether it’s the service that I often think of. An example being the controller-service-repository pattern, here’s some documentation around the service annotation that can be found within the Spring ecosystem.
I also like to utilise the likes of adapters, while it’s still fresh in my mind, I would highly recommend using this website for a great reference when looking at design patterns. But specifically when looking at the adapter design pattern specifically, I find it insanely common, so much so that I often tend to create factories around them, if not sometimes some form of strategy pattern around them, you get the idea.
In addition to general design discussion(s), another idea that I’ve fallen in love with is AOP, I won’t go too far into AOP, what it is & how it’s so epic, if you’d like to learn more, here’s a good starting point. I find that through careful utilisation of AOP, you can very easily improve the cleanliness of your code. Since through clever design decision, you can essentially ensure that blocks of your code can run without making any obvious reference to another block of code, increasing encapsulation, etc. Of course with ideas such as this, there’s a fine balance since it can be very easy to essentially abstract blocks from each other so much so that it can be hard to debug or hard to make sense of, etc.
