TGViewer
Android Broadcast Android Broadcast @android_broadcast · 14.5K subscribers
Post #9404 8.6K
💡 Надо регулярно следить за выполнением правил и лучших практик в коде

За годы работы в 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
  • 👍 50
  • 🔥 8
  • 🆒 3
  • ❤ 2
More from @android_broadcast
  1. Oct 1, 2026🔥 Выпустили официальный плагин Firebase для Codex #Firebase #Codex
  2. Oct 1, 2026👨🏻‍💻 Строим мультиагентные системы для разработки на Podlodka AI Crew Инженерные задачи…
  3. Sep 30, 2026📹 День, когда сайдлоадинг остановился. Google запустила верификацию разработчиков при уст…
  4. Sep 30, 2026‼️NoOp — удобный способ отключить API в релизных сборках без усложнения кода Отладочные ин…
  5. Sep 30, 2026🛒 Google Play расширяет возможности и типы платных подписок В блоге Android Developers ра…
  6. Sep 29, 2026🤖 Обновленный гайд по поиску лагов UI в Android Показано как искать проблемы на версиях A…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →