Как удержать границы в коде
Вопрос
Допустим, архитектуру договорились соблюдать. Как сделать, чтобы её действительно соблюдали через полгода?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
договорённость без проверки не работает - нужен линтер
eslint-plugin-boundaries или eslint-plugin-import с зонами
steiger - линтер именно под FSD
проверка в CI, а не только локально
запрет глубоких импортов мимо публичного API
граф зависимостей и поиск циклов, например madge
ревью ловит смысл, линтер ловит механику - нужны оба
Что могут спросить следом
- А если линтер мешает срочному фиксу?
Разбор
Любое архитектурное правило, которое не проверяется машиной, перестаёт действовать примерно через квартал. Сначала «тут же очевидно можно», потом дедлайн, потом так уже везде.
Что ставят на практике:
- Правила импортов в линтере.
eslint-plugin-boundariesописывает слои и разрешённые направления;eslint-plugin-import/no-restricted-paths- то же победнее. Для FSD есть специализированныйsteiger. - Запрет глубоких путей - импорт мимо
index.tsдолжен падать линтером. - Проверка в CI. Локально правило обходят флагом, в CI - нет.
- Поиск циклов отдельным шагом:
madge --circular. - Ревью остаётся для смысла: линтер не отличит фичу от сущности.
Сильный ответ на секции заканчивается фразой про цену: слишком строгие правила начинают мешать, и тогда их обходят массово. Правило должно быть таким, чтобы его было проще соблюсти, чем обойти.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.