The project I’m working on these days is not properly “legacy” but has seen some twists that renders it less than ideal.
On this project, one of the worst point that has been an obstacle for me to develop a simple feature is layered architecture. “What”, shout all experienced developers, “layered architecture is at the root of maintainability!” and I agree wholeheartedly. So, how could layer architecture be an obstacle?
- First, adding too many layers kill layering. I’ve always been a proponent of keeping the layers count low – especially DTO – when not strictly necessary. Too many layers and you will not only add complexity at development time but also performance overhead at runtime.
- Second, mapping is extremely important. If you completely change attribute names from one layer to another, newcomers are bound to endlessly scratch their heads.
- In all cases, the point of those layers is to separate code. So, keep it that way.
- Finally, if you need to do one (or all) of the former point, document it!
In my case, I stumbled upon an aggregation of all 4 points, as well as a previously unknown component (at least to me), jQuery template. This jQuery plugin is used to handle AJAX (but this is just a coincidence, as I suspect you could replace it with any equivalent and still get unmaintainable code).
Server-side, Spring MVC is the framework. A controller returns DTO which are processed through JSON converter. Guess what, JSON sent back by the server is mapped to another JSON entity client-side, one that has all fields of the original, but not all with the same name. Point 2 just makes it harder to understand what happens, and client means full-text search. Welcome into your new home…
Point 4: are you kidding?
Now that I’m slightly psychotic because of this feature I had to implement, and since I will know where you live in a not-so-distant future, I suggest you start designing your architecture by respecting KISS! This will render all aforementioned points moot and keep me happy.