Аудит банковского приложения: как выпустить качественный продукт

Аудит банковского приложения: как выпустить качественный продукт

14.01.2021
# Для_разработчиков Разработка Финтех
Author avatar
Сергей АлексеевiOS разработчик

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

Аудит банковского приложения – сложный и многоуровневый процесс. Каждый раз приходится сталкиваться с рядом задач и обеспечивать максимальную производительность приложения в каждой из них. Однако существует множество документов и руководств, в которых перечисляются основные положения и пункты, которые должны быть предусмотрены в приложении. Разберём ключевые параметры, необходимые для качественной работы любого банковского приложения.

1. Качество кода

Для проверки качества кода необходимо придерживаться следующих шагов. Безусловно, необходимо наличие стандартов для написания исходного кода, best practices и соглашений/документации. Например, SwiftLint для согласования Code Style в iOS разработке. Он позволяет настраивать различные параметры конфигурации, в частности, список правил, которые необходимо исключить; список правил, которые необходимо включить; исключить/включить подкаталоги или файлы, и т.д. Чтобы проверить следование данным стандартам, рекомендуется внедрять статистические анализаторы кода и стиля программирования. В них должны быть включены расширенные списки правил или персонализированные правила. Следует обеспечивать интеграцию отчётов о проверке анализатора в среде CI/CD, тенденцию их изменений.

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

Для проверки качества кода также рекомендуется использовать метрики качества кода, например, cyclomatic complexity, coupling, class hierarchy, code duplication`s, method cohesion. Чтобы определить какая метрика будет подходить для конкретно вашего проекта, необходимо определить текущий уровень для данных метрик.

 2. Ревью кода

В разработке должна выполняться практика обязательного ревью исходного кода для Pull/Merge Request на основе специально написанного чек-листа. Проверяются стандарты, принятые на проекте, а также корректность реализации бизнес-логики.

Также в процессе ревью исходного кода необходима проверка наличия и качества юнит тестирования. Для этого следует выбрать модули, работающие с бизнес-логикой и задать необходимый уровень покрытия тестами. Затем добавить quality gate по соответствию покрытия таргетными значениями.

3. Юнит-тестирование

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

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

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

4. Технический долг

Рекомендуется написать собственное правило для статического анализатора, которое будет определять количество to-do комментариев в коде. Задачи технического долга необходимо переносить в общий бэклог проекта (чтобы менеджер проекта видел количество и статус задач), обозначать их метками, оценить и определить, какое количество задач должно считаться минимально обязательным для новой итерации.

5. Автоматизация

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

Для автоматизированных тестов должны применяться те же стандарты кода, которые применяются и для основного кода. Их следует включить в CI/CD процесс. При возникновении ошибки тестируемую ветку невозможно объединить с исходной – это предотвращает попадание кода с ошибками в релиз.

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

6. Архитектура

Безусловно, качественный продукт должен содержать единый архитектурный стиль с чётким разделением слоёв приложения, придерживаться принципов Clean Architecture. При этом рекомендуется заканчивать миграцию кода из legacy и избавляться от данного модуля и связывающего кода. Это сильно влияет на восприятие кодовой базы с точки зрения определения архитектурного подхода и консистентности.

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

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

7. Процесс и распределение ролей

Для успешной реализации проекта в ключевой Core команде, помимо основных ролей Team Lead, Tech Lead и разработчиков, следует внедрить и другие спринтовые роли. Например, researcher, bug fixer, backloger, communicator, document creator, security champion. При этом у каждого члена Core команды должна быть своя чётко сформулированная задача на спринт. Такой подход позволяет более прозрачно определить KPI каждого участника.

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

  • уменьшение сложности проекта;
  • управление знаниями проекта: документирование процессов разработки или использование метода перекрёстного обучения.

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

8. Безопасность

Безопасность является едва ли не самым ключевым аспектом аудита приложения для мобильного банка. Читайте об этом в нашей отдельной статье !

Заключение

Опыт разработки приложений для мобильного банкинга позволил нашей команде разработчиков Joy Dev стать экспертами в данном направлении мобильной разработки. Мы активно используем и совершенствуем данные инженерные практики, чтобы создавать для вас качественные приложения высокого уровня сложности, в том числе enterprise проекты с высокими требованиями к надёжности и производительности приложений, большим количеством кода, длительным сроком использования и возможностью масштабирования. Поэтому отправляйте нам заявку, и мы обязательно свяжемся с вами и обсудим реализацию вашего проекта! 

Author avatar
Сергей АлексеевiOS разработчик
Поделись статьей в соцмедиа:
Рекомендуемые статьи
Joy Dev в топе рейтинга Tagline 2023 среди лучших IT-компаний России

Joy Dev в топе рейтинга Tagline 2023 среди лучших IT-компаний России

Joy Dev в топе рейтинга Tagline 2023 среди лучших IT-компаний России

Joy Dev в топе рейтинга Tagline 2023 среди лучших IT-компаний России

Joy Dev в топе рейтинга Tagline 2023 среди лучших IT-компаний России

Joy Dev в топе рейтинга Tagline 2023 среди лучших IT-компаний России

Призовое место “Real Cosmetology” в конкурсе Золотое Приложение

Призовое место “Real Cosmetology” в конкурсе Золотое Приложение

Призовое место “Real Cosmetology” в конкурсе Золотое Приложение

Призовое место “Real Cosmetology” в конкурсе Золотое Приложение

Призовое место “Real Cosmetology” в конкурсе Золотое Приложение

Призовое место “Real Cosmetology” в конкурсе Золотое Приложение

Золото в конкурсе Workspace Digital Awards 2023

Золото в конкурсе Workspace Digital Awards 2023

Золото в конкурсе Workspace Digital Awards 2023

Золото в конкурсе Workspace Digital Awards 2023

Золото в конкурсе Workspace Digital Awards 2023

Золото в конкурсе Workspace Digital Awards 2023

Хронофаги и как их усмирить

Хронофаги и как их усмирить

Хронофаги и как их усмирить

Хронофаги и как их усмирить

Хронофаги и как их усмирить

Хронофаги и как их усмирить

Шаг за шагом: настройка окружения для Kotlin Multiplatform Mobile

Шаг за шагом: настройка окружения для Kotlin Multiplatform Mobile

Шаг за шагом: настройка окружения для Kotlin Multiplatform Mobile

Шаг за шагом: настройка окружения для Kotlin Multiplatform Mobile

Шаг за шагом: настройка окружения для Kotlin Multiplatform Mobile

Шаг за шагом: настройка окружения для Kotlin Multiplatform Mobile

Cофт скилы: как получать больше за красивые глаза

Cофт скилы: как получать больше за красивые глаза

Cофт скилы: как получать больше за красивые глаза

Cофт скилы: как получать больше за красивые глаза

Cофт скилы: как получать больше за красивые глаза

Cофт скилы: как получать больше за красивые глаза

Площадки для видеостриминга: обзор-сравнение

Площадки для видеостриминга: обзор-сравнение

Площадки для видеостриминга: обзор-сравнение

Площадки для видеостриминга: обзор-сравнение

Площадки для видеостриминга: обзор-сравнение

Площадки для видеостриминга: обзор-сравнение