Regular readers of this blog know I’m a big proponent of the Spring framework, but I’m quite opinionated in the way it should be used. For example, I favor explicit object instantiation and explicit component wiring over self-annotated classes, component scanning and autowiring. Concepts Though those concepts are used by many Spring developers, my experience has taught me they are not always fully understood. Some explanation is in order. Self-annotated classes Self-annotated c
Let's face it, most developers - myself included, prefer to deal with code than with people. However, when communicating with other developers, we share a common context and understanding, which makes a lot of explanations unnecessary. It's the same for all specialized jobs, such as lawyers or civil engineers.
Most of our day-to-day job is learned through mentorship and experience and not based upon scientific research. Once a dogma has permeated a significant minority of practitioners, it becomes very hard to challenge it. Yet, in this post, I'll attempt to not only challenge that sometimes tests must be ordered but prove that in different use-cases.
If you listen to other language communities - such as Python or Ruby, it seems Java developers have a strong tendency of over-engineering. Perhaps they’re just jealous of our superior platform (wink), perhaps there is some very slight reason that they believe so. I do believe so. And it’s quite interesting that I realized it by doing code review - while I may be guilty of over-engineering myself when writing code. But I’m working on it. Of course, you’re a 'simple' dev
This week, I've lived again an experience from a few years ago, but in the opposite seat. As a software architect/team leader/technical lead (select the term you're more comfortable with), I was doing code reviews on an project we were working on and I stumbled upon a code throwing a NullPointerException: that was a big coding mistake. So I gently pointed to the developer that it was a bad idea and that I'd like him to throw an IllegalArgumentException instead, which exactly the exception type m