Заказная разработка ПО в IBS: организация процессов разработки и тестирования

В третьей статье цикла рассказывалось о подходах IBS к UX/UI-дизайну. В продолжении речь пойдет об особенностях организации разработки и тестирования. Из-за разнообразия применяемых технологий процесс разработки, как правило, строится вокруг кросс-функциональных команд с участием аналитиков, backend- и frontend-разработчиков, QA- и DevOps/DevSecOps-инженеров. С увеличением числа участников проекта возрастает коммуникационная энтропия, так что результативность разработки теперь напрямую зависит от организации процессов. Об опыте IBS в этом направлении рассказывают начальник отдела разработки backend Кирилл Кодин, начальник отдела разработки frontend Андрей Андеев и директор отделения тестирования Константин Синанов.

Планирование реализации

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

После оценки задача берется в спринт, который может длиться 1–3 недели. Набор задач в спринте формируется с учетом статистической скорости команды и приоритетов заказчика.

Используемые технологии

Для разработки серверной части применяются Java, .NET, Python. Эти языки отличаются высокой производительностью, стабильностью и богатой экосистемой для сложных вычислений и интеграций. Кодовая база формируется в соответствии с индустриальными стандартами и лучшими внутренними практиками, чтобы гарантировать чистоту, надежность и поддерживаемость программного кода будущего решения. Соблюдаются единые правила Google Java Style Guide, Microsoft Coding Conventions, а также архитектурные принципы SOLID, DRY и KISS. В Java реализуется четкое разделение на слои Controller, Service и Repository при работе со Spring, а в .NET – Clean Architecture с элементами Domain-Driven Design и разделением на Core, Application и Infrastructure.

При создании пользовательских интерфейсов используются React, TypeScript, Redux, Material-UI, а также дизайн-система собственной разработки NemoUI. TypeScript помогает минимизировать ошибки типов, Redux дает возможность управлять состоянием приложения, а благодаря готовым компонентам NemoUI ускоряется разработка интерфейсов.

Для организации кода применяется методология Feature-Sliced Design (FSD), упрощающая поддержку крупных проектов за счет логической группировки кода по фичам, сущностям и виджетам. Интеграция с backend-слоем реализуется через REST и GraphQL. Для оптимизации производительности конечного приложения применяется сборка через Webpack или Vite.

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

Технологии искусственного интеллекта в разработке

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

Наиболее полезен ИИ-помощник в следующих задачах:

1) Формирование системных постановок в соответствии с заданным шаблоном. Основные функции – настройка параметров генерации документов (выбор типа документа, наименования и проекта), подготовка данных для генерации (создание и загрузка файла с бизнес-требованиями), генерация и просмотр готового документа, создание диаграмм.

2) Ускорение написания кода. ИИ-ассистент интегрирован в IDE с помощью плагина CodeGPT. Способен создавать шаблонный код (DTO, CRUD-методы, API-эндпоинты), предлагать оптимизации и рефакторинг «на лету», а также дополнять код, основываясь на контексте проекта.

3) Обучение и онбординг новых сотрудников. ИИ выступает в роли виртуального ментора, помогая новичкам быстро разбираться в коде проекта. Отвечает на вопросы по внутренним стандартам и процессам без необходимости отвлекать коллег.

4) Генерация тестов и документации к коду (unit-тестов, Swagger-описаний на основе кода, технической документации в Markdown).

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

Автоматизированный контроль качества

Перед отправкой в репозиторий программный код проходит многоуровневую проверку. Выявлять стилистические ошибки помогают линтеры (StyleCop, ESLint). Инструмент контроля качества кода SonarQube, интегрированный в CI/CD, обеспечивает проверку всех поступающих изменений на нарушения в Checkstyle/StyleCop и уровень покрытие unit-тестами. Кроме того, он позволяет выявить уязвимости в коде и сразу на них отреагировать. Настроенная аналитическая панель помогает отслеживать статус по каждому из проектов.

В контроле качества кода важен комплексный подход. На первом этапе каждый класс и метод проверяются изолированно с помощью unit-тестов, при этом для замены внешних зависимостей используются моки (Mockito/Moq). Основные фреймворки – JUnit и Nunit. Минимально допустимый уровень покрытия – 70%, что контролируется через SonarQube. Чтобы выявить проблемы взаимодействия между компонентами, выполняется интеграционное тестирование с использованием Testcontainers для работы с БД и WireMock для мокирования внешних API.

Перед созданием пул-реквеста код дополнительно проверяется автоматизированными инструментами: ESLint для frontend-части, Husky – для pre-commit хуков.

Процессы сборки и развертывания ПО происходят автоматически. Docker контейнеризует приложение, Jenkins или GitLab CI отвечают за непрерывную интеграцию. Каждая успешная сборка разворачивается на тестовых стендах и проходит через функциональное и нагрузочное тестирование.

Проведение тестирования

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

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

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

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

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

Для автоматизации процессов применяются проверенные инструменты – как проприетарные, так и с открытым исходным кодом. Инструменты управления тестированием выбираются исходя из задач на проекте и возможностей бюджета. В данный момент наиболее популярными являются Тест IT, TestRail, Zephyr, ТестОпс, eqator. Они охватывают управление тестированием, разработку тестовой модели, отслеживание дефектов, анализ покрытия требований и нефункциональные проверки.

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

Подготовка релиза

На завершающем этапе формируется релиз, включающий только задачи, которые прошли все этапы тестирования и код-ревью и составляют полезную для пользователя функциональность. Тимлид совместно с DevOps-инженером выполняет финальные технические процедуры: создает теги в Git, формирует Docker-образы и готовит Release Notes с описанием внесенных изменений. После развертывания релиза стабильность работы отслеживается с помощью инструментов мониторинга Prometheus и Grafana.

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

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

Реклама. ООО «ИБС Софт». ИНН7713721689