Принципы DRY, KISS, YAGNI

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

Итак, первый принцип —   DRY (Don’t Repeat Yourself) который переводится как — не повторяйте себя. Суть этого принципа в том, чтобы замечать дублирующиеся участки кода и избавляться от копирующихся строк кода.

Давайте рассмотрим следующий пример из андроида. Есть 2 активити, внутри которых одни и те же вью элементы и они одинаково инициализируются в методе onCreate. И мы видим одинаковые строчки кода в обоих активити. В этом случае можно поступить так — выделить базовый класс активити и оставить эти вью в нем, а 2 активити отнаследовать от них.

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

В чем плюс этого принципа — не только уменьшать объем кода, который видим в проекте, но и в том, что если в одном месте придется модифицировать код, то его придется модифицировать и в другом аналогичном месте, а иметь 1 точку, которую можно будет спокойно модифицировать и знать, что в остальных местах изменения применятся — это ли не замечательно? Так например и работает принцип внедрения зависимостей. У нас есть интерфейс, который инжектится в класс, а конкретную реализацию всегда можно поменять в 1 месте и во всем проекте все методы будут отрабатывать иначе.

 

Теперь давайте рассмотрим принцип KISS (Keep It Short & Simple) что можно перевести как — держите все коротким и простым. Т.е. суть в том, чтобы писать короткие и простые для понимания функции-методы, классы, интерфейсы и т.д.

Об этом принципе неявно говорит Роберт Мартин в книге Чистый Код. Он подчеркивает, что при написании методов надо помнить несколько правил — методы должны быть короткими, второе правило — они должны быть еще короче. Также он подчеркивает важность количества аргументов. Лучшая функция та, у которой нет аргументов, когда есть 1 аргумент то неплохо, 2 — максимальное оптимальное количество, но когда их 3 и больше, то это скорей всего значит что у вас довольно сложная функция, которую было бы неплохо разбить на мелкие составляющие. Также о простоте — надо именовать переменные и методы насколько возможно ясно, чтобы не было необходимости даже писать джавадок над этим методом или комментарий, поясняющий суть.

Что насчет классов, если в нем более 500 строк (условно) значит что-то пошло не так и надо посмотреть, можно ли выделить второй класс и отделить логику. Никто не любит громоздские классы в овер9000 строк кода, потому что его сложно в первую очередь читать, а потом уже поддерживать и модифицировать.

И еще один момент с интерфейсами. Они должны хранить в себе насколько возможно меньше методов. Лучше иметь 2 интерфейса, 1 из которых наследуется от второго, чем 1 интерфейс в котором все 6 методов например.

 

И третий принцип, который коррелирует с предыдущим принципом YAGNI (You Aren’t Going to Need It) что переводится как — тебе это не понадобится. В чем суть принципа — не писать код, который вам в данную минуту не нужен. Зачастую, когда программист поделил свою большую задачу на мелкие и занят первым куском, то он может за одно и написать код, который относится ко второй части большой задачи. Почему это плохо, спросите вы, а я отвечу — это плохо тем, что при чтении кода в данный момент (пулреквест) ревьюера это собьет с толку, т.е. ситуация будет следующая — ок, ты пишешь класс запроса, а зачем ты написал еще и этот класс, оно не имеет никакого отношения к этой задаче? А в ответ можно будет услышать — ну, это задел на будущее, в следующей задаче мне это понадобится. На что опытный программист ответит — вот когда оно понадобится, тогда и напишешь. Суть в том, что когда ты приступишь к написанию этого участка кода, возможно, ты уже будешь думать иначе и удалишь этот код, который написал. Поэтому необходимо заниматься тем, что важно на данный момент. Еще один момент, который может произойти, ты напишешь код, который потом долго еще не будешь трогать и в какой-то момент полностью удалишь. А в проекте останется мусор из комментариев TODO завершить тогда-то и так-то. В итоге имеем так называемую утечку времени.

И самая частая ситуация. При решении задачи ты пишешь еще и код, который возможно когда-нибудь тебе пригодится, но как показывает практика врядли. Это из серии — написать вместо объекта список объектов, с мыслью, что, возможно, когда-нибудь в очень маловероятном случае, тебе понадобится не один объект, а несколько. Если эта вероятность слишком мала, то оно не стоит того. Вот когда произойдет этот маловероятный случай и нужно будет иметь не объект, а список, тогда и наступит лучший момент модифицировать код. Да, кто-то скажет что думает о масштабируемости, но мы не рассматриваем этот случай, а тот, когда действительно нет никакой явной и разумной причины и даже намека, что в этом куске кода понадобится еще один объект. Иначе бы весь наш код выглядел бы как классы с протектед методами и кучей пустых методов, на потом, которые бы 10 лет еще никто бы не трогал и что в итоге бы засоряло проект.

 

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

Запись опубликована в рубрике Программирование Java. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *