Линтер (Linter)

Линтер — это инструмент статического анализа, который сканирует исходный код, не выполняя его, в поисках нарушений стиля, вероятных багов и запахов кода (code smells) — неиспользуемых переменных, непоследовательного форматирования, недостижимого кода, отсутствующей обработки ошибок или нарушений согласованных командой соглашений. Популярные линтеры включают ESLint (JavaScript/TypeScript), Pylint и Ruff (Python), RuboCop (Ruby) и golangci-lint (Go). Почему это важно для создателей AI/SaaS-продуктов: линтер — это самый дешёвый и быстрый уровень контроля качества во всём конвейере — он работает миллисекунды локально в редакторе и снова секунды в CI, отлавливая целые классы багов (например, использование `==` вместо `===` в JavaScript или необработанное отклонение промиса), прежде чем человеку-ревьюеру вообще придётся тратить на них время. Он также автоматически обеспечивает единообразный стиль, полностью устраняя из код-ревью споры в духе «табы против пробелов». Для команд, опирающихся на сгенерированный AI код, строгая конфигурация линтера — это дешёвый автоматический рубеж, отлавливающий значительную долю ошибок AI (неиспользуемые импорты, непоследовательные названия, пропущенные проверки на null) ещё до того, как человек вообще откроет диф. Как это работает: линтер разбирает исходный код в абстрактное синтаксическое дерево и прогоняет по нему настраиваемый набор «правил», каждое из которых ищет по паттерну конкретную проблему и сообщает файл/строку/столбец плюс сообщение. Многие линтеры различают «ошибки» (обязательно исправить, блокирует CI) и «предупреждения» (следует исправить, не блокирует), и многие правила автоматически исправляемы (линтер может сам переписать код, например `eslint --fix`). Линтеры обычно подключаются к редактору (красные волнистые линии в реальном времени), pre-commit хуку (блокирует плохой коммит локально) и CI (блокирует плохое слияние). Практический пример: разработчик пишет `const [data, setData] = useState()`, а затем позже `data.map(item => item.name)` без проверки на null. Правила `react-hooks` от ESLint и строгой проверки на null от TypeScript немедленно отмечают это в редакторе: «Object is possibly 'undefined'». Разработчик исправляет на `data?.map(...)`. Отдельно он оставляет в файле неиспользуемый `import { useEffect } from 'react'`; правило ESLint `no-unused-vars` отмечает это, и запуск `eslint --fix` автоматически удаляет мёртвый импорт — ни на одну из проблем не потрачено время ревьюера-человека. Умножьте это на кодовую базу с десятками участников и тысячами коммитов, и линтер тихо отлавливает сотни мелких проблем в месяц, которые иначе либо просочились бы в продакшн, либо отняли бы внимание ревьюера на тривиальных вопросах вместо логики, действительно требующей человеческого суждения. Большинство команд также подключают линтер к pre-commit хуку, так что нарушения отлавливаются и часто автоматически исправляются локально ещё до создания коммита, а значит этап линтинга в CI — и время ревьюера — резервируются для редкого случая, когда что-то действительно проскользнуло.