Читать книгу - "Антихрупкость в IT - Александр Васильевич Бындю"

поэтому потребуется переобучение людей.

3. Знания об истории развития унаследованной системы могут быть потеряны, поэтому вы рискуете забыть реализовать функциональность, которая была в старой системе.

4. Обычно работа по исправлению идёт под давлением сроков и большого количества технических долгов, что грозит потерей мотивации в команде.

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

6. Если заказчик или инвестор, взвесив все риски, решается взяться за работу, то вам следует понять важную вещь: для него не будет разделения на «новую систему» и «старую систему». Система всегда едина. Возникли неожиданные проблемы в неожиданном месте? Теперь это ваша проблема. Вы в этом не виноваты? Код был хрупким и поэтому всё сломалось? Для заказчика теперь вы ответственный за весь код, вам и решать все проблемы. Приготовьтесь к тому, что будете самостоятельно искать, отлаживать, профилировать унаследованную систему значительное время.

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

Анализ унаследованной системы

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

Где находится исходный код?

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

Если системы контроля версий нет, то её обязательно нужно завести в самом начале, ещё до первых изменений в коде. Это поможет вам:

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

2. Собрать все исходники системы и всех подсистем в одном месте.

Где развёрнута система?

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

Если вам досталась актуальная документация инфраструктуры, то это большая удача. В любом случае стоит ввести DevOps’а в курс дела и дать ему задачу актуализировать документацию.

Какая версия сейчас работает?

Если системой уже начали пользоваться, то нужно понять, какая версия в данный момент залита на боевых серверах. Это критически важно при изучении работы системы, анализе её поведения, отладке и профилировании.

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

Как выпустить новую версию?

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

Нередко в проектах нет CI/CD. В этом случае нужно запланировать с заказчиком системы время и настроить CI/CD. В выпуск версии вам стоит включить как минимум:

1. Сборку последних версий всех проектов в системе

2. Проставление номера текущей версии.

3. Модификацию файлов конфигурации под окружение.

4. Запуск автоматических тестов.

5. Выпуск артефактов для заливки.

6. Заливку новой версии на боевые сервера.

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

Интегрирована ли система с другими системами?

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

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

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

Логирование работы

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

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

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

1. Откроет глаза заказчику на реальную ситуацию на проекте.

2. Придаст вам дополнительную мотивацию поскорее всё исправить.

Настроены ли мониторинг и аналитика?

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

Модульные и интеграционные тесты

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

«Зелёные» тесты будут вашими лучшими друзьями, поскольку они являются самой актуальной документацией к системе. Существующие тесты надо обязательно включить в CI/CD, если этого ещё не было сделано.

Если тестов нет, то вам захочется покрыть код тестами. Здесь вы можете столкнуться с несколькими проблемами:

1. Заказчик не выделяет время на покрытие кода автоматическими тестами. Тогда QA-инженеры обязательно должны сделать полное ручное тестирование системы и перед каждым релизом перепроверять регресс, что может занять значительное время.