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

Большинство разработчиков строят абстракции для кода, который живёт ровно в одном месте.

Один интерфейс. Одна реализация. Один вызывающий. Навсегда.

И называют это «чистым кодом».

Вот в чём ловушка →

Абстракция, построенная для переиспользования, которое никогда не наступает — не переиспользуема. Это просто лишний слой, который надо прочитать, чтобы понять, что код на самом деле делает.

📌 Сначала удобство использования. Переиспользование — то, что вы зарабатываете потом.

Самая частая пустая трата, которую я вижу:

- ❌ IThingService с одной реализацией «на всякий случай»
- ✅ Конкретный класс, который можно прочитать от начала до конца
- ❌ Общая база «для будущей гибкости», которая никогда не гнётся
- ✅ Простая прямая версия, решающая сегодняшнюю задачу
- ❌ Фабрика, оборачивающая создание одного объекта
- ✅ Внедрение объекта напрямую через DI

Каждая лишняя абстракция усложняет использование кода.

Больше файлов для открытия. Больше косвенности для трассировки. Больше догадок, зачем это существует.

👉 Честный тест перед тем, как выносить абстракцию:

1. Есть ли у меня второй или третий реальный вызывающий код прямо сейчас? (Не «может быть потом»)
2. Это делает код проще в использовании или просто даёт повод гордиться собой?
3. Сможет ли следующий разработчик разобраться в этом без моих объяснений?

Если ответ «нет» — удаляйте слой. Пишите конкретную реализацию.

Вы не теряете переиспользование.

Вы сохраняете код удобным до тех пор, пока переиспользование действительно не появится.
А когда оно появится — правильная абстракция станет очевидной, потому что у вас наконец будет два или три реальных примера, чтобы её сформировать.

Преждевременная абстракция — это сложность, за которую вы платите сегодня ради выгоды, которая может никогда не наступить.

Сделайте код удобным сначала. Абстрагируйте только тогда, когда второй реальный сценарий использования вынудит вас это сделать.

@KodBlog