Технический аудит качества кода: кому нужен и как его правильно проводить

Аудит ИТ-продукта практически всегда связан с какой-то острой для заказчика проблемой с которой он обращается к нам в поисках выхода. Стандартизация процесса и внедрение специальных чек-листов позволяет нам с первых шагов аудита выявлять явные и скрытые боли клиента, находить нужный подход и в результате делать наших заказчиков довольными. 

Как понять, что вам нужен аудит и c чего лучше начать, расскажем на примере технического аудита качества кода (как одного из этапов аудита). В завершение поделимся чек-листом, который позволит не упустить важные моменты.

В каких случаях проводят аудит качества кода

Технический аудит качества кода мобильного приложения включает анализ существующей кодовой базы и разработку рекомендаций по ее улучшению. Проводят его в нескольких случаях:

• При смене подрядчика. 

Новый подрядчик должен понять, в каком состоянии находится приложение. Для этого он проводит разные виды аудита, в том числе аудит качества кода.

• Для анализа качества приложения при реализации сторонним подрядчиком. 

Аудит позволит заказчику убедится в качестве реализованных решений.

• Если есть вопросы к работе текущей команды проекта: много багов, затягивание сроков, «вечный» рефакторинг и прочее. 

Аудит поможет понять, какие проблемы есть в приложении и расставить приоритеты для их исправления. В случае необходимости можно проанализировать причины возникновения багов, но наш опыт подсказывает, что лучше разделять аудит кода и исследование причин ошибок. 

• Для оценки готовности приложения к масштабированию

Нередко аудит проводят, когда хотя оценить, готово ли приложение к масштабированию и другим амбициозным планам по его развитию.

• Когда работа команды устраивает, но для уверенности хочется получить мнение стороннего эксперта о качестве кода.

Предположим, что у вас есть молодая команда из 2-4 специалистов, которая еще набирается технического опыта. Она ведет разработку приложения на протяжении определенного периода, но хочет, чтобы кто-то провел аудит и подсказал, оптимальны ли выбранные технические решения, какие риски есть и как их можно избежать.

• Для самостоятельной оценки качества кода с целью определения ключевых точек роста проекта и конкретных шагов для их реализации.

Предположим, у вас есть внутренний проект, на котором работает небольшая команда или всего один разработчик. Другие специалисты заняты своими проектами и не могут провести аудит вашего. В этом случае набор артефактов для аудита (чек-лист, регламент) поможет вашей команде посмотреть на код незамыленным глазом. 

Технический аудит кода не проводит глубокий аудит безопасности кода и не исследует процессы на обеспечение качества, скорости, надежности и прочего. В ходе технического аудита кода не происходит поиск багов и определение их критичности, а только подсвечиваются проблемные зоны и риски в коде проекта. Поэтому в зависимости от целей заказчика технический аудит кода может быть дополнен аудитом процессов, качества проекта, безопасности кода.

С чего начать технический аудит кода

Во-первых, описать контекст-проекта, который включает: 

• Бизнес-цель проекта.
• Ключевые функции.
• Системы для интеграции.
• Состав команды.
• Описание процесса разработки.

Описать контекст может руководитель проекта и члены команды.

Пример 1.

• Бизнес-цель: Предоставить риелторам удобный способ работы на объекте через мобильный интерфейс с функциями CRM-системы. 
• Ключевые функции: просмотр списка объектов для обхода, взятие объекта в работу, указание информации по объекту с прикреплением фото и т.п.
• Система для интеграции: CRM на Битрикс.
• Состав команды: 2 Flutter-разработчика, QA-специалист, аналитик, дизайнер, Битрикс-разработчик, руководитель проекта. 
• Описание процесса разработки: разработка ведется итеративно. В мобильном приложении может параллельно разрабатываться от 1 до 3 крупных фич. В релиз, как правило, попадают 1-2 крупные фичи. Битрикс-разработчик разрабатывает фичи не только для мобильного приложения, но и для CRM. 

Во-вторых, определить цель аудита для бизнеса. 

Необходимо поговорить с заинтересованными сторонами, собрать их ожидания по аудиту, выявить и сформулировать основную цель, согласовать ее с заказчиком. Если неправильно понять потребность аудита, время и деньги будут потрачены зря.

Пример 2. Цель — кратно увеличить объем поставки фич. 

В-третьих, сформулировать вопросы, которые определяют достижение цели. 

Допустим на проекте есть проблема — долгий time-to-market. Формулируем цель — увеличить поставку бизнес-фич в 3 раза за один спринт. Далее анализируем проблему, выдвигаем гипотезы о возможных причинах. Формулируем причины в виде вопросов, на которые должен ответить аудит. 

Вопросы к примеру 2:

1. Позволяет ли текущая архитектура мобильного приложения вести параллельную разработку двумя и более командами?
2. Насколько архитектурный подход к проектированию фич позволяет легко их расширять? 
3. Минимальны ли трудозатраты на инфраструктурные задачи при создании новой фичи?

Чек-лист и инструменты для разработки и профилирования помогут ответить на эти вопросы.

Примеры инструментов.

• Плагин зависимостей, который позволяет строить визуальное отображение зависимостей между модулями. На их основе можно понять связность модулей. Если она высокая, то нескольким командам будет сложно работать, они будут зависеть от результатов друг друга.
• Плагины зависимостей версий библиотек. Инструмент показывает корневые зависимости и пути к ним, а также актуальность версий библиотек. Это дает понимание, что надо в проекте, а что нет, позволяет выявить проблемы, связанные с обновлением версий библиотек.
• Плагины работы с таблицами, которые позволяют визуализировать таблицы в базе данных и определять, насколько корректно спроектирована база данных, и выявлять ее избыточность.
• Gradle Doctor позволяет исследовать скорость сборки Android-приложения. Скорость сборки приложения влияет на скорость разработки фич.
• Инструменты анализа производительности, расхода памяти, заряда, передачи данных по сети и прочего. Они помогают в анализе конкретных проблем, возникающих при работе с приложением. Инструменты для iOS и Android

Чек-лист технического аудита кода 

Мы в SimbirSoft разработали чек-лист для технического аудита кода. Ниже — небольшая выдержка. Но уже эта информация поможет сократить время на аудит и не упустить важные моменты.

Архитектура

• Подходят ли для проекта выбранная архитектура и/или архитектурные решения? Насколько верно они реализованы?
• Используется подход Clean Architecture?
• Есть деление на модули при необходимости?
• Есть ли в приложении логичная структура пакетов?

Верстка

• Если это относительно новое приложение, построен ли UI на базе Compose или SwiftUI?
• Есть ли в проекте гибкая структура работы со стилями UI-компонентов?
• Правильно ли организована работа с ресурсами в верстке?
• Есть ли поддержка локализации?
• Переиспользуются ли компоненты UI между экранами?

Инженерная культура

• Зафиксирован ли code style и любые другие правила написания кода на проекте? Придерживаются ли их участники команды?
• Используется ли статический анализатор кода на постоянной основе и встроен ли он в CI/CD?

Реляционная база данных (БД)

• Есть ли миграции? 
• Проверяются ли миграции БД тестами?
• Используются ли индексы и транзакции?

В рамках аудита мы оцениваем и то, как код пишется, определяем, как настроен CI/CD и как проводится code review. Мы решили оценивать эти моменты не в рамках аудита процессов, а в ходе технического аудита кода, поскольку они непосредственно влияют на качество кода.

На выходе аудита получаем заполненный чек-лист, а также вывод и рекомендации для команды разработки и бизнеса.  Ниже — небольшая выжимка из аудита.

Подводя итоги анализа можно отметить, что качество кода находится на приемлемом уровне. Описанные проблемы могут повлиять на разработку следующим образом:

• Недостаточно сильное разделение кода на отдельные сценарии и фичи повышает трудозатраты на координацию работы между командами, усложняет написание модульных тестов и может привести к потенциальным ошибкам.

Для устранения данных проблем предлагаем следующие решения:

• Реализовать модуляризацию:

1. Осуществить плавный переход на другую библиотеку DI.
2. Разделить слои Clean Architecture каждой фичи на пакеты.
3. Инвертировать зависимости (Dependency Inversion из SOLID) во всех слоях, предусмотренных Clean Architecture.

И это, как вы поняли, только один вывод и одна рекомендация. Не стал приводить много, поскольку в каждом случае они будут уникальными.

Такая фокусировка аудита на бизнес-цели, использование шаблона и чек-листа позволяет:

• сократить аудит с двух недель до 3-5 дней для проектов среднего размера в 30-50 экранных форм или 20 тысяч строк кода. 
• повысить удовлетворенность клиентов результатами аудита. На выходе бизнес получает ответы на все интересующие вопросы.

Если остались вопросы, пишите нам.