У маленькой задачи уже есть фабрика, реестр обработчиков и предложение выделить отдельный сервис. Самой функции пока нет. Зато архитектурная схема наконец выглядит так, что её не стыдно показать знакомым инженерам.
Мне понятна привлекательность сложного решения. В нём можно продемонстрировать знания, предусмотреть будущее и получить удовольствие от устройства системы. Неловкий вопрос приходит позже: кто будет объяснять всё это человеку, которому нужно изменить одно правило?
Что действительно меняется
Допустим, продукту нужен еженедельный отчёт одного формата. Можно построить универсальный конструктор экспортов. А можно сначала выяснить, какие изменения уже ожидаются, сколько пользователей будет у отчёта и что станет дорогим при появлении второго формата.
Простой вариант не обязан быть одноразовым. Его можно отделить от контроллера, проверить расчёт и оставить ясную точку расширения. Но универсальность должна отвечать наблюдаемой потребности. Предположение «когда-нибудь наверняка понадобится» слишком дёшево по сравнению с постоянной ценой поддержки.
С отчётом есть хороший мысленный эксперимент: добавить второй формат без обещания поддержать все возможные форматы. Какие части действительно повторились? Где различие оказалось содержательным? На двух настоящих случаях абстракция часто выглядит иначе, чем на одном настоящем и десяти воображаемых.
Это не означает всегда ждать дублирования. Дорогие границы системы иногда нужно продумать заранее. Но полезно различать решение, которое трудно поменять после запуска, и внутреннюю организацию небольшого участка, которую спокойно уточнят по мере роста. Будущему не обязательно заранее выдавать отдельную фабрику.
Сложнее всего отказаться от уже придуманной красивой конструкции. Ты потратил вечер, нашёл удачные названия, мысленно решил будущие задачи. Теперь выясняется, что обычная команда по расписанию справится. Приходится расстаться с работой, которую никто не просил.
Я бы защищал простоту через конкретные вопросы. Сколько мест нужно прочитать для изменения? Можно ли проверить правило отдельно? Понятно ли, где искать сбой? Если короткое решение всё смешивает и скрывает зависимости, оно лишь выглядит простым по числу строк.
Кому достанется следующий шаг
Хорошая простота учитывает следующего разработчика. Понятное имя, видимое условие, явная ошибка часто полезнее изящной абстракции, ради которой нужно сначала освоить авторскую философию.
Разумеется, бывают задачи, где сложность оправдана: много независимых правил, несколько потребителей, строгие требования к отказам. Тогда хочется увидеть именно эти причины рядом с решением. Устройство системы должно объясняться её жизнью, а не любовью автора к определённому шаблону.
Оставить после себя меньше обязательств — вполне серьёзное инженерное достижение. Даже если на диаграмме получились всего три скучных прямоугольника.
Какую ненужную сложность я сейчас хочу создать из любви к красивому решению?
