Programming Chi is a blog about pitiful ideas, bugs and failures I notice every day. Fortunately, besides failures there are also a lot of successes and beautiful solution which I hope I will also write about.
To efficiently develop software, it is crucial to control its quality, particularly the architecture and code structure. In Java, ArchUnit, a library for testing certain aspects of architecture and design, can help. In this article, I'll present ten practical ArchUnit tests based on my experiences with developing a Spring Framework-based application.
In the world of software, modularization is crucial for maintaining flexibility, scalability, and code readability. I have participated in many discussions about the ideal size of a module. These discussions often feature extreme opinions, ranging from "it's better to have a few large modules" to "the smaller the modules, the better". The truth, as always, lies somewhere in between, and in this…
Modularization in projects is one of the key techniques that allows for maintaining code readability, scalability, and ease of maintenance. As projects evolve, especially those with a larger scope, it becomes an important element ensuring order and transparency in the code structure. However, as the project progresses and new changes are introduced, and developers come and go, it's easy to forget…
The Open-Closed Principle, described in SOLID, ensures project flexibility, but does it always lead to optimal, future-ready code? It sounds promising - open for extension, closed for modification. Let's take a closer look.
In recent years, service architectures, especially microservices, have gained enormous popularity, yet the approach to end-to-end (E2E) testing often remains unchanged. We hear that tests verifying the operation of the entire system are crucial in the software development process, especially with distributed architectures.
In this post, I'd like to present my three-point approach to tasks and problems related to documentation.
Checkstyle is a powerful library that not only allows standardizing code formatting in a project but also catching some program errors (e.g., whether the equals method is implemented along with the hashCode method) and code design issues (e.g., maximum method size or cyclomatic complexity).
This post is a brief story of how good intentions can lead to disaster when forgetting about JVM's internal mechanisms and how, once again, Kent Beck's approach - "Make it work, Make it right, Make it fast" - came into play.
On this blog, I sometimes touch upon taboo subjects like in post *Optional as a Field and what are you going to do to me about it?* This time, it's about static public variables. Much has already been said about the harm their usage has inflicted on the world. In this post, I'd like to analyze a specific case of their usage, namely metrics...
It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so. -- Will Rogers