L
L
low molecular macro2020-12-09 14:49:17
Programming
low molecular macro, 2020-12-09 14:49:17

DRY at any cost?

I'll start from afar - with a general question. Is it always necessary to strictly adhere to the basic rules and principles of programming? Will the disregard of such rules be considered low skill? Can this play a key role in the evaluation of you by the employer?
Why did I ask this question. In Youtube, I am taking a course of a web developer popular in the English-speaking environment. In the course of the course, there is the creation of a form for adding and editing products on the site. And this is the principle the author of the course adheres to: one form is created with all possible fields to fill in. Depending on who and for what purpose the form is used (the user sends his product to the admin for the admin to add it later / the user edits his product / the admin adds the product / the admin edits any of the products), parameters are passed to it. Based on these parameters, the form changes - it hides fields that should not be available to the user / the action address changes / the fields are automatically filled if an existing product is being edited, etc. And like, this is Don' t Repeat Yourself. Instead of several forms, only one is created. But! As for me (maybe it's just my lack of professionalism), the form becomes sooooo complicated, with a bunch of checks and sending various additional parameters in order to understand how and where to send this form. And the form itself becomes almost unreadable due to the large amount of logic added to it.
And so, it became interesting to me, is it really the way most serious programmers write? Do I need to accustom myself to this approach - DRY at any cost? Because I would most likely create multiple forms. Not one for every occasion. And for example, one for editing a product and one for adding a new one. And only then I checked with logic who is using it - the admin or the user. Yes, the forms are repeated. But the code would be much easier to read and less confusing.

Answer the question

In order to leave comments, you need to log in

9 answer(s)
G
GavriKos, 2020-12-09
@GavriKos

Is it always necessary to strictly adhere to the basic rules and principles of programming?

There is programming and there is business. That's all.

S
soloveid, 2020-12-09
@soloveid

It's not DRY anymore.
This is already an anti-pattern of God Object actually turned out.
The essence of the DRY pattern is to make it so that changes are required only in one place in the code
and it is not a pain when you have to go through and look for the same pieces of code and replace them.
In the case you described, a person is trying to solve another problem - so that all forms are similar to each other
or something similar and do not have to change 10 forms. And I agree, his solution is good only for him, others
will have a hard time supporting such code.

A
Adamos, 2020-12-09
@Adamos

To train yourself to follow *any principle* at any cost is stupidity.
Programming principles are just the accumulated experience of good decisions. But there are no solutions that are good in everything. Especially in programming, where conditions change dynamically, and it is simply impossible to predict them all in advance.
Maybe a single form for all cases will be very convenient when you need to change the design of the entire site. Or maybe adapting logic that is not suitable for it to this monster will only gobble up a lot of time, and changing the design will be accompanied by a transition to a framework that will make this universal form simply meaningless. Now, while you are composing it, you cannot know it.
Therefore, one should not pray for principles, but look back at them when deciding how best to do here and now. And accept it not because you learned the principle, but because it helped you understand that it would be better that way. Or vice versa.

V
Vasily Bannikov, 2020-12-09
@vabka

> at any cost
Only the Sith make everything absolute.
And any principle should be applied when it is appropriate.
Everyone has already said about the fact that not always available resources correspond to the inner desire to "make everything perfect".
But DRY also sometimes contradicts KISS (the code can become more complicated) and YAGNI (the code will become brittle)

L
Lander, 2020-12-09
@usdglander

And you can go even further and generally put all the forms on the site into one. And rightly so, why <form>open the tag several times? Everywhere and always you should be guided by only one rule - common sense. Everything else is a special case of this rule.

A
approximate solution, 2020-12-09
@approximate_solution

Do I need to accustom myself to this approach - DRY at any cost?

You need to teach , but whether it will always be possible to use DRY is already a matter of deadlines, finances and other everyday principles.
What is programming (if we are talking about the business area) = this is a solution to the problems of some uncle. Uncle pays money, depending on the amount of cash - the quality of the product grows. If you are paid 100 bucks and given 1 month to solve a major problem, and you write everything using all the chips you described above, there are 2 developments:
a) most likely you will not complete the task, because the finances invested in the project do not fit with the project implementation and you will be driven out by pissing rags
b) you start writing noodle-like code (and they write it, and it doesn’t matter whether the project is big or small), show the finished functionality, and then, if possible, finish it, or not finish it, because the client is greedy, and he thinks that he fucked you, but actually fucked you each other.
And now how it is right in practice = if the finances that are invested in the project hint at good code, writing shitty code means being branded as an idiot in the face of colleagues who will support your project.
If the finances that are given to you for the project are equal to the tears of a cat, no one will say a word to you, since the result is important to the owner, and not whether you follow the principles of dry or not.
In my experience, the second option is more common, especially in SMBs.

F
FanatPHP, 2020-12-09
@FanatPHP

https://habr.com/ru/company/mailru/blog/349978/

C
cicatrix, 2020-12-09
@cicatrix

Blindly and mindlessly following anything is bad.
Specifically, in your example (exclusively from the way the problem is described), you can follow the DRY principle and, at the same time, adhere to KISS and not make a god object, you can chain inheritance from simple forms to complex ones.

M
merss, 2020-12-09
@merss

DRY is about something else, it's not DRY.
This is similar to the divine object antipattern, although it's all relative.
Here you can do the decomposition without violating DRY.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question