The more experienced the developer, the less the KISS principle is respected?

Question

Programming

There is a Keep It Stupid Simple principle.
But looking through some Laravel projects on github from experienced developers, there is a feeling that everyone has put everything on this principle.
A bunch of some folders inside the app, service layers, providers, repository, full of some traits. Each sneeze has its own class. Everything is tied to each other.
Someone is trying to make Symfony from Laravel.
I understand that seniors know how to do this, they know a lot of patterns, but why complicate everything?
Especially when the repository has a link to the site, and there ... a simple site with the documentation of some library.
That is, the creators of Laravel wrote a bunch of all sorts of abstractions and magic to simplify the task for developers, but then the developers also wrote their own, in my opinion, only because they can do it.
A junior in such a project is unlikely to be able to add something, and another senior will come and rewrite everything for himself because he thinks that this pattern is not needed here, but 3-4 others instead, for "convenience".
I will not give specific examples, so as not to throw a stone into the garden of a particular developer. But in general, this is the trend.
Please give an example of a correctly (observing best practices) written project on Laravel, in which there is nothing superfluous, if you know one.

Answer 1

The KISS principle does not mean that you should use the most primitive tools.
It means that it is not necessary to overcomplicate the system unnecessarily .
If you think like that, you don’t need higher education either: “Grandfather built excellent baths, although he was completely illiterate.
If you still do not understand the purpose of all these "layers, providers and repositories", this does not mean that no one needs them at all.
In order to simplify the management of the system, it must be complicated.
This principle applies to every field of human endeavor, from building rockets to running states.
The more complex the system, the greater the overhead for its management. Homepage with cats can and should be done by primitive means. In a large project, you must immediately lay down on future extensibility. That is, to divide the responsibility between the "rails" in advance.
And by the way. Code in which "everything is tied to each other" is very bad code. Actually, the purpose of all these "layers, providers and repositories" is precisely to make the components as independent as possible from each other.

Answer 2

The most common cause is "bicosis ai ken".
I somehow dealt with one authentication library based on Laravel (not Sentinel, there is a separate horror). Lord, the author screwed up 6 layers of abstraction for the sake of one `login()` operation. SIX, I'm not kidding. I broke my brain trying to figure it out.
Wrote to the author, yes. In response, I received "Everything is simple there, what do you not understand? (Further there were counterproductive insults)"

Answer 3

The more experienced the theme developer, he will better understand when and what to use.
Patterns, principles, etc. This is important for beginners. Then you begin to understand yourself.

Answer 4

What you called - repository, service layer, provider is not as difficult as it seems.
Repository is a layer above the model, usually one class for each model in which all the functions for working with the model are collected, i.e. all the necessary queries to the database through the model, so as not to write them in the model itself.
Service layer - a layer between the controller and the repository, usually one class for each model (repository). Here, they usually write the processing of data received from the repository so that later it can be immediately inserted into the view. As a rule, the service layer has methods create read update delete - as in the controller and they write the logic that was usually written in the controller only without being tied to the view.
Sevice Provider - some code that wanders from project to project and does, for example, user authorization or caching. Laravel has its own service provider mechanism.
As a rule, the service layer and repository are added to put all the logic there and keep the models and controllers very simple. For example, in controller methods there may be a banal call to service layer methods with a binding to view and no more logic.
Look at this example https://blog.eduonix.com/web-programming-tutorials... and it will immediately become clear.
There is nothing complicated in this approach, otherwise no one would use it.
You can try to write the same blog yourself but only with a service layer and a repository - it's easier than it seems.

Answer 5

They do everything right. It is impossible to "simply" make a complex project that is extensible and flexible. KISS is usually used at the initial development stage, when you just need to do it - then yes, it is indispensable. The deadlines are tight, and you’re sawing little things, no, you just need to code it, the client will smile, and then, you see, it will give time for refactoring.
Well, Laravel is cooler than Symphony, although somewhat slower.

Answer 6

0. Titles do not exist to determine the quality of the encoder, but in order not to pay more than
1.

A bunch of some folders inside the app, service layers, providers, repository, full of some traits. Each sneeze has its own class. Everything is tied to each other.

if there is no documentation and tests in the code or nearby, consider it to be shitcode
2.

But looking through some Laravel projects on github from experienced developers, there is a feeling that everyone has put everything on this principle.

on the other hand, there are projects on which you want to try something new, which of course should not be used there
3. Each such project should be considered separately and the theory about

The more experienced the developer, the less the KISS principle is respected?

not worth it

Answer 7

Just young developers complicate (they more often produce entities by imitating rather than thinking).
But experts with experience simplify. Simplification has two main approaches:
1. Do not do what is not required.
2. Divide and rule over what is required. Correctly dividing - we simplify.
As for the repositories. Business logic objects should not know where and how they are stored, how they are retrieved and saved. Then the business logic is easy to write and test. Just as easily, we can test retrieving or saving objects separately. Which leads to an easy change of storage. And while there is no standard for repositories and their interface. It can be minimal and added based on demand. No need to immediately write an interface for all occasions.
Sometimes it happens that business logic is simple. Take an object from one place and put it slightly modified in another. All the complexity will not be in the business logic, but around it. with repositories. One repository implements only the extraction into the general view of the object, and the second only the placement in the repository. And we know that if the API for one of the repositories changes, then the changes will have to be made only for it. We broke and rather wrote more code, but knowing that one API is raw or changing quickly, we have protected ourselves from the difficulty of making changes.

Answer 8

I understand that seniors know how to do this, they know a lot of patterns, but why complicate everything?
The most ridiculous excuse not to learn patterns :)

Answer 9

I'm afraid to run into butthurt, but I can't keep silent anymore.
The ability to build architecture does not depend on the experience of the developer (alas and ah). But, at the same time, the number of features, techniques, patterns and abstractions directly depends on the experience of the developer.
This leads to a disappointing fact: a dumb (read: not able to build architecture) developer begins to write more and more fancy shit code with age.
That's all I wanted to say.

Answer 10

The answer is in the question.
So inexperienced.
How many really experienced developers I know, and I know a lot of them - they always have everything extremely simple “under the hood”.
Another question is that developers with less than 10 years of experience consider themselves experienced ... Well, let them. In a few years they will think differently. "Oh, I was a fool..."
You can bet with them.

Answer 11

Just some kind of sadness ...
1. Your question is a cry to nowhere. Do you think I need to learn all this? No, you don't need to, you can work without this pattern. They are generally THEN understood. (sweat and blood, lol)
2. Kiss is not about the fact that patterns are not needed. It's about simplicity that YOU don't see. This very Laravel is sawed by a bunch of cool pykhers, they probably know better than yours (and mine, thank Buddha I'm not a pykher).
3. Please fuck off without these best practices. You other people, when you will do in their project, everyone will tell and teach.