Твердые принципы против ЯГНИ

Когда твердые принципы становятся ЯГНИ?

Как программисты, мы постоянно идем на компромиссы между сложностью, ремонтопригодностью, временем сборки и так далее. Среди прочего, два из самых умных руководящих принципов для выбора - это, на мой взгляд, принципы SOLID и YAGNI. Если вам это не нужно; не строить его, и держать его в чистоте.

Теперь, например, когда я смотрю серию dimecast на SOLID , я вижу, что она начинается как довольно простая программа и заканчивается как довольно сложная (конец да сложность также в глазах смотрящего), но она все еще делает меня интересует: когда твердые принципы превращаются в то, что вам не нужно? Все твердые принципы - это способы работы, позволяющие использовать изменения на более позднем этапе. Но что, если проблема, которую нужно решить, довольно проста, и это одноразовое приложение, то что? Или принципы SOLID всегда применимы?

Как спросили в комментариях:

• Твердые принципы
• YAGNI

Всегда трудно судить о подходе, основанном на скринкасте, поскольку проблемы, выбранные для демонстраций, как правило, настолько малы, что применение таких принципов, как SOLID, быстро создает впечатление, что решение полностью перегружено.

Я бы сказал, что твердые принципы почти всегда полезны. Как только вы станете опытным с ними, их использование не будет похоже на то, о чем вы должны сознательно думать. Это просто становится естественным. Я видел, как много одноразовых одноразовых приложений становятся чем-то большим, так что теперь я боюсь сказать, что я собираюсь что-то выбросить, потому что вы просто никогда не узнаете.

Подход, который я обычно использую, заключается в том, что если я пишу простое приложение для конкретной задачи, я иногда отказываюсь от принципов громкого имени в пользу нескольких строк кода, которые работают. Если я обнаружу, что возвращаюсь к этому приложению для внесения дальнейших изменений, я найду время, чтобы сделать его ТВЕРДЫМ (по крайней мере, в некоторой степени, поскольку 100% -ное применение принципов редко выполнимо).

В больших приложениях я начинаю с малого, и по мере развития программы я применяю принципы SOLID, где это возможно. Таким образом, я не пытаюсь спроектировать всё заранее, до последнего перечисления. Для меня это сладкое место, где сосуществуют YAGNI и SOLID.

Подумайте о проблеме в первую очередь. Если вы слепо применяете принципы YAGNI или SOLID, вы можете навредить себе позже. Надеюсь, мы все сможем понять, что не существует единого подхода к проектированию, который бы подходил всем проблемам. Вы можете увидеть доказательства этого, когда магазин продает шляпу, рекламируемую как «один размер подходит всем», но она не подходит вашей голове. Он либо слишком большой, либо слишком маленький.

Вместо этого лучше понять принципы и проблемы, которые SOLID пытается решить; а также принципы и проблемы, которые YAGNI пытается решить. Вы обнаружите, что один связан с архитектурой вашего приложения, а другой - с процессом разработки в целом. Хотя в некоторых случаях возможны совпадения, они представляют собой совершенно разные проблемы.

YAGNI («Вам это не нужно» [причудливая американская аббревиатура]) посвящен экономии времени застройщика, добавлению железобетонных фундаментов со стальным восстановленным мостом к мосту, который предназначен только для охвата ручья шириной 3 фута, когда более простой деревянный мост подойдет просто хорошо. Если мы пересекаем реку шириной в милю и нуждаемся в поддержке нескольких тракторных прицепов, конечно, нам понадобятся дополнительные фундаментные работы. По сути, YAGNI предлагает вам взглянуть на более широкую картину и дизайн для текущих потребностей. Он решает проблему создания чего-то слишком сложного, потому что мы предвидим ряд потенциальных потребностей, которые клиент еще не определил.

SOLID заботится о том, чтобы убедиться, что части моста правильно совмещаются и могут поддерживаться в течение долгого времени. Вы можете применять ТВЕРДЫЕ принципы к деревянному мосту, а также к стальному железобетонному мосту.

Короче говоря, эти два понятия не обязательно противоречат друг другу. Когда вы сталкиваетесь с ситуацией, когда вы верите в это, самое время взглянуть на общую картину. В зависимости от вашего заключения, вы можете решить отказаться от части принципов SOLID или решить, что вам это действительно нужно.

Принципы SOLID не нужны, когда это одноразовое приложение; в противном случае они всегда нужны.

SOLID и YAGNI не имеют разногласий: хороший дизайн класса облегчает обслуживание приложения. YAGNI просто заявляет, что вы не должны добавлять в ваше приложение возможность настраивать это чудовище, которое может делать все под солнцем - если только оно ему действительно не нужно.

Это разница между классом автомобилей с четко определенными границами (SOLID) и классом автомобилей, который обладает способностью к самовосстановлению (YAGNI) до того, как клиент об этом попросит.

Ничто не всегда относится! Не позволяйте астронавтам архитектуры пугать вас! Важно постараться понять, какие проблемы пытаются решить эти принципы, чтобы вы могли принять обоснованное решение о их применении.

Недавно я пытался понять, когда мне следует использовать принцип единой ответственности ( вот что я придумал).

Надеюсь это поможет!

Есть цитата, приписываемая Эйнштейну (возможно, вариация реальной ):

«Все должно быть сделано как можно проще, но не проще».

И это более или менее подход, который я использую, когда сталкиваюсь с компромиссом SOLID и YAGNI: применяйте их альтернативно, потому что вы никогда не знаете, является ли программа «одноразовым» кодом или нет. Итак, просто добавьте слой грязи, который работает, затем отполируйте его до более чистого интерфейса ... и повторяйте, пока не дойдете до нужного уровня энтропии. С надеждой.

Есть много способов разработать программу для данной проблемы; SOLID - это попытка определить свойства хорошего дизайна. Правильное использование SOLID должно привести к созданию программы, которую легче рассуждать и изменять.

YAGNI и KISS занимаются широким спектром возможностей. Программа, которая решает больше видов проблем, является более сложной и абстрактной. Если вам не нужна эта универсальность, вы потратили время и силы на создание кода, который сложнее понять и поддерживать, но не приносит никакой дополнительной выгоды.

Хорошо продуманная программа не обязательно ориентирована только на те функции, которые ей необходимы. Программа, ориентированная только на те функции, которые ей необходимы, не обязательно хорошо разработана. Здесь нет компромисса, только две ортогональные оси в пространстве принятия решений. Идеальная программа является модульной и имеет только основные функции.

Я думаю, что вы должны начать YAGNI, и когда есть необходимость, решите это.

Я имею в виду, что SOLID существует, поэтому, когда вы добавляете новый класс, вам не нужно будет проводить рефакторинг, просто переключите реализацию (например), ну, на мой взгляд, просто напишите свой код, и когда вы увидите, что вы меняете вещи - измените это с помощью SOLID (то есть опасный рефакторинг, от которого SOLID должен вас спасти - это не так уж плохо, когда вы только начинаете).

Вы не тратите время впустую, потому что вам все равно придется выполнять работу (в начале), и там, где это необходимо, ваш код хорош и аккуратен.

Я думаю, вы могли бы назвать это ленивой оценкой SOLID.