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

Задний план:

Каталог приложений Hootsuite был создан с использованием MongoDB и тесно связан с устаревшей кодовой базой Hootsuite (также известной как Монолит). Чтобы отделиться от монолита, команда создала службу каталогов приложений (ADS), микросервис Scala, использующий базу данных MySQL. MySQL был выбран вместо Mongo из-за его строго типизированных полей и реляционной структуры. Функции ограничения типов в Mongo намного проще, и мы столкнулись с ошибками, вызванными неправильным сохранением данных (подробнее о MySQL vs Mongo). Более того, база данных MySQL может также поддерживать приложения организации (приложения, которые могут быть запущены в конкретной организации и доступны только членам этой организации). Целью миграции было уменьшить зависимость от устаревшей кодовой базы Hootsuite за счет перехода на микросервис, принадлежащий команде, а также объединить приложения и приложения организации. Это также часть долгосрочного проекта по объединению нескольких представлений одних и тех же концепций интеграции в одно связное решение. Миграция данных каталога приложений позволяет нам объединить существующие социальные сети в единую схему, что значительно снижает сложность архитектуры Hootsuite. Проект включал рефакторинг кода монолита для чтения и записи из микросервиса. Процесс был разбит на три основных этапа:

  1. Выполните рефакторинг монолита для чтения и записи как из Mongo, так и из MySQL. MongoDB по-прежнему оставалась основной базой данных, то есть пользователи получали данные из Mongo, а не из MySQL.
  2. Выполните рефакторинг монолита, чтобы сначала читать и писать из MySQL, сделав MySQL первичной базой данных, а Mongo - вторичной базой данных.
  3. Выполните рефакторинг монолита для чтения и записи только в MySQL, тем самым устраняя необходимость в Mongo.

Проблемы:

План развивался, когда мы исследовали кодовую базу и поняли, что недооценили сложность проекта. На нашем пути было несколько развилок, которые заставили нас принять решение о том, как нам двигаться дальше. В каждом случае мы задокументировали возможные подходы и обсудили, какой из них лучше всего. Один из таких случаев произошел, когда мы решили удалить нашу зависимость от службы генерации идентификаторов под названием Snowflake. Мы использовали эту службу для автоматической генерации идентификаторов в MongoDB - функции, которой у Mongo нет. MySQL, с другой стороны, может автоматически увеличивать идентификаторы первичных ключей при вставке, поэтому мы решили, что Snowflake больше не нужен.

Преодоление этих проблем:

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