Как определить качество кода

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

Есть ли у вас рабочее определение качества, а не набор слов «читаемый, поддерживаемый, тестируемый». Интервьюеру важно, чем вы это качество измеряете и как отстаиваете его на ревью. Следом часто дают кусок кода и просят оценить его вслух.

Как отвечать

Сформулируйте определение через стоимость изменений: качественный код тот, который новый человек в команде быстро понимает и меняет без страха сломать соседнее. Дальше разделите то, что проверяет машина, и то, что видит только человек.

Автоматически:

• линтер и форматтер: ESLint с правилами для хуков и доступности (eslint-plugin-react-hooks, eslint-plugin-jsx-a11y), Prettier, чтобы споры о стиле не занимали ревью;
• типы: TypeScript в режиме strict, минимум any и приведений через as;
• сложность и дубли: правило complexity в ESLint, SonarQube или аналог для повторов и запахов кода;
• тесты: юнит-тесты и компонентные на Vitest или Jest с Testing Library, e2e на Playwright. Покрытие смотрят как сигнал, а не как цель;
• фронтенд-метрики: вес бандла, Core Web Vitals, лишние перерисовки в React Profiler.

Глазами на ревью: понятные имена, компоненты с одной задачей, отсутствие скрытых побочных эффектов, предсказуемое управление состоянием, обработанные ошибки и пустые состояния.

Сильный ответ заканчивается командными индикаторами: сколько времени уходит на ревью, как часто откатываются релизы, сколько багов возвращается после исправления. Если в команде это не считали, так и скажите и объясните, что стали бы отслеживать первым.

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

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

Путают качество с личным вкусом: «мне так не нравится» на ревью без ссылки на правило или последствие не работает.

Забывают про фронтенд-специфику. Код может быть аккуратным, но ломать работу с клавиатуры или тянуть в бандл целую библиотеку ради одной функции.