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