SOLID, DRY, KISS, YAGNI на фронтенде
↑ 8.2 Архитектура фронтенда и паттерны · → Следующая
Зачем это на собесе
Принципы противоречат друг другу; senior показывает, как выбирать баланс.
Принципы
| Принцип | Формулировка | Пример на фронтенде |
|---|---|---|
| DRY | не повторять знание | единый валидатор, общий тип из OpenAPI |
| KISS | проще — лучше | ref и computed вместо собственного стора |
| YAGNI | не делай «на будущее» | не строить универсальный конфигуратор форм ради одной формы |
| SOLID | границы и зависимости | см. раздел про парадигмы |
| Separation of Concerns | разные ответственности отдельно | UI, состояние, доступ к данным |
| Law of Demeter | говори только с ближайшими | не тянуть a.b.c.d через компоненты |
Конфликты
- DRY против YAGNI: раннее объединение похожего кода создаёт неверную абстракцию. Правило трёх: обобщаем на третьем повторении.
- DRY против независимости модулей: дублирование между разными доменами бывает дешевле общей зависимости.
- KISS против расширяемости: не проектировать для гипотетических требований.
Ключевой вопрос: дублируется знание или просто похожий текст. Если два фрагмента меняются по разным причинам — это не дубль.
Неправильная абстракция
Дороже дубликата: флаги и if в общем компоненте, который «почти подходит всем».
Практика
- сначала конкретный код, абстракция после появления паттерна;
- маленькие компоненты с узкими props;
- явные зависимости, без глобальных сущностей;
- измеримые критерии: цикломатическая сложность, размер файла, частота совместных изменений.
Вопросы с ответами
Когда не следует применять DRY?
Если код похож случайно и будет меняться по разным причинам, либо объединение создаёт связь между независимыми доменами.
Как понять, что абстракция преждевременна?
Появляются флаги-исключения, параметров больше, чем строк реализации, потребители используют лишь часть возможностей.