По результатам опроса в сообществе и под статьей на Хабре образовалась интересная статистика, которая превзошла мои ожидания.
В обоих случаях целые 44% опрошенных, представившихся системными аналитиками (почти половина) проголосовали за вариант «мне приходилось погружаться в код своих коллег и читать его».
А если учесть, что и в сообществе и на Хабре треть опрошенных (35% и 40% соответственно) проголосовала за вариант «посмотреть результаты», то получим около 70% аналитиков, сталкивавшихся с такой необходимостью и это колоссальные цифры! 🤯
О чем же они говорят?
☹️1. Плохая документация
На это могло повлиять множество факторов. Как основные: или отсутствие аналитиков, или сложный запутанный домен, или команда работала в режиме «стартап», когда главное было пилить как можно быстрее новый функционал для бизнеса. Или все вместе взятое .
☹️2. Плохие процессы
Возможно, что в команде не были должным образом выстроены процессы проектирования, разработки и тестирования:
отсутствовали соглашения по проектированию и описанию требований
отсутствовала культура тестирования (напомню, что хорошо описанные требования на разработку являются основой для формирования тест-кейсов, и хорошие QA будут требовать документацию от аналитиков).
Что делать?
Отсутствие документации — это большая возможность для прокачки скиллов: как хардов, так и софтов.
В целом в таких ситуациях я использую следующий порядок действий:
Получить доступ к стенду тестирования и посмотреть, какой функционал уже имеется в системе.
Определить круг стейкхолдеров и подготовить вопросы для их интервьюирования.
Изучить таск‑трекер (условная Jira) на предмет следов разработки (можно узнать о том какие сервисы и фичи были сделаны ранее)
Поговорить со всеми разработчиками и узнать, какие сервисы они разрабатывают/разрабатывали на проекте и вообще что они о нем знают.
Изучить систему контроля версий (например GitLab или BitBucket) — позволит найти сервисы и их код.
Изучить конфигурации сервисов. В них, как правило, будут URL-адреса интеграционных и иных взаимодействий (БД, брокеры итд).
Изучить API, если есть описание. Если нет, то придется погружаться в чтение кода.
На этом этапе очень полезным станет отрисовка схемы микросервисов и определение структуры моделей данных в БД.
На схему микросервисов будет необходимо нанести сервисы, стрелочками изобразить взаимодействие между ними, и желательно написать имя используемого метода и его URL.
БД можно описывать в табличном виде или в виде ER-диаграмм.
Во время чтения кода вы можете использовать информацию из предыдущих пунктов, чтобы восстановить и задокументировать бизнес-процессы так, как они реализованы на самом деле.