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

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

Есть ли у вас рабочие критерии, а не набор лозунгов про SOLID и чистый код. Сильный ответ связывает качество с ценой изменения. Следом обычно спрашивают, как качество держится в команде и что вы смотрите на код-ревью.

Как отвечать

Дайте определение через последствия: качественный код дёшево читать, менять и проверять. Дальше критерии и чем их мерить в Java-проекте:

• читаемость: имена, из которых понятен смысл, короткие методы, единый стиль. Стиль не обсуждают на ревью, его фиксируют форматтером (Spotless с google-java-format) и Checkstyle в сборке;
• надёжность: статический анализ ловит типичные баги до запуска. SpotBugs, Error Prone, SonarQube с quality gate на новый код: подозрительный null, несогласованные equals и hashCode, ресурсы вне try-with-resources;
• тестируемость: зависимости приходят через конструктор, логика отделена от фреймворка. Покрытие меряет JaCoCo, но процент говорит лишь о том, что строки выполнялись. Качество самих тестов показывает мутационное тестирование PIT;
• сложность и связность: цикломатическая и когнитивная сложность методов, циклические зависимости пакетов. Архитектурные правила закрепляются тестами на ArchUnit;
• изменяемость: сколько файлов приходится трогать ради одной фичи. Если ради нового статуса заказа правят двадцать switch, это видно без всяких метрик.

Закончите процессом: автоматические проверки в CI отсекают механическое, а ревью остаётся людям для смысла, дизайна и имён.

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

Называют главным критерием процент покрытия. Покрытие 90% без проверок внутри тестов даёт ложное спокойствие, а погоня за цифрой рождает тесты на геттеры.

Путают качество с обилием паттернов. Фабрика фабрик ради одного класса делает код хуже, а не лучше.

Говорят только о своём вкусе, без инструментов и договорённостей. Интервьюеру важно, как качество держится, когда вы в отпуске, а на это отвечают правила в CI, а не личная аккуратность.