|
Back around 1975 ± 2 years one of the programmers at the newspaper where we worked wrote a simple program he named GAME1. He put the .SAV (like .exe or .com) file of it (TOPS 10 system) in the system area. When one of the people in the sports department ran it, it printed "Files Deleted" and listed all the files in the area with pauses to make it realistic. Typing control C which would normally cancel a running program caused it to print "I can't do that" and it continued listing files. It had also sent a message to the operator who had been made aware of the program, so when he called for help the operator told him he couldn't kill it. He said later he became physically ill since those files were stories that were supposed to be printed in the next edition. No files were actually deleted and the program exited once the several hundred files in that directory had been listed.
|
|
|
|
|
Even the BSD works ! Looks like Microsoft was beaten on 'Cloud PC' service  .
Gilles Plante
modified 21-Apr-21 10:01am.
|
|
|
|
|
A small .NET Core API project...
30+ controllers, one for each table.
30+ services, one service per table.
30+ "repositories", one repository per table.
30+ files for constants, basically one constant string definition (ok, maybe 3 or 4) per static class.
30+ files for actual model entities. So why are you using Dapper instead of EF?
The "repositories" are basically passthroughs to the db context for CRUD operations, and because the project uses Dapper, somewhere in the code base is 30*4 SQL statements for each table's CRUD operations.
And given that the controllers, services, and "repositories" are manipulating tables, and it seems like they were hand coded rather than generated by a tool... 
And it seems so bassackwards to me. To me, controllers and services should be based on function, not table CRUD operations.
And while I haven't looked at the Angular  front-end, I suspect, from what I see of the back-end, that all the business rules are coded in the UI.
So, given that:
No integration testing to validate business logic.
It's actually quite clean, given it all follows a repeated coding style and practice. On the other hand, the lack of abstraction and the lack of any architecture other than the "controller-service" architecture baked into ASP.NET Core API just leaves me feeling sad and depressed.
And you do NOT want to know how much budget this project was given, that has been completely used up and the project is not anywhere near finished.  (We're talking just shy of six figures here.)
|
|
|
|
|
Well, while I totally agree with what you imply... I have been non stop fighting most time in most of my workplaces, to avoid this kind of over engineering, which seems to be a powerfully widespread gospel... And not just with junior devs...
To this day I still can't understand why people emphatically still "need" a (home made) "Per table Data Repository", when we have EF that take care of it all for you already!
In a way you can't blame the junior dev here, maybe he was using the (socially) safest architecture...
|
|
|
|
|
Super Lloyd wrote: o this day I still can't understand why people emphatically still "need" a (home made) "Per table Data Repository", when we have EF that take care of it all for you already!
Exactly!
|
|
|
|
|
I have nothing against using a repo per table, sometimes I do it. Sometimes, a repo will be for a task or some kind of logical grouping.
90% of dapper is just mapping from a table to a class, hardly any code involved. Even to generate a class to represent a table is trivial.
The advantage for me and working with different levels of developers is that its simple to understand, simple to find the correct repo and method. EF may be different now but for most things I don't need a full ORM and EF was a pain. I'm also perfectly happy writing my own SQL and if I need I can just add it to the repo. I don't see this as over engineering, it's pretty simple.
I used to be into EF but I found it harder and harder to justify it over a micro-orm. It may be different now and easy to setup, configure and use but still it's a layer I don't need.
I also have nothing against lots of controllers but I can't understand it being per table in your example, usually its for the UI and specific task.
I've always found it interesting why people use EF, personally I stopped using it when I couldn't justify to a client why I wanted to use it over PetaPocco (wow not thought of that for a while).
|
|
|
|
|
I've seen "senior devs" do this exact thing.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Super Lloyd wrote: I have been non stop fighting most time in most of my workplaces, to avoid this kind of over engineering,
Please refer to this as pseudo-over-engineering or pseudo-engineering.
This is the type of "architecture" which is actual artifice or facade layer that is totally useless.
If the architecture doesn't somehow enable :
1) less code to be written (thus making enhancements and fixes easier)
2) make the code more reusable (and is actually going to be re-used)
then it is Crapitecture.
Just because some took a doghouse and placed it at the top of a 300 foot tall concrete tower does not make it a skyscraper.
|
|
|
|
|
raddevus wrote: it is Crapitecture
This new pattern deserves a book written about it!
|
|
|
|
|
EF is a whole other set of problems.
|
|
|
|
|
Where was the Lead. The person in charge is to blame, not the junior devs.
Mentoring, Design reviews, standards.
|
|
|
|
|
Marc Clifton wrote: it seems like they were hand coded rather than generated by a tool...
No, they were generated by tools. 
Marc Clifton wrote: No integration testing to validate business logic.
IOW, they have no idea whether the code implements the required business logic! 
I'll bet that connection strings, passwords, etc. are all hardcoded, as well.
I'm certain that we all wrote bad code when starting out, but this is exceptional!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: IOW, they have no idea whether the code implements the required business logic!
I might have missed it in all the other boilerplate stuff.
Daniel Pfeffer wrote: I'll bet that connection strings, passwords, etc. are all hardcoded, as well.
Thankfully not.
|
|
|
|
|
Sounds like a perfect case for code-generation by a tool, instead of throwing workers at the problem.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
They just followed the logic.
which used to be the best approach? the multi layer approach, they "followed" that.
Which used to be the fastest ORM? Dapper, so, it might just be, let's continue using it.
|
|
|
|
|
My first thought with anything done by all juniors is did they enforce user roles at the controller/etc level, or just hide links to admin pages but let ordinary users do admin if they found/were given the URL?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
We do not fault dogs for acting like dogs. We intervene and train them patiently and consistently.
Same with junior programmers. They have likely learned the basics through college or other training, but there is so much to learn in the real world. That is why those of us who are team leads and software engineering managers have a responsibility to mentor. Every code review is an opportunity to train. Whomever was leading this project should have managed it so as to keep this from getting out of hand. Topics like SOLID are principles, not laws. It takes engineering expertise, which can be taught, to know how to implement those principles for any given project.
Of course, sometimes a team lead is not given the authority to mentor and manage projects, which can lead to this kind of thing. An old adage that is true in any time frame, is this set of illustrative equations:
Responsibility + Authority = Success
Responsibility - Authority = Failure
It is unfortunate that junior programmers were allowed to roam free. Same when non-engineers manage software projects. Bad things happen. 
|
|
|
|
|
Have you worked for insurance companies too?
|
|
|
|
|
That's funny!  Programming these days is so complicated. School doesn't prepare you for the real world.
|
|
|
|
|
Patterns. Granularity. Just missing generics.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Errr. That's on you.
Don't expect a junior to have a clue.
Be a mentor, not an after the fact critic.
|
|
|
|
|
mattyltaylor wrote: Be a mentor, not an after the fact critic.
Oh, I am very much a mentor. Unfortunately I and my team are picking up this project having no knowledge of it until, well, now. So the damage was done a while ago.
|
|
|
|
|
Which is correct?
Egg Storage[^]
I am sooo totally a B person myself. And you put the carton in so the eggs are in the side closest to the person. So when you grab them they aren’t over balanced away from you and onto the floor.
I dislike A intensely. and I really do not know why.
My family is just wrong though. They don’t have a system. Grab them out of the middle half the time.
To err is human to really elephant it up you need a computer
|
|
|
|
|
You raised a very interesting and extremely controversial topic right there!  
|
|
|
|
|
Yes! It kind of reminds me of the "big endian / little endian" argument in the mythical Lilliput!
Get me coffee and no one gets hurt!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
