🎯 Зачем спрашивают
- Знание и понимание базовых принципов и эвристик написания поддерживаемого кода
📝 Ответ
На данный вопрос нет однозначно верного ответа. Теория расходится с практикой. В коммерческой разработке часто приходится пренебрегать качеством кода в угоду скорости его релиза.
Коротко:
- Код выполняет свою основную функцию
- Код соответсует Code-style и в прокте есть линтеры, форматеры
- Код покрыт тестами
- Имеется формализованная архитектура
- Неочевидные места описаны комментариями
- применяются принципы/паттерны проектирования
Подробнее:
Во-первых, код соответствует общепринятому code-style в команде. Все договоренности следуте фиксировать правилах линтеров и форматеров. Это избавит вас от необходимости становится линтером на code-review.
Во-вторых, код покрыт тестами. Хотя бы unit тестами, в идеале — интеграционными. Зачастую у кода отсутствует какая-либо документация, а сами тесты и их описания заменяют ее. По тест кейсам становится ясно, что является ожидаемым поведением модуля, а что нет. И, что самое главное, тесты являются гарантом того, что ошибка в коде обнаружится, если вы код рефаторите или переписываете.
В-третьих, у кода/модуля/приложения должна быть структура или архитектура (FSD, FDD, модульная). Каждому проекту и/или команде подойдет своя. Единая и формализованная архитектура:
- позволит быстрее погрузиться в проект. Особенно если она популярна
- разграничит зоны ответственности кода и границы модулей (снижает связанность, увеличивает зацепление)
- избавит от головной боли куда же положить свой код
В-четвертых, есть комментарии там, где это необходимо. Почему-то комментарии демонизируются и считаются антипаттерном, но это не так. Не все важные моменты/особенности в коде могут быть задокументированы. А комментарий в коде может за пару предложений объяснить всю суть.
Так же комментарии улучшаю DX:
Код
/** * Конфигурация сенсора для системы мониторинга */ interface SensorConfig { /** * Человеко-читаемое имя сенсора, чтобы легко отличать его в панели * (например: "Температура в серверной" или "Влажность склада") */ label: string; /** * Уникальный код устройства в сети (обычно MAC-адрес или UUID) * Используется системой для идентификации и связи */ deviceId: string; /** * Частота опроса сенсора в секундах * Чем меньше значение, тем точнее данные, но выше нагрузка на сеть и батарею */ pollingInterval: number; /** * Граничное значение, при превышении которого генерируется тревога * Например, для температурного датчика это может быть +80°C */ alertThreshold?: number; /** * Массив тегов для категоризации сенсора * Может использоваться для поиска и фильтрации (например: ["warehouse", "humidity"]) */ tags: string[]; /** * Дата последней калибровки сенсора в ISO-формате * Позволяет отслеживать, насколько актуальны данные */ lastCalibratedAt: string; }
В-пятых, при написании кодов вы придерживаетесь лучших практик. Например:
- SOLID
- GRASP
- Практики чистого кода (Боб Мартин)
- Использование Design Patterns
- И многие другие
Использование SOLID, GRASP, принципов чистого кода и шаблонов проектирования помогает создавать решения, которые легче понимать, расширять и сопровождать.
Такие подходы уменьшают связанность, повышают гибкость, уменьшают количество ошибок и делают систему более предсказуемой и надёжной в долгосрочной перспективе.
Они так же формируют единый профессиональный язык, позволяя разработчикам одинаково понимать архитектуру, решения и приемы в коде.
Не во всех проектах применимы принципы чистого кода и популярные паттерны
Во-первых, требуются определенный уровень компетенции со стороны команды разработки.
Во-вторых, это может замедлить разработку.
Есть продукты, генерирующие деньги здесь и сейчас, или проект нужно запустить в кратчайшие сроки, чтобы проверить спрос. В таких случаях важнее скорость, чем качество технического решения.
Исходите всегда из здравого смысла.
⚖️ Компромиссы
✅ Плюсы:
- Перечисленные техники и подходы позволяют унифицировать написание кода
- Упрощение онбординга нового члена команды (при условии, что он шарит)
❌ Минусы:
- Высокий порог входа. Если вы frontend разработчик, то понять многие принципы будет тяжело. Нужна практика написания backend приложений
- Понятие “качественный код” крайне субъективно
- В продуктовой разработке качеством кода зачастую пренебрегают в угоду целям бизнеса. Если вы привыкли писать качественный код, а бизнесу задача нужна была еще вчера, вы будете фрустрировать
🔎 Встречные вопросы
- Какие практики code review вы используете в своей команде?
- Что такое quality gate?
- Покрываете ли свой код тестами?
- Как балансировать скорость разработки и качество кода?
- Что важнее — тесты или документация?
- Как внедрять code review практики в команде, которая их раньше не делала?
🚩 Красные флаги
- Упоминание лишь “code-style” и правильно названных (человекочитаемых) переменных
- Из эвристик вспоминаются самые распространенные и заезженные: KISS, DRY, YAGNI