Post #9404

💡Надо регулярно следить за выполнением правил и лучших практик в коде За годы работы в IT в разных компаниях и командах я понял одну простую вещь: даже лучшие правила и практики будут нарушаться, если нет автоматической системы, которая их регулярно проверяет. Сегодня поделюсь, как я подхожу к автоматизации контроля качества кода Android-проектов на Kotlin. Рассматривать будем только статический анализ — когда код не выполняется, а анализируется как текст. 🛠 Инструменты для анализа кода • Detekt — статический анализатор Kotlin-кода. Работает быстро, так как проверяет файлы по отдельности, без учёта зависимостей между ними. • KtLint — проверка стиля кода. Настроек немного, но работает с конфигом .editorconfig, что удобно для командной разработки. • Android Lint — мощный инструмент для Android-проектов. Может анализировать разные типы исходников и проверять сразу несколько файлов по одному правилу. ⚠️ Запуск из Android Studio и через Gradle может иметь разные настройки. Полный контроль — через Gradle ⚙️Дополнительно для Compose: • Compose Rules — правила для Detekt или KtLint, проверяющие соответствие best-practice работы с Compose. • Compose Rules от Slack — набор правил для Android Lint (частично пересекается с предыдущим, но есть уникальные). 🔐Безопасность: • GitLeaks — поиск в коде секретов и данных, которые не должны попасть в репозиторий. Можно смело комбинировать несколько линтеров. Лучше перебдеть, чем недопроверить. 🚀Как запускать проверки Я использую три уровня автоматизации: 1. Перед пушем кода — быстрые проверки (Detekt, KtLint) в pre-push hook. ⏱️ Цель — не больше 30 секунд, чтобы не раздражать разработчиков, но сразу отсеивать очевидные ошибки. 2. На CI/CD — полная проверка. ⏱️ Лимит — 10 минут. Обычно сюда входят все линтеры, кроме Android Lint, который может сильно замедлить процесс. 3. Ночные прогоны — расширенный Android Lint и тяжёлые правила, если в проекте были изменения. 🛠Собственные правила Стандартные линтеры могут покрыть только общие случае и правила, но если есть практики, которые надо форсировать для вашего кода то тут надо будет писать собственные правила. Для анализа Kotlin кода я пишу расширения для Detekt, а во всех остальных случаях - для Android Lint, но довольно редко. 📌 Бонус: AAR-библиотеки могут содержать свои Lint-правила, которые автоматически подключаются при их использовании. 💬Делитесь в комментариях как вы следите за качеством вашего кода на регулярной основе и какие инструментыиспользуете. #android#compose#инструменты#ci