Как проверить качество кода при мобильной

Коротко: Проверка качества мобильного кода включает технический аудит архитектуры, анализ безопасности, тестирование производительности и проверку на соответствие законодательству РФ (реестр Минцифры, требования КИИ). Основные задачи - исключить уязвимости, обеспечить работу приложения на отечественных ОС и подтвердить право на использование ПО через контроль над исходным кодом, что критично для объектов критической информационной инфраструктуры.

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

Технический аудит кода перед запуском проекта

Запуск мобильного приложения без предварительного анализа - это риск получить технический долг, который «выстрелит» в первый же месяц эксплуатации. Технический аудит нужен не для того, чтобы найти опечатки в переменных, а чтобы понять, выдержит ли логика приложения рост нагрузки и насколько легко будет внедрять новые функции. Когда разработчики пишут код, они часто фокусируются на том, чтобы фича заработала «здесь и сейчас», забывая о масштабируемости. В итоге через полгода любое изменение интерфейса превращается в переписывание половины модулей.

Проверка качества мобильного кода начинается с анализа чистоты кода (Code Quality). Мы смотрим, соблюдаются ли стандарты написания (например, Google Style Guide для Swift или Kotlin), нет ли избыточных циклов и правильно ли используются паттерны проектирования (MVVM, VIPER или MVI). Если архитектура перегружена или, наоборот, слишком примитивна, приложение будет «тормозить» или падать при попытке выполнить сложные операции. Это напрямую влияет на пользовательский опыт и удержание аудитории.

На что смотреть при аудите:

• Связность модулей. Если изменение одного экрана требует правки кода в пяти других местах - архитектура нарушена.
• Обработка ошибок. Приложение не должно просто «вылетать» при отсутствии интернета или неверном ответе от сервера. Код должен содержать механизмы перехвата исключений.
• Управление памятью. Утечки памяти (Memory Leaks) - главная причина, по которой мобильные приложения «пожирают» заряд батареи и замедляют смартфон.

Важно понимать, что аудит должен проводиться не только вручную, но и с помощью статического анализаторов (SAST). Инструменты вроде SonarQube или специализированные линтеры позволяют автоматически найти потенциально опасные участки. Однако автоматика не видит логических дыр. Например, алгоритм может быть идеальным с точки зрения синтаксиса, но при этом неверно обрабатывать состояние транзакции в банковском приложении. Поэтому полноценный аудит мобильного приложения - это всегда гибрид автоматики и глубокого экспертного ревью.

Критерии оценки архитектуры и безопасности приложения

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

Одним из ключевых критериев является защита данных при передаче (Data in Transit) и при хранении (Data at Rest). Даже если вы используете HTTPS, важно проверить, не допускает ли код использование устаревших протоколов TLS или слабых методов шифрования. Если ключи шифрования зашиты прямо в исходный код (hardcoded keys) - это критическая уязвимость, которую легко обнаружить простым декомпилятором. Для серьезных продуктов, таких как банковские или логистические приложения, это недопустимо.

Архитектура также оценивается с точки зрения интеграции с API. Мобильное приложение - это лишь «лицо» системы, вся логика должна быть на стороне бэкенда. Если бизнес-логика (например, расчет скидки или проверка баланса) выполняется на стороне клиента, это делает приложение уязвимым для подмены данных через прокси-серверы. Правильная архитектура подразумевает, что клиент получает только готовый результат, а все проверки проходят на защищенном сервере.

При выборе подрядчика на разработку важно требовать отчет о прохождении тестов на проникновение (Penetration Testing). Это не просто проверка кода, а имитация реальной атаки на приложение. Если разработчик утверждает, что «у нас всё безопасно», - это не аргумент. Аргументом является отчет, где указаны векторы атак, которые были протестированы, и подтверждение того, что уязвимостей уровня Critical и High не обнаружено.

Как проверить соответствие реестру российского ПО

Для многих компаний в России вопрос использования импортного софта перешел из разряда «желательного» в разряд «критического». С 1 марта 2026 года правила игры изменились: ключевым критерием включения в реестр Минцифры стал не только факт владения правами, но и возможность контроля над программным обеспечением. Это означает, что если вы заказываете разработку приложения на аутсорсе, вы должны быть уверены, что по итогам контракта вы получаете полный контроль над исходным кодом и не зависите от зарубежных сервисов доставки кода.

Проверка соответствия реестру - это не только проверка названия в списке на сайте Минцифры. Нужно убедиться, что софт не использует компоненты, которые прямо запрещены или делают невозможным включение продукта в реестр. Важно следить за изменениями в законодательстве: например, приказ Минцифры от 25.12.2025 № 1246 может накладывать дополнительные обязательства на разработчиков в части документирования кода.

При проверке обратите внимание на следующие моменты:

• Статус правообладателя. Проверьте, является ли компания-разработчиком российским юрлицом.
• Отсутствие иностранных компонентов. Если приложение критически зависит от проприетарных библиотек, которые нельзя легально использовать или обновлять в РФ, оно не пройдет проверку.
• Соответствие функционала. Проверьте, совпадает ли заявленный в реестре функционал с тем, что фактически реализован в приложении.

Если ваша компания планирует использовать приложение в государственных процессах или в секторе КИИ, проверка соответствия реестру должна стать этапом приемки (UAT). Нельзя ждать завершения проекта, чтобы узнать, что ваше приложение не подходит под требования регулятора. Это должно быть заложено в техническое задание на этапе проектирования.

Стандарты доверенного ПО и требования КИИ

Для субъектов критической информационной инфраструктуры (КИИ) требования к софту максимально жесткие. Согласно постановлению Правительства РФ № 1937 от 28.11.2025, понятие «доверенное программное обеспечение» получило четкое юридическое определение. Это софт, который прошел проверку на отсутствие закладок, недокументированных возможностей и соответствие стандартам безопасности, установленным регуляторами.

С 1 июня 2026 года новые требования для продуктов, попадающих в сферу КИИ, уже действуют в полном объеме. Это означает, что если ваше мобильное приложение управляет доступом к объектам КИИ (например, через систему управления умным заводом или через мобильный терминал), оно должно соответствовать стандартам доверенного ПО. Одно из главных требований - поэтапный переход на 100% российское ПО на значимых объектах КИИ, который завершится к 1 января 2036 года, но для многих секторов ускорение процесса уже началось.

Что включает в себя проверка на «доверенность»:

1. Анализ цепочки поставок (Supply Chain Security). Проверка всех сторонних библиотек на предмет их происхождения.
2. Отсутствие недокументированных функций. Проверка кода на наличие скрытых команд, которые могут активироваться при определенных условиях.
3. Механизмы подписи кода. С учетом новых правил выдачи российских сертификатов для подписи кода (вступление в силу с 1 марта 2027 года), приложение должно быть подписано доверенным сертификатом, который подтверждает авторство и целостность.

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

Методы тестирования производительности и нагрузки

Мобильное приложение работает в условиях нестабильной среды: плохой сигнал связи, ограниченный заряд батареи, перегрев процессора. Поэтому тестирование производительности (Performance Testing) должно имитировать эти условия. Недостаточно проверить, как приложение работает на последнем iPhone в офисе с идеальным Wi-Fi. Нужно проверить, как оно ведет себя при переключении с 4G на Edge или при работе в режиме экономии энергии.

Существует несколько подходов к тестированию нагрузки:

• Нагрузочное тестирование (Load Testing). Проверка работы приложения при ожидаемом количестве пользователей.
• Стресс-тестирование (Stress Testing). Попытка «сломать» систему путем экстремального увеличения нагрузки, чтобы понять точку отказа.
• Тестирование стабильности (Endurance Testing). Длительная работа приложения под нагрузкой, чтобы выявить утечки памяти или переполнение дискового пространства.

При тестировании мобильного приложения критически важно разделять нагрузку на клиентскую и серверную части. Часто проблема кроется не в самом приложении, а в том, что API не справляется с количеством запросов от мобильных клиентов. Тестировщики должны использовать инструменты имитации сетевых задержек (Network Emulation), чтобы увидеть, как интерфейс реагирует на долгий отклик сервера. Если приложение «замирает» (UI Freeze) во время ожидания ответа - это ошибка проектирования потоков (threading).

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

Типичные ошибки при передаче исходного кода

Когда проект переходит от одного подрядчика к другому или возвращается заказчику, передача исходного кода часто становится зоной конфликтов. Основная проблема - это не только наличие самого кода, но и его «читаемость» и полнота. Если вам передали архив с файлами, но не передали инструкции по развертыванию (Deployment Guide) и описание архитектуры, этот код практически бесполезен.

Типичные ошибки при передаче:

1. Отсутствие документации к API. Разработчики часто забывают описать, какие параметры принимает и возвращает каждый метод. В итоге новый штат программистов тратит недели только на то, чтобы понять, как работает ваш бэкенд. 2. Hardcoded-конфигурации. Если настройки подключения к базе данных или ключи API зашиты прямо в коде, а не вынесены в переменные окружения, это создает огромные проблемы при переносе проекта на другие сервера. 3. Зависимость от проприетарных инструментов сборки. Если проект невозможно собрать без специфической, платной или редкой версии среды разработки, вы становитесь заложником одного поставщика.

Еще одна серьезная ошибка - передача кода без истории изменений (Git History). Если вам прислали «слепок» (snapshot) кода без истории коммитов, вы теряете возможность понять, почему было принято то или иное архитектурное решение. Это делает аудит качества практически невозможным, так как невозможно отследить, на каком этапе возникла та или иная ошибка.

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

Стоимость проверки кода сторонними экспертами

Заказчики часто задаются вопросом: зачем платить сторонним экспертам, если разработчики сами говорят, что у них всё хорошо? Ответ прост: у разработчиков всегда есть предвзятость (bias). Они заинтересованы в том, чтобы проект был сдан в срок, и могут сознательно или подсознательно игнорировать «костыли» в коде. Сторонний аудит - это независимая экспертиза, которая дает объективную картину.

Цена на тестирование программного обеспечения сильно варьируется и зависит от глубины проверки. Нельзя оценивать аудит по количеству строк кода. Цена складывается из сложности архитектуры, требований к безопасности (например, требования КИИ значительно удорожают процесс) и объема документации, которую нужно подгототать по итогам.

Важно понимать, что дешевый аудит - это деньги на ветер. Если эксперт за неделю «проверил» проект и выдал отчет на две страницы без примеров уязвимостей - это не аудит. Качественный отчет должен содержать не только список ошибок, но и рекомендации по их устранению, а также оценку рисков для бизнеса. Инвестиции в аудит на этапе разработки всегда обходятся в разы дешевле, чем исправление критических ошибок после того, как приложение уже вышло в App Store или Google Play.

Что запомнить:

• Аудит должен быть гибридным: автоматические сканеры + глубокое ручное ревью.
• Для работы в секторе КИИ критически важно соответствие требованиям доверенного ПО и наличие контроля над кодом.
• Проверяйте не только код, но и то, как приложение ведет себя в плохих сетевых условиях и при низком заряде батареи.
• При передаче кода требуйте не только файлы, но и полную историю коммитов и инструкции по развертыванию.
• Стоимость проверки - это страховка вашего бизнеса от катастрофических расходов на переписывание системы в будущем.