L_G>>Всегда остаётся вероятность, что YAGNI придумали идиоты и применение этого принципа в массовом индустриальном/энтерпрайзном программировании неоправдано. Но я в этот принцип почему-то поверил и даже широко применяю (видимо, потому, что я очень ленивый программист).

BFE>Вряд ли. Скорее методология должна соответствовать задаче. YAGNI не годится для V-Model, но подходит для agile. При этом сам agile не подходит для тех задач, где чёткие требования прописанные и подписанные в договоре, где V-Model — самое то.

YAGNI — обычно про фазу ПРОЕКТИРОВАНИЯ РЕАЛИЗАЦИИ требований/задачи. (Иногда её выполнят тот же программист, что и кодирует, но не суть.) И тогда ЕСЛИ у проектировщика/программиста возникает вопрос "а не забубенить ли мне/нам в коде ЕЩЕ И ЭТО?", YAGNI дает ответ: "НЕТ, это тебе/нам ПОКА не нужно. Когда будет нужно — поймём и тогда уже забубеним (когда уже нельзя будет отвертеться)."

В V-Model, насколько понимаю, есть выделенная стадия проектирования, которая должна завершиться до начала кодирования, но не суть. ЕСЛИ у проектировщика возник вопрос "а не забубенить ли нам...?" (при неизменности спущенных ему сверху требований), то он вполне может применить YAGNI и решить НЕ забубенивать, поскольку внешние требования этого не требуют и у него ЕСТЬ ВЫБОР. Кстати, экономия времени — это экономия денег (или становится ей при возрастании масштаба). Думаю, YAGNI подтверждает свою полезность статистически (на большинстве случаев), хотя всегда есть шанс не угадать (отказаться от того, что в будущем окажется полезным) и проиграть.

Даже на этапе обсуждения ТЗ с заказчиком YAGNI вполне применимо! (Тут уже речь об экономии денег/времени заказчика. Если исполнитель хочет загрузить себя работой по-максимуму, ОН применять YAGNI, конечно же, не станет.)

L_G>>BTW, рационально мыслящие программисты обычно практикуют не переписывание с нуля, а дописывание нового с одновременным рефакторингом старого (рефакторинга в рамках необходимого для того, чтобы новое вписалось органично, а не в виде костылей). Думается, тем коллективом двигало как раз то самое хорошо знакомое тебе стремление сделать программирование интересным.

BFE>Не, большинство выбирает ехать, а не шашечки и как следствие частые аварии ведущие к костылям.

Тут я рассуждаю о конкретном случае "коллектив переписывает одну и ту же функциональность в который раз."
Если "выбирает ехать, а не шашечки" — о том, что впендюривают костыли, не тратя время на рефакторинг — то это случай, прямо ПРОТИВОПОЛОЖНЫЙ описанному переписыванию с нуля.

L_G>>Всегда остаётся вероятность, что YAGNI придумали идиоты и применение этого принципа в массовом индустриальном/энтерпрайзном программировании неоправдано. Но я в этот принцип почему-то поверил и даже широко применяю (видимо, потому, что я очень ленивый программист).

BFE>Вряд ли. Скорее методология должна соответствовать задаче. YAGNI не годится для V-Model, но подходит для agile. При этом сам agile не подходит для тех задач, где чёткие требования прописанные и подписанные в договоре, где V-Model — самое то.

YAGNI — обычно про фазу ПРОЕКТИРОВАНИЯ РЕАЛИЗАЦИИ требований/задачи. (Иногда её выполнят тот же программист, что и кодирует, но не суть.) И тогда ЕСЛИ у проектировщика/программиста возникает вопрос "а не забубенить ли мне/нам в коде ЕЩЕ И ЭТО?", YAGNI дает ответ: "НЕТ, это тебе/нам ПОКА не нужно. Когда будет нужно — поймём и тогда уже забубеним (когда уже нельзя будет отвертеться)."

В V-Model, насколько понимаю, есть выделенная стадия проектирования, которая должна завершиться до начала кодирования, но не суть. ЕСЛИ у проектировщика возник вопрос "а не забубенить ли нам...?" (при неизменности спущенных ему сверху требований), то он вполне может применить YAGNI и решить НЕ забубенивать, поскольку внешние требования этого не требуют и у него ЕСТЬ ВЫБОР. Кстати, экономия времени — это экономия денег (или становится ей при возрастании масштаба). Думаю, YAGNI подтверждает свою полезность статистически (на большинстве случаев), хотя всегда есть шанс не угадать (отказаться от того, что в будущем окажется полезным) и проиграть.

Даже на этапе обсуждения ТЗ с заказчиком YAGNI вполне применимо! (Тут уже речь об экономии денег/времени заказчика. Если исполнитель хочет загрузить себя работой по максимуму, ОН применять YAGNI, урезая себе ТЗ и общую сумму договора, конечно же, не станет.)

L_G>>BTW, рационально мыслящие программисты обычно практикуют не переписывание с нуля, а дописывание нового с одновременным рефакторингом старого (рефакторинга в рамках необходимого для того, чтобы новое вписалось органично, а не в виде костылей). Думается, тем коллективом двигало как раз то самое хорошо знакомое тебе стремление сделать программирование интересным.

BFE>Не, большинство выбирает ехать, а не шашечки и как следствие частые аварии ведущие к костылям.

Тут я рассуждаю о конкретном случае "коллектив переписывает одну и ту же функциональность в который раз."
Если "выбирает ехать, а не шашечки" — о том, что впендюривают костыли, не тратя время на рефакторинг — то это случай, прямо ПРОТИВОПОЛОЖНЫЙ описанному переписыванию с нуля.