Hi all, today I would like to share with you a personal project, that has nothing to do with IT, but a lot in common with refactoring ideas.
Music composition and orchestration, is my great passion, and in the last years I have been putting it apart for more other concrete things. But I never garbaged the idea to continue to compose music, and maybe one day do it at professional level, so finally I decided to bring back to life this passion and here it comes: The First Touch.
A while ago I wrote about few design paradigms to keep in mind when designing and implementing a certain component. Among them, the famous K.I.S.S. (Keep It Simple, Stupid) kept on appearing as a valid and reasonable one. I then realized though how dangerous KISS can be when used by junior developers or, more generally, as a religion: it is pretended to be true and right, without further explanations, and hence in the name of KISS we get to justify almost everything. Often wrongly. The main concern is about what simple means in a certain context and whether that meaning breaks any other valid paradigm or, more precisely, your (technical) common sense.
We might probably apply the same reasoning to other paradigms as well, indeed correct design pattern and paradigms appliance always depends on the given contexts, but KISS seems to be a special case, because we can actually use it everywhere, anytime, in the name of simplifying things. But, are we really simplifying things? Read More
Soon or later we all experienced the comfortable feeling of test green lights, assuring a non regression after a change on a critical component or right after a refactoring which impacted several internal interactions. It’s probably the main advantage of having a good test coverage over your project as part of a continuous integration build system: tests may not spot bugs immediately indeed, but they should in most of the cases quickly alert about a broken functionality and any important regression. Therefore, we want and we need to rely on unit tests, we want and we need to have proper and effective unit tests then.
Let’s hence try to list some important aspect of a good unit test which will definitely improve the quality of what is supposed then to prove the quality of your build (nope, we are not talking about any meta-quality though). Read More
Design a domain can be a real challenge. A lot of bad practices can easily bring you to a bad design, and in most of the cases those issue will be discovered only after the advanced phase of business logic development.
Fortunately there are several approaches and “philosophies” for good design, like Domain Driven Design by Eric Evans.
What I would like to point out in this post is that not always Redundancy can be avoided, and that not always it is bad. I will discuss about the reasons of that after having presented all that cases where Redundancy should really be avoided.
What is Redundancy?
Let’s start by analyzing Redundancy in Database and Domain modelling.
Even if for any reason you cannot apply nor introduce Agile methodologies in your organization, there are of course still important points to focus on and daily share, little by little, as a personal (and professional) mission to improve project productivity and team sustainability. The Agile manifesto already stands for a brief but complete list of lessons to learn and follow which however may be strongly restricted by corporate management and existing delivery patterns (customer relationships, documentation, release cycle, etc.). The Scrum framework though better empathizes three keys pillars which go beyond Agile practices and can indeed be applied to almost any type of complex project life-cycle and team leadership. Let’s analyze them.