Аудит кода и оценка работы подрядчика

Проблема: нет уверенности в качестве работы

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

Нет возможности проверить подрядчика самостоятельно

Приложение разработала аутстафф-команда. У компании нет штатных Flutter-специалистов, поэтому поддерживает приложение та же команда.

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

Разработали нестандартный план и параметры для оценки подрядчика

У заказчика не было конкретного плана, поэтому мы составляли его вместе.

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

Этап 1. Первичный аудит

1. Анализ приложения. Здесь мы собирались составить рекомендации по улучшению приложения. Это стандартная процедура аудита кода.
2. Передача подрядчику для доработки. Это нужно для улучшения качества продукта.
3. Запрос оценки полноты выполнения требований. Это поможет оценить, насколько объективно команда подрядчика оценивает свои работы.

Этап 2. Повторный аудит

1. Постаудит приложения. То есть еще раз оценить приложение по тем же параметрам. Добавили этот этап, чтобы оценить, сколько требований выполнил подрядчик. С этими данными мы сможем оценить эффективность внешней команды.
2. Сравнение оценок. Оценки от нас и от подрядчика могут отличаться. Значительные различия могут означать, что подрядчик либо недостаточно компетентен, либо скрывает недостатки своей работы.

Заказчик утвердил этот план. Мы составили список задач для обеих проверок. Объём работ был большой, поэтому компания объявила тендер по этому плану и задачам. Мы выиграли тендер и приступили к работе.

Нашли четыре зоны роста по итогам первого аудита

Мы учли время, необходимое для получение доступов к проекту, поставленные заказчиком дедлайны и распределили работу на четыре недели. За это время мы проверили ключевые параметры приложения: архитектуру, структуру, общее качество кода, организационные процессы, качество UI/UX, безопасность, производительность. Анализировали приложение вручную и автоматизированно. Например, автоматический анализ частоты смены кадров показал, что производительность падает, когда пользователь открывает клавиатуру.

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

1. Процесс код ревью

В ходе код ревью разработчики проверяют код друг друга до того, как внести изменения. Чтобы изменить код, разработчики отправляют запросы (pull requests).

Рекомендации. Наши эксперты составили рекомендации, которые помогут более тщательно контролировать изменения в коде: предлагать по одному изменению за раз, более подробно разбивать на задачи, привлекать к ревью больше экспертов, ввести практику комментирования по современным стандартам.

Почему это важно. Когда разработчики проверяют запросы друг друга, они улучшают качество кода и обмениваются знаниями. Без код ревью команда не формирует культуру качества и постоянного улучшения. Это может негативно сказаться на качестве проекта в будущем.

2. Работа с техническим долгом

Технический долг формируется из временных решений — многие знают их как «костыли».

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

1. Вести список задач технического долга с подробными описаниями проблем и обоснованием их решения. Организовать для этого доску в Jira и создавать задачи для всего, что в техническом долге отмечено как to do.
2. Оставлять в коде ссылку на соответствующую задачу из технического долга. Описание задачи хранить в карточке этой задачи в Jira.
3. Внедрить систему приоритизации в технический долг, чтобы самые важные задачи решать в первую очередь.

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

Почему это важно. «Костыли» помогают выпустить продукт быстрее или с меньшими затратами. Но в перспективе они усложняют код, замедляют разработку и снижают качество продукта. Чтобы предотвратить задержки и избыточные расходы, техническим долгом нужно управлять: выделять время на доработку «костылей» до высококачественных решений.

3. Качество документации

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

Рекомендации. Мы рекомендовали вести системную документацию. Описали, что для этого нужно и как это лучше реализовать на примере официальных рекомендаций для фреймворка Flutter. Дали ссылки на конкретные места в коде, которые нужно иначе задокументировать или к которым нужны комментарии. Предложили составить подробную инструкцию по сборке приложения.

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

4. Качество тестирования

Тестирование кода проводят во время или после разработки, чтобы найти и устранить ошибки.

Рекомендации. Мы рекомендовали настроить автоматическое тестирование. Написать тесты для бизнес-логики, для UI и unit-тесты на найденные и исправленные ошибки. Unit-тесты позволяют проверить отдельные модули кода, чтобы избежать конфликтов при внесении исправлений.

Почему это важно. Качественное тестирование позволяет снизить число ошибок в продукте до релиза. Также тестирование освобождает разработчиков от части работ по отладке. За счёт этого разработка идёт быстрее.

В итоговом отчёте оставили 44 рекомендации. Эти рекомендации с конкретными задачами компания передала подрядчику. После новогодних праздников команда подрядчика должна была начать над ними работать.

Оценили качество устранения ошибок на втором аудите

Спустя два месяца мы провели постаудит — повторную проверку по результатам изменений. Анализировали те же параметры и уделяли особое внимание проблемам, которые выявили на предыдущем этапе.

Проверили приложение и оценили прогресс

Из 44 рекомендаций подрядчик полностью выполнил 14. По нашим оценкам, большую часть остальных рекомендаций команда выполнила меньше, чем на 50%. При этом сам подрядчик оценивал полноту выполнения выше.

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

Выявили расхождения в оценках

Мы и внешняя команда по-разному оценили полноту доработок. Больше всего отличались оценки код ревью и технической документации. Подрядчик отметил, что не выполнил часть рекомендаций, чтобы быстрее разрабатывать и запускать новые версии продукта.

Финальный отчёт по итогам аудита

Мы распределили приоритеты доработок: три задачи с высоким приоритетом, три — со средним, четыре — с низким.

Первый приоритет:

1. Усовершенствование работы с системой контроля версий.
2. Непрерывное поддержание чистоты кода.
3. Системная работа с техническим долгом.

Второй приоритет:

1. Доработки инструкции по сборке приложения и документации нового кода.
2. Рекомендации по работе со статическим анализатором кода.
3. Более подробное описание структуры приложения.

Третий приоритет:

1. Несущественные улучшения архитектуры приложения.
2. Включение дополнительных вариантов сборки в инструмент управления версиями FVM.
3. Усовершенствование тест-кейсов.
4. Создание инструкций для настройки Git Hook.

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

«Чтобы провести хороший аудит, нужно уметь не только критиковать, но и предлагать. По результатам аудита мы предоставляем клиенту подробный отчёт, в котором
основную ценность имеют рекомендации. На самом деле клиенту нужен не аудит сам по себе. Клиент хочет, чтобы у него всё было хорошо в проекте. Именно поэтому
для каждой обнаруженной нами проблемы мы предлагаем один или несколько
вариантов её решения».

Евгений Сатуров
Head of Flutter в Surf

Результат: приложение стало безопаснее, код качественнее, процессы автономнее

В результате компания:

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

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

Компания довольна аудитом и результатом нашей работы.

«Нам было очень приятно сотрудничать с Surf. Команда всегда работала слаженно, своевременно информировала нас о прогрессе и выполняла задачи в срок. Меня особенно порадовал высокий уровень компетентности команды во всех задачах проекта. В ходе всего проект было видно, что клиентоориентированность
у сотрудников Surf в крови. Спасибо большое за вашу работу».

Проектный менеджер в ритейл-компании