DRY

DRY или Don't Repeat Yourself (не повторяй себя), - наверное, один из самых несложных принципов программирования. Он сводится к тому, чтоб каждый кусочек информации в IT системе был представлен в единственном варианте во избежание дублированного представления. Если мы говорим непосредственно про код, то придерживаясь этого принципа во время разработки позволяет вам:
👍🏻 поддерживать минимальное количество кода при той же функциональности
👍🏻 избежать наличия тех багов, от которых вы уже избавились - отсутствие дублирующихся частей кода позволяет избежать необходимости копипаста исправлений при любом исправлении
👍🏻 уменьшить связность кода за счет того, что внешние зависимости используются в каждой части только в единственном экземпляре

Не стоит так же забывать о том что DRY вполне себе тесно связан с качеством кода, в частности с принципом Single Responsibility. В случае SRP это происходит, потому что вам приходится выносить общие кусочки кода в отдельные общие методы, что уменьшает зону ответственности каждого метода.

"Сухого" вам кода ;)

#DRY #SRP

Оператор if

Чем больше программирую, тем больше не люблю оператор if и стараюсь избегать его использования. Все дело в том, что из-за него вы начинаете генерировать ветки кода, что усложняет его понимание. Более того ваш код сложнее тестировать т.к. на тот же метод нужно написать больше тестов чтоб покрыть ими все возможные ветки выполнения. Например, 3 структуры if-else в теле метода уже генерируют до 8 возможных разных веток выполнения кода.

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

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

#if #SRP

Solid
Single Responsibility Principle

SRP - по-моему, один из самых простых и самых важных принципов. Каждая часть, каждый компонент системы должен отвечать за одну и только одну функциональность. Проще всего понять что система/компонент/класс удовлетворяет этому условию - это если можно дать максимально простой ответ на вопрос “что делает эта часть?” без использования “и”/”или”.

Причем в более сложных системах даже передача данных и управление поведением - это тоже разные сферы ответственности.

Основные триггеры что ваш компонент не удовлетворяет принципу SRP:
👉 При ответе на вопрос “Для чего он нужен?” вам хочется использовать частицы “и”/”или”.
👉 Вы используете оператор if в теле метода. Уже писал чуть более подробно об этом выше по хештегу #if. Само по себе ветвление означает, что что поведение запрограммировано с условием “или”.
👉 Вы передаете туда булеву переменную. Использование булевой переменной в качестве параметра является антипаттерном, т.к. уже подразумевает, что она будет использоваться в операторе if или в комбинации с другими переменными. В общем - в очередной раз появляются условности и ветки.

#if #SRP

Недавно меня спросили - чем плохо большое количество аргументов в методе или конструкторе?

1. Это сложно читать в коде и на ревью, если IDE без подстветки - можно запросто перепутать пару аргументов
2. Если эти аргументы передаются через 2-3 слоя - то возникают длинные портянки аргументов где опять же очень легко многое напутать, а добавление/изменение чего-либо приводит к каскадным фиксам.

Как избежать большого количества параметров, передаваемых в метод?

способ 1: Рефакторинг
Если метод не удоволтворяет принципу #SRP, то при его рефакторинге количество параметров явно уменьшиться

способ 2: Группировка параметров в один объект
Если метод удовлетворяет принципу #SRP - значит и параметры этого метода можно как-то сгруппировать. Можно их сгруппировать в один объект, который, в свою очередь создавать с помощью #builder

способ 3: Вынос аргументов метода в поля класса
В некоторых ситуациях есть возможность все аргументы метода или их часть вынести в качестве полей класса, тогда сам класс можно создавать с помощью #builder, а потом вызывать метод с минимальным колиеством дополнительных аргументов