1. Focus on Design, Not on Frameworks
One of my goals for the future is to focus on the design of the projects and invest less time into learning all the ins and outs of cool-looking frameworks and libraries.
Before using any new library, I will carefully consider the problem at hand and evaluate whether the library is the most effective solution, as well as compare it to a potential solution using plain Java.
I recently published an article on this topic, in which I share some insights from Uncle Bob Martin and Christion Gorman before offering my perspective on the matter. If you are interested in finding out how to Quit Believing in Framework Magic, feel free to read through the article and let me know what you think!
To summarize, excessive reliance on frameworks and libraries can obstruct the clarity of our business logic, expressed in code. As the saying goes, “clean code reads like well-written prose.” If much of our code is scattered across configuration classes and properties files, it will be difficult to achieve this level of clarity.
2. Embrace The Domain
If we are hesitant to fully understand and embrace the domain we are working in, it becomes challenging to effectively communicate the business cases through code. It is important to not shy away from the domain and to avoid relying solely on technical jargon.
This is a funny website that generates names for your Java classes: try hitting “enterprisfy” a couple of times :)
It is mindblowing how many words we can use without truly conveying any meaningful information.
In conclusion, my second new year resolution is to dive deeper into practices such as D.D.D (domain Driven Design) and B.D.D (Behaviour Driven Development). Furthermore, I believe Uncle Bob’s idea about Screaming Architecture is really interesting and it can guide us in this direction.
3. Write Better Code Using Functional Style
In my opinion, a strong foundation of tests is key to good design. Especially when incorporating the considerations previously mentioned and using B.D.D.
For example, placing core logic into pure functions makes it much simpler to write executable specifications and use parameterized tests, which involve providing sets of input and expected output values.
Moreover, I am planning to start applying the Command-Query Separation Principle more rigorously and use immutable objects whenever possible.
Conclusions
These are the main practices I want to focus on in 2023. I believe they supplement each other nicely. The functional style will allow me to write better tests in a nice B.D.D. fashion, where you can focus on the use case and not on the implementation details.
Moreover, by eliminating unnecessary frameworks and libraries, we can work towards prioritizing the clarity of business logic in code. This aligns with Uncle Bob’s idea of “Screaming Architecture” where the business use cases are clearly and immediately evident.
Thank You!
Thanks for reading the article and please let me know what you think! Any feedback is welcome.
If you want to read more about clean code, design, unit testing, functional programming, and many others, make sure to check out my other articles.
If you like my content, consider following or subscribing to the email list. Finally, if you consider supporting my blog and buy me a coffee I would be grateful.
Happy Coding!