В студенчестве читал историю как отличить хорошего программиста...

В студенчестве читал историю как отличить хорошего программиста от плохого.

Вот программисту поставлена задача: написать взаимодействие с одним каналом данных (любым: порт/файл...). Если в реализации для того чтобы перейти к произвольному числу каналов данных:
1. Нужно всё переписать - плохой программист
2. Необходимо слегка изменить код - хороший программист
3. Нужно изменить одну константу - отличный программист.

Теперь, уже не будучи студентом, твёрдо уверен, что если задачу организации взаимодействия с одним каналом данных программист решает по третьему пути максимального обобщения - его надо срочно уволить. Ну или срочно побить палками и уволить.

За неоправданное усложнение поддерживаемой системы. Эдакая максима: "Система должна быть максимально минимальной."

Стоимость поддержки в овердохуя случаев велика, а выгода в том же числе случаев не оправдается.

Конечно, зависит от ситуации, есть редкие случаи, в которых набор технических требований предсказуем, следовательно, необходимая общность решения известна заранее, аднака, на то они и редкие.
As a student, I read the story of how to distinguish a good programmer from a bad one.

Here is the task for the programmer: to write interaction with one data channel (any: port / file ...). If in the implementation in order to go to an arbitrary number of data channels:
1. Need to rewrite everything - a bad programmer
2. It is necessary to slightly change the code - a good programmer
3. You need to change one constant - an excellent programmer.

Now, already not being a student, I am firmly convinced that if a programmer solves the problem of organizing interaction with one data channel in the third way of maximum generalization, he must be dismissed urgently. Well, or urgently beat with sticks and fire.

For unjustified complication of a supported system. A kind of maxim: "The system should be as minimal as possible."

The cost of support in overdosing cases is high, and the benefit in the same number of cases will not be justified.

Of course, it depends on the situation, there are rare cases in which the set of technical requirements is predictable, therefore, the necessary generality of the solution is known in advance, adnaka, for which they are rare.
У записи 4 лайков,
0 репостов.
Эту запись оставил(а) на своей стене Иван Афанасьев

Понравилось следующим людям