Question:
Currently I see that some frameworks , libraries and systems use the concept of convention over configuration, from that I raised the following questions
- What is convention over configuration?
- What are the advantages and disadvantages?
Answer:
It means that the tool is opinionated, that is, it decides what is good for you, in most cases. In general, decisions are made by engineers who are trained and experienced with that problem and know how to work best, but the tool lets you change this already agreed pattern and allows a different configuration than usual.
It is a way of establishing a default , making the work easier and inducing the most unsuspecting programmers to do the right thing, without preventing the necessary flexibility for non-standard cases that something different might work better if configured by a competent programmer.
With it you have to make fewer decisions and that's good or bad. It's good because it uses what's called get the things done . It's bad because it's common for the project to be simple, doing wrong things for that scenario.
In general, for the user of the tool, there are only advantages, he has it ready and doesn't have to think about the problem, there's no work, there's no risk of doing it wrong, without preventing another way to do it. It takes little or no work to use the convention and it takes a lot of work to set up something different, which you can still have ready-made conventions and you don't even need to do it, just configure what you want to use that way.
You can talk about a tangential disadvantage: the user will lose the chance to learn something, but that's only if he's not curious, the concept helps him tend to be lazy, but it's a matter of attitude.
A very big advantage for the user is the much lower learning curve, even if he goes from one project to another using the same tool, he tends to adapt to the new project more easily.
Of course, for the project it can have the disadvantage of the inexperienced or lazy choosing the convention when it is not the best solution. It can also complicate things a bit because it implies certain things and everything seems too magical, but again, it's up to the user to be curious.
Perhaps the biggest disadvantage is not the concept itself, but because in some cases it tends to make the project too inflexible and not meet everything you need with settings. It's more a question of how it's done than a premise of the concept.
For the tool it has the disadvantage of being a little more complex. But this is not so serious, or even bad because an alternative is just to have the convention that makes it simple but very rigid and not very useful for many people. Depending on the case it may be better for her to just have something simple with just the convention. On the other hand, doing it just the way the configuration requires without a convention is practically the same work, creating difficulty for the user.
It is common for these tools to require the project to be created within certain assumptions and even use certain file names or structure because internally it expects that. In a way this can reduce the complexity, so it depends.
If done well it is very advantageous if the tool demands it. If done badly the disadvantage is not hers, but her misuse, a convention that displeases most is not good.
In general they adopt the principle of least surprise (which is most likely to happen here).
Of course there can be abuse and it can be done poorly and the convention does not adopt "best practices".
This is present in complete tools or in very simple things. If you have a function that does something with a passed argument, but if it doesn't pass anything it still manages to do something useful by adopting a default value that would have been passed, that is, there is a convention that that parameter has a certain value in many cases, when you pass the argument you are configuring the function to do something a certain way.
It makes a lot of sense in frameworks because they control your application.