It's ironic to me that the "Hammer Factory Factory Factory" post was recently doing the rounds again.
I have recently been working with a client whose "senior" dev swallowed some books with opinions on "quality" wholesale and uncritically.
Thus in the simplest project, implementations that could literally be a lambda function (on receive message, write row into DB) are a festival of multiple tiers of objects, mappers, mediators, IoC frameworks, wrappers, Nuget packages, etc., etc.
Everything is in multiple projects. Simple constants (like: API routes - '/api/foo/bar') are indirected into files containing those strings, so there's a huge cognitive overhead and much clicking around to make sense of it. God help you if you don't use an IDE.
This isn't quality. It's the antithesis of quality. Devs have to understand a whole load of abstractions just to get simple things done. But the author is proud of his tower of 'best practice' - blissfully unaware that adding the simplest feature is now hundreds of lines of code, where one would suffice. This is burning through, literally, thousands of euros of dev time.
But... what the OP writes are strong conventions, no?
Coming from Spring or Java EE:
> implementations that could literally be a lambda function (on receive message, write row into DB) are a festival of multiple tiers of objects, mappers, mediators, IoC frameworks, wrappers, Nuget packages, etc., etc.
Spring or Java EE is a strong convention, so IOC is one automatically as well (both make use of that heavily). Hibernate would be the next strong convention, therefore mappers are, therefore we will have multiple tiers of objects. Wrappers will also be needed in a language like Java. About the rest of this list I can't say much now, but I would argue that lots of what this person is doing is based on strong conventions in the enterprise world. And it goes on:
> Everything is in multiple projects. Simple constants (like: API routes - '/api/foo/bar') are indirected into files containing those strings, so there's a huge cognitive overhead and much clicking around to make sense of it. God help you if you don't use an IDE.
Coming from Java again, everything won't be in multiple projects, but in multiple Maven modules instead. AFAIK that is good practice, or, if you want: a strong convention. Stuff like API routes will indeed not be saved in a code file, but in an openapi file instead.
IMO then, what this person was doing was actually following strong conventions. Yes, these are often also specific patterns, but what is the difference, specifically for these things listed here?
It seems to me much more that the person was probably "limited" more by the language. I think there are fairly good reasons for all of these, especially when working with more than ten people - in a language like Java. And in this case you will have to use Java (or something similarly famous) because otherwise you won't find a replacement very quickly that is fairly cheap. Now, maybe the person would not have needed all this in such a small project that is just for one person. But who knows, maybe the project grows. Or maybe this person was simply familiar with this and could get this down fastest. All in all, I think there are many good reasons to decide to make a project with patterns/conventions like this.
It's ironic to me that the "Hammer Factory Factory Factory" post was recently doing the rounds again.
I have recently been working with a client whose "senior" dev swallowed some books with opinions on "quality" wholesale and uncritically.
Thus in the simplest project, implementations that could literally be a lambda function (on receive message, write row into DB) are a festival of multiple tiers of objects, mappers, mediators, IoC frameworks, wrappers, Nuget packages, etc., etc.
Everything is in multiple projects. Simple constants (like: API routes - '/api/foo/bar') are indirected into files containing those strings, so there's a huge cognitive overhead and much clicking around to make sense of it. God help you if you don't use an IDE.
This isn't quality. It's the antithesis of quality. Devs have to understand a whole load of abstractions just to get simple things done. But the author is proud of his tower of 'best practice' - blissfully unaware that adding the simplest feature is now hundreds of lines of code, where one would suffice. This is burning through, literally, thousands of euros of dev time.