[Перевод] AndroidAudit. Ваше Android-приложение как место преступления27.06.2016 18:48

От переводчика: оценка процесса и результата разработки — достаточно субъективная вещь, если не используется какая-либо мера весов. Можно долго спорить: табы или пробелы, git или mercurial, maven или gradle, но такие споры все равно скатываются к вкусовщине и каким-то частным случаям. Другое дело — соблюдение однородности проекта, вот это уже вполне себе измеримая величина.

Плохая методология лучше её отсутствия.

Помимо общих вещей, найдутся и специфические, присуще только мобильной разработке, только под Android. Pedro Vicente Gómez Sánchez из Karumi в своей работе разобрал по косточкам основные технические области и задал меткие вопросы для правильной, объективной оценки разработки для платформы Android. Если появится задача: оценить чужой проект, то рекомендую воспользоваться его методологией. Я воспользовался этой методологией, как чек листом. На выходе получился вполне понятный не профессионалу документ, где напротив каждой категории — конкретная величина соответствия правильности от 0 до 1.

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

Система контроля версий

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

• Есть ли у вас правильно настроенный *ignore файл, чтобы файлы метаданных IDE и другие посторонние элементы не попадали в хранилище?
  
• Сторонние библиотеки сконфигурированы в качестве внешних зависимостей или лежат в хранилище?
  
• Достаточно ли краткие и выразительные комментарии к коммитам (commits) вы используете?
  
• Является ли размер ваших коммитов обоснованным?
  
• Все ли файлы в коммите связаны с одной и той же проблемой или функциональностью?
  
• Используете ли вы какие-либо схемы ветвления типа «feature branch» или «git-flow»?
  
• Достаточно ли информативны названия веток?
  
• Используете ли вы систему pull request/code review до слияния кода в master?
  
  • Есть ли у вас какой-либо регламент относительно того, на что нужно обращать внимание при рассмотрении PR (pull request)?
    
  • Сколько комментариев в среднем приходится на каждый PR?
    
  • Сколько людей рассматривает каждый PR?
    
  • Сколько »+1» к PR вам нужно для слияния?
    
  • Кто несет ответственность за закрытие ветки?
  
  
• Вы используете release branches для каждого релиза?
  
• Как долго открыт процесс подготовки (staging process)?
  
• Сколько исправлений вы вносите в release candidate, прежде чем выпустить его?
  
• Имеется ли возможность переключиться на точный код какой-либо из опубликованных версий вашего приложения?
  
• Сколько исправлений (hotfix) вы выпустили в прошлом году?
  
• Вы объединяете (squash) коммиты до слияния (merging) его в master/develop ветку?
  
• Готовы ли master/develop ветки к выпуску в любое время?

Инструменты сборки

Определяющим фактором является возможность запустить процесс сборки на машине разработчика и на любой другой внешней системе, например на системе непрерывной сборки (continuous integration).

• Сколько библиотек используются в проекте?
  
• Разделен ли проект на модули?
  
• Используют ли модули Maven или Gradle для разрешения зависимостей, или используются локальные .jar-файлы?
  
• На опасное ли расстояние приближен проект к лимиту количества методов в .dex файлах? Или уже за гранью?
  
• Вы используете библиотеки, которые не нужны в проекте?
  
• Используется ли multidex?
  
• Все ли внешние зависимости обновлены до современных версий?
  
• Все ли лицензии сторонних библиотек соблюдены?
  
• Используются ли устаревшие или не поддерживаемые сторонние библиотеки?
  
• Обусловлен ли минимальный SDK требованиями технического задания (product description)?
  
• Актуален ли целевой SDK (target SDK)?
  
• Используется ли ProGuard или любой другой инструмент обфускации (obfuscation — запутывание)? Он включен и правильно настроен?
  
• Учетные данные хранилища ключей (keystore credentials) и учетные данные Google Play хранятся в надежном месте?
  
• Хранилище ключей приложения (application keystore) и учетные данные хранятся в надежном месте?
  
• Должным ли образом настроены build types?
  
• Правильно ли используются flavors?
  
• Правильно ли настроен релизный тип сборки?
  
• Включена ли опция резервного копирования?
  
• Включен ли Lint? Он успешно проходит проверку?
  
• Имеется ли инструмент статического анализа? Он настроен и успешно проходит проверку?
  
• Есть ли Checkstyle? Он настроен и успешно проходит проверку?
  
• Правильно ли настроен id приложения и version name/code?
  
• Вы используете какую-либо структуру или стратегию версионирования id?
  
• Используется ли инструмент непрерывной сборки (continous integration), правильно ли он настроен?
  
• Автоматизирован ли процесс выпуска новых версий?

Использование Android ресурсов

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

• Существуют ли какие-либо недостающие ресурсы для densities, flavors и build types?
  
• Требуется ли поддержка приложением экранов с различной плотностью пикселей (density) по техническому заданию?
  
• Используются ли в приложении drawable/mipmap, шрифты или векторные ресурсы?
  
• Существуют ли какие-либо недостающие переводы?
  
• Автоматизирован ли процесс перевода?
  
• Какой язык выбран по умолчанию для перевода?
  
• Использует ли приложение сторонние шрифты?
  
• Использует ли приложение значения конфигурации внутри файла строковых ресурсов?
  
• Соблюдается ли соглашение для присвоения однородных имен ресурсам?
  
• Есть ли параметры конфигурации, связанные с аппаратными средствами устройства, правильно ли они настроены?
  
• Поддерживаются ли планшеты?

Использование Android Layout

Как мы уже говорили ранее, существует широкий спектр Android устройств в мире, каждый из них с собственным размером и плотностью экрана. Определяющим фактором является правильное использование Android Layouts.

• Возникают ли проблемы с производительностью из-за количество слоев в макетах (layouts) приложения?
  
• Используете ли вы темы и стили?
  
• Используются ли повторно макеты (layouts) с использованием «include» тега?
  
• Вы используете правильный тип группировок в макетах?
  
• Учтены ли различные размеры экранов в макетах?
  
• Используется ли какое-либо соглашение об именовании, чтобы присваиваемые имена макетам и виджетам оставались однородными?
  
• Списки реализованы с использованием ListView или RecyclerView?
  
• Правильно ли используется Android Support Library?

Права доступа

Запрос возможных действий приложения (permissions) увеличивает доверие пользователей к нему, а также расширяет его возможности за счет «прозрачной» интеграции с другими сервисами.

• Все ли запрашиваемые разрешения (permissions) действительно необходимы?
  
• Разрешение используется намеренно?
  
• Есть ли отсутствующие разрешения?
  
• Если целевой SDK больше, чем 23, то «опасные разрешения» запрашиваются с помощью системы разрешений совместимости (compatibility permissions system)?
  
• Разрешение запрашиваются тогда, когда они будут использоваться?
  
• Есть ли обратная связь с пользователем, объясняющая, почему какое-либо разрешение необходимо?

Проблемы с безопасностью

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

• Настроен ли HTTP клиент на использование HTTPS?
  
• Настроен ли HTTP клиент на использование встроенного сертификата (certificate pinning) и сообщений аутентификации с HMAC?
  
• Сохраняет ли приложение конфиденциальную информацию пользователя? Где?
  
• Сохраняет ли приложение информацию вне внутренней системы хранения данных?
  
• Логируется (logging traces) ли приложение при сборке релиза?
  
• Обфусцирован (obfuscated) ли код приложения?
  
• Предоставляет ли ваше приложение поставщика контента (Android content provider), приемника (receiver) или сервис другим приложениям?
  
• Отключена ли опция «debuggable» в релизной сборке?

Push уведомления (Push Notifications)

Push — это отличный механизм для информирования наших пользователей в любое время, но это более сложная проблема, чем кажется на первый взгляд.

• Используется ли сторонняя библиотека для реализации системы Push-уведомлений?
  
• Используется ли система GCM для передачи информации приложению, или просто, чтобы показывать сообщения пользователю?
  
• Как ведет себя приложение при получении Push-уведомления?
  
• Как ведет себя приложение, когда связанная с Push-уведомлением информация не та, что ожидалась?
  
• Показываются ли уведомления с использованием API совместимости (compatibility API)?

Производительность

Производительность имеет большое значение. Никто не захочет использовать на своих дорогих устройствах медленное приложение. Производительность — это деньги.

• Есть ли в приложении какие-либо утечки памяти?
  
• Настроен ли в develop сборке какой-либо анализатор памяти, как, например, «LeakCanary»?
  
• Android Strict Mode подключен и настроен в develop сборке?
  
• Как в приложении используются потоки? Вы используете async tasks, intent services или любые другие сторонние библиотеки?
  
• Вызывает ли количество фоновых потоков проблемы с производительностью?
  
• Используете ли вы какие-либо политики планировщика (scheduler policy) или просто создаются потоки по требованию?
  
• Поддерживаете ли вы Android Doze Mode?
  
• Прослушиваются ли события, связанные с состоянием сети или любого другого повторяющегося события от операционной системы?
  
• Основной поток используется только для выполнения задач, связанных с кодом пользовательского интерфейса?
  
• Имеются ли в приложении какие-либо политики кеширования?
  
• Настроен ли клиент HTTP на использование тайм-аута?
  
• Настроен ли клиент HTTP на использование GZIP?
  
• Работает ли пользовательский интерфейс приложения со скоростью 60 кадров в секунду?
  
• Нет ли таких custom view, для которых выделяется слишком большой объем памяти, или которые выполняют «дорогостоящие» задачи в потоке пользовательского интерфейса (UI thread)?
  
• Вы тестируете ваше приложение на lower-end (бюджетных, непроизводительных) устройствах?
  
• Не «тормозит» ли прокрутка recycler view?
  
• Для загрузки изображений используется какая-либо сторонняя библиотека или у вас есть своё собственное решение?
  
• Изображения масштабируются под размеры экрана или сразу загружаются под определенный экран устройства?
  
• Разумно ли использование памяти?
  
• Правильно ли используется модификатор «Static» в Java?
  
• Все ли задачи, связанные с обработкой изображений, могут обрабатывать несколько изображений за раз?
  
• Работает ли система статистики в фоновом потоке и сконфигурирована ли она с правильным приоритетом?
  
• Оптимизируется ли код в релизной сборке?

Структура Java Packages

Хорошая структура пакетов сделает наш код более масштабируемым.

• Используются ли пакеты для разделения кода по функционалу (features) или концепциям (например, Login vs User)?
  
• Используются ли модификаторы видимости Java, чтобы скрыть детали реализации внутри пакетов?
  
• Все ли пакеты выходят из корневого пакета?
  
• Повторяет ли директория с тестами структуру исходной папки?
  
• Организованы ли различные функции (features) с помощью одной и той же структуры пакетов?
  
• В правильных ли пакетах лежат классы?
  
• Соблюдаются ли соглашения об однородном названии пакетов?
  
• Связано ли название корневого пакета с именем компании?

Code Style

Согласованная с точки зрения стиля кодовая база помогает нашим инженерам читать код проще. Инженер читает ГОРАЗДО больше кода, чем пишет, так что это важное понятие.

• Является ли codestyle однородным?
  
• Используете ли вы венгерскую нотацию?
  
• Есть ли какой-либо инструмент Checkstyle? Он настроен и работает?
  
• Соответствует ли код Java codestyle?
  
• Вы используете табуляцию или пробелы?
  
• Правильно ли названы классы?
  
• Используете ли вы «I» в качестве префикса интерфейсов или «Impl» как суффиксы реализации?
  
• Используете ли вы правильные имена переменных?
  
• Используете ли вы правильные имена для полей (fields)?
  
• Используете ли вы правильные имена для методов?
  
• Используются ли атрибуты и модификаторы видимости методов должным образом?
  
• Код написан на английском языке?
  
• Используете ли вы Javadoc?
  
• Вы пишете комментарии к коду?
  
• Используете ли вы константы или перечисления (enums), чтобы избежать дублирования литералов?

Offline реализация

Обеспечение хорошей работы в режиме offline является отличительным фактором наших приложений.

• Может ли приложение использоваться, когда нет подключения к сети Интернет?
  
• Каково поведение приложения при медленном сетевом соединении?
  
• Какое поведение приложения при потере запроса из-за сбоя в сети?
  
• Синхронизируются ли изменения данных приложения с бекэндом после того как соединение было восстановлено?
  
• Настроен ли тайм-аут на сетевое соединение?
  
• Настроена ли политика кеширования HTTP?
  
• Сеанс пользователя восстанавливается автоматически?

Архитектура

Архитектура приложений, с точки зрения кода, является одной из частей аудита, которая дает нам более глубокое представление о приложении. В ходе обзора архитектуры приложения мы будем сосредоточены на понятиях, связанных с S.O. L.I.D и Clean Code принципами.

Реализация слоя представления (Presentation Layer Implementation)

• Используется ли какой-либо паттерн, связанный с реализацией GUI (графического интерфейса пользователя)? Model View Presenter или Model View ViewModel два из наиболее часто используемых шаблонов для разработки приложений. Правильно ли они реализованы?
  
• Связана ли реализация слоя представления (presentation layer) с реализацией вида (view implementation)?
  
• Связана ли реализация вида (view implementation) c реализацией модели (model implementation)?
  
• Включает ли слой представления бизнес-логику?
  
• Правильно ли реализация вида использует Android SDK tools?
  
• Используете ли вы сторонние библиотеки для упрощения реализации вида?
  
• Разделена ли реализация разных функций по отдельным activities или fragments?
  
• Однородно ли поведение пользовательского интерфейса?
  
• Используете ли вы custom views для повторного использования кода пользовательского интерфейса?

Реализация предметной области (Domain Implementation)

• Есть ли отдельный слой предметной области (domain layer) или вся бизнес-логика реализована в слое представления (presentation layer)?
  
• Выражены ли правила предметной области и различные требования к приложению в основных объектах бизнес-логики?
  
• Реализован ли слой предметной области с применением принципов ООП?
  
• Связан ли слой предметной области с Android SDK или любой сторонней библиотекой?
  
• Связан ли слой предметной области со слоем представления?
  
• Является ли модель предметной области (domain model) «анемичной»?
  
• Используете ли вы «толстые» модели предметной области?
  
• Основан ли код на слабо связанных и, в то же время, хорошо взаимодействующих друг с другом компонентах?
  
• Реализована ли обработка ошибок с использованием исключений или какого-либо другого механизма обработки ошибок?
  
• Сопоставляются ли данные (mapped) между различными слоями?
  
• Влияет ли архитектура внешних компонентов (например, схемы базы данных или парсинга JSON) на архитектуру модели предметной области?
  
• Разработчики злоупотребляют наследованием?
  
• Дублируется ли код?
  
• Есть ли dependency injection библиотеки или сконфигурированный service locator?
  
• Не слишком ли высока сложность классов и методов?

Реализация API

• Привязана ли реализация API к Android SDK?
  
• Происходит ли «утечка» через API каких-либо деталей реализации из-за клиента HTTP или используемой библиотекой для реализации сетевого слоя?
  
• API клиент посылает правильные заголовки?
  
• Каково поведение API клиента для различных ответов HTTP?
  
• API клиента реализует механизм аутентификации?
  
• Правильно ли реализован процесс возобновления сеанса?
  
• Есть ли поддержка обфускации JSON?
  
• Разделена ли реализация API для различных клиентов?

Реализация Хранения

• Где хранится информация?
  
• Используются ли транзакции при чтении и записи информации в хранилище?
  
• Надежно ли хранение конфиденциальной информации пользователя?
  
• Использует ли слой хранения какие-либо сторонние библиотеки?
  
• «Утекают» ли детали реализации через слой хранения?
  
• Правильно ли спроектированы tables/schemas?
  
• Запросы, отправленные в хранилище, оптимизированы?
  
• Используются ли Android SDK APIs для хранения данных в правильном месте? Сохраняются ли данные в базу данных, а настройки (preferences) и небольшие по объему данные в Shared Preferences и файлы на диске?

Тестируемость

• Есть ли у приложения тесты?
  
• Является ли приложение тестируемым?
  
• В приложении используются различные виды (unit/integration/end-to-end) тестов?
  
• Правильно ли названы тесты?
  
• Достаточно ли тесты охватывают проект?
  
• Есть ли чрезмерное документирование (overspecification) в тестах?
  
• Время выполнения разумно?
  
• Не слишком ли низко покрытие кода?
  
• Существуют ли какие-либо игнорируемые тесты?
  
• Есть ли нестабильные тесты (flaky tests)?
  
• Используете ли вы современные фреймворки для тестирования?
  
• Существуют ли какие-либо тесты без утверждений (tests without asserts)?
  
• Тесты и продакшен код написаны одними и теми же разработчиками?
  
• У вас есть команда QA?
  
• У вас есть команда QA, автоматизирующая часть тестов?
  
• Есть ли у вас какие-либо системы непрерывной интеграции (continuous integration system)?
  
• Используете ли вы builders, factories или mothers, чтобы уменьшить затраты на создание некоторых объектов, которые необходимы для тестов?
  
• Тесты утверждений (assertions) правильно написаны?
  
• Проводите ли вы более одного логического утверждения на тест?
  
• У вас есть различные наборы тестов, связанные с одним и тем же проектом?
  
• Вы используете различные подходы тестирования для различных частей приложения?
  
• Используете ли вы какой-либо monkeyrunner?
  
• Следуете ли вы какой-либо TDD или BDD методологии?
  
• Используете ли вы Java, чтобы написать тестовые варианты (test cases)?

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

Автор: Pedro Vicente Gómez Sánchez.

© Habrahabr.ru