Что такое принципы DRY, SOLID, KISS и YAGNI и почему они важны?

Что проверяют

Умеете ли вы перенести принципы, придуманные для классов, на компоненты, хуки и модули фронтенда, и понимаете ли, где они начинают вредить. Следом почти всегда просят пример из своего кода: где вы применили принцип и где сознательно от него отступили.

Как отвечать

Коротко расшифруйте каждый принцип и сразу покажите его во фронтенде:

• DRY: одно знание живёт в одном месте. Речь о правилах и данных, а не о похожем тексте: схема валидации, общая для формы и API, или константы роутов;
• KISS: самое простое решение, которое работает. Локальный useState вместо глобального стора, пока состояние нужно одному экрану;
• YAGNI: не делать заранее то, что «когда-нибудь пригодится»: темизацию на пять тем, плагинную систему, слой абстракции на случай смены бэкенда;
• SOLID: пять принципов, которые на React читаются так.

Разбор SOLID на компонентах:

• S: компонент отвечает за одно. Загрузку данных выносят в хук (useUser), отображение остаётся в компоненте;
• O: расширение через композицию, children и слоты, а не через новый if внутри компонента на каждый случай;
• L: обёртка над кнопкой принимает все её пропсы (ComponentProps<'button'>) и ведёт себя как кнопка, её можно подставить вместо нативной;
• I: компонент получает name и avatarUrl, а не весь объект user с тридцатью полями;
• D: компонент зависит от абстракции, например клиента API из контекста или пропса, а не зовёт fetch напрямую. Так его проще тестировать.

Закончите тем, что принципы спорят между собой: DRY тянет к абстракции, YAGNI и KISS от неё удерживают. Рабочее правило: выносить общее после третьего повторения, когда уже видно, что именно общее.

Где спотыкаются

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

Зачитывают определения SOLID из книги про ООП и не могут привести ни одного примера с компонентами, хуками или модулями.

Используют YAGNI как оправдание для отсутствия типов и тестов. Принцип про лишнюю функциональность, а не про качество того, что уже нужно.