Недавно я был в резерве CodingCoach, когда парень по имени Шаян задал вопрос. Он сказал:

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

Он хорошо замечает, хотя я уверен, что на достаточно длительной временной шкале вы найдете несколько статей о KISS (Keep It Simple Stupid) и YAGNI (You Ain't Gonna Need It). Я могу представить себе прямые объяснения этих двух концепций. быть немного худым на земле.

Итак, теперь посмотрите, как я отважно пишу в Интернете авторское мнение о слабо определенных темах, с которыми сталкивались многие люди, практически не обращая внимания на тот факт, что раздел комментариев неизбежно будет наводнен пьянящей смесью «Я не мог Согласен больше »s и« ну вообще… »s.

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

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

Да?

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

Я предполагаю, что проблема заключается в том, что эти принципы являются довольно мягкими концепциями. Нет действительно жестких правил, которые можно было бы применить, чтобы однозначно сказать: «Да, я соблюдаю принципы KISS и YAGNI». Кроме того, принципы очень субъективны как для человека, который их применяет, так и для ситуации, в которой они применяются.

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

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

ПОЦЕЛУЙ: ДЕТРОЙТ! КОД! СИТЫЫЫЫЫ!

Keep It Simple Stupid, или принцип KISS, делает то, что написано на банке. KISS советует избегать попыток перехитрить себя при написании кода.

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

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

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

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

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

Это не обязательно означает, что самый простой из возможных фрагментов кода автоматически становится лучшим кодом, который вы можете написать. Здесь определенно есть место для элегантности, а некоторые проблемы просто сложны и требуют комплексных решений. На что KISS намекает, так это на то, что решение всегда должно оставаться достаточно простым, чтобы любой член вашей команды мог легко понять его, не зная, как в настоящее время работает код.

Если подумать об этом объективно, это мудрый шаг. Каждый раз, когда вы пишете что-то непонятное, вы рискуете, что следующий разработчик, работающий над вашим кодом, не поймет замысла вашего кода. Это может привести к тому, что разработчик неправильно использует ваш код!

Насколько все просто?

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

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

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

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

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

Убери хрустальный шар: ЯГНИ

Вам не понадобятся бессмертные слова мудрости Рона Джеффриса как часть движения экстремального программирования. В основе этой мантры также лежит простота, но она немного отличается от KISS.

Когда KISS предлагает вам реализовать полное решение проблемы самым простым способом, YAGNI задает вопрос, действительно ли все в полном решении необходимо.

Когда разработчики учатся создавать расширяемое программное обеспечение, иногда появляется склонность пытаться делать вещи таким образом, чтобы любое возможное воплощение решения стало возможным в будущем. Такие вещи, как «О, мы хотим размножаться прямо сейчас, но что, если мы хотим делить? Мы должны реализовать это, пока мы этим занимаемся! "

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

YAGNI говорит, что сборка для этих ненужных вариантов использования усложняет программу, решая проблемы, которые, вероятно, даже не будут «проблемой» в программном обеспечении, которое вы пишете. В предыдущем примере; Конечно, вам может понадобиться разделение, но что, если нет ?! Теперь вам просто нужно было создать такие вещи, как учет ошибок деления на ноль для функциональности, которую вы даже не собираетесь использовать!

Способ, которым YAGNI продвигает прагматизм, заключается в том, что YAGNI предлагает вам сосредоточиться на решении проблемы, которую вы пытаетесь решить немедленно, а не пытаться решить все мировые проблемы с помощью решения, которое вы пишете прямо сейчас.

Просто красиво

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

YAGNI помогает нам добиться простоты, напоминая нам, что нам не нужно решать для каждого варианта использования в первой итерации. Даже если бы мы могли, мы бы зря тратили время, потому что на самом деле нас волнует только тот вариант использования, который мы решаем сейчас, а не 100 других, которые нам МОГУТ понадобиться в будущем.

KISS помогает нам достичь ремонтопригодности и расширяемости нашего кода, напоминая нам, что читаемый код лучше умного кода каждый день недели.