DRY для джуниора и сеньора
Раз уж пошли по базовым принципам, то сегодня разберём DRY: Don't Repeat Yourself.
Такой популярный и такой обманчиво простой.
Отношение к DRY эволюционирует по мере роста разработчика и проходит через четыре этапа:
🔸 Этап 1. Стажёр
Боготворит DRY, считает дублирование кода ужасным грехом. Действительно, зачем писать несколько раз одно и то же?
Для этого код максимально оптимизируется. Универсальные методы, универсальные статические методы, много входных параметров.
🔸 Этап 2. Джуниор
Любит DRY, но понимает, что любить — значит страдать.
Проект становится больше, а бизнес-логика — сложнее. Добавить в метод ещё один if уже не так просто. Сложно разбираться в коде, сложно писать тесты, но чего не сделаешь ради хорошего кода. А хороший код на этом этапе — это максимально сжатый код🙂
🔸 Этап 3. Мидл
Всё ещё любит DRY, но более возвышенно — на уровне иерархий и паттернов. Когда приходится дублировать код, то грустит, что на проекте плохая архитектура.
🔸 Этап 4. Сеньор
Распилил монолит на сервисы, реализовал десятки крупных фич и отдал сердце SOLID.
А теперь по делу
Часто начинающие разработчики считают, что хороший код — это суперконцентрированный код с кучей паттернов и хитрых приёмов.
В больших проектах хороший код — это тот, который легко читать, тестировать и поддерживать. Оптимизации и приёмчики - это совсем небольшая часть кодовой базы.
Если бизнес-процессы не пересекаются, то связывать их искусственно с помощью кода — плохая идея.
🙁 Класс User c 20 полями. 10 полей используются в 1 сервисе, другие 10 - в другом, половина объекта всегда пустая
🙁 Универсальный метод с 7 параметрами под разные случаи
🙁 Сложная иерархия с кучей шаблонных методов
Единственный плюс — меньше кода. Зато
❌ Плохая читаемость
❌ Сложно писать тесты
❌ Сильная связность. Функцию тяжело поменять или вынести в другой модуль
Я не говорю, что копипаст - единственный шанс на хорошую архитектуру. Переиспользовать код можно, если это действительно универсальные компоненты и та же цепочка бизнес-процессов. Но такое понимание приходит только с опытом.
Раз уж пошли по базовым принципам, то сегодня разберём DRY: Don't Repeat Yourself.
Такой популярный и такой обманчиво простой.
Отношение к DRY эволюционирует по мере роста разработчика и проходит через четыре этапа:
🔸 Этап 1. Стажёр
Боготворит DRY, считает дублирование кода ужасным грехом. Действительно, зачем писать несколько раз одно и то же?
Для этого код максимально оптимизируется. Универсальные методы, универсальные статические методы, много входных параметров.
🔸 Этап 2. Джуниор
Любит DRY, но понимает, что любить — значит страдать.
Проект становится больше, а бизнес-логика — сложнее. Добавить в метод ещё один if уже не так просто. Сложно разбираться в коде, сложно писать тесты, но чего не сделаешь ради хорошего кода. А хороший код на этом этапе — это максимально сжатый код🙂
🔸 Этап 3. Мидл
Всё ещё любит DRY, но более возвышенно — на уровне иерархий и паттернов. Когда приходится дублировать код, то грустит, что на проекте плохая архитектура.
🔸 Этап 4. Сеньор
Распилил монолит на сервисы, реализовал десятки крупных фич и отдал сердце SOLID.
А теперь по делу
Часто начинающие разработчики считают, что хороший код — это суперконцентрированный код с кучей паттернов и хитрых приёмов.
В больших проектах хороший код — это тот, который легко читать, тестировать и поддерживать. Оптимизации и приёмчики - это совсем небольшая часть кодовой базы.
Если бизнес-процессы не пересекаются, то связывать их искусственно с помощью кода — плохая идея.
🙁 Класс User c 20 полями. 10 полей используются в 1 сервисе, другие 10 - в другом, половина объекта всегда пустая
🙁 Универсальный метод с 7 параметрами под разные случаи
🙁 Сложная иерархия с кучей шаблонных методов
Единственный плюс — меньше кода. Зато
❌ Плохая читаемость
❌ Сложно писать тесты
❌ Сильная связность. Функцию тяжело поменять или вынести в другой модуль
Я не говорю, что копипаст - единственный шанс на хорошую архитектуру. Переиспользовать код можно, если это действительно универсальные компоненты и та же цепочка бизнес-процессов. Но такое понимание приходит только с опытом.