Как мы полностью обновили VK Мессенджер: переписать нельзя рефакторить

Случается, ты просыпаешься и осознаешь: так больше продолжаться не может и нужно что‑то менять. Разные кодовые базы, избыточное легаси и нестабильность мешают пользователям получать удовольствие от общения в твоем приложении. И эта мысль подводит тебя к развилке: один путь ведет к сложному и долгому рефакторингу легаси за почти 10 лет, второй к не менее долгому, а, порой, более сложному процессу переписывания с 0. Но какой бы путь ты ни выбрал, в любом случае начинаешь испытывать азарт — предстоит большая Задача (именно с большой буквы).

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

Что такое VK Мессенджер

VK Мессенджер по своей сути — сервис внутри еще большего сервиса. Он тесно связан со множеством других разделов ВКонтакте: Музыка, Фотографии, Видео, Лента — да практически со всеми. Для наглядности визуализируем. 

При этом веб-мессенджер как платформа состоит из 4 продуктов: 

• веб-версия vk.com;

• fast-чаты (всплывающие чаты);

• мобильная версия m.vk.com;

• десктопный мессенджер ВКонтакте. 

Мало того, что все эти части имели раньше разные кодовые базы (даже мессенджер внутри vk.com), так и у них был разный приоритет. Самый высокий был у vk.com с его мобильными клиентами. Далее шел m.vk.com, для которого что‑то могли уже не делать ради экономии времени и трудозатрат. На третьем месте по важности была десктопная версия. Этот проект моей команде достался уже готовым. Его когда‑то написал на Electron один разработчик, который потом ушёл из компании. У команды не было знания кодобазы, а спросить было не у кого, поэтому что даже CI пришлось настраивать самим с 0 за пару месяцев. А fast‑чаты мы поддерживали по остаточному принципу.

С чем мы подошли к развилке

Как уже сказал, изначально VK Мессенджер состоял из 4 независимых кодовых баз. Все они были написаны давно, и с тех пор в них внесли много изменений. Технологии развивались, что‑то стали делать проще, что‑то — иначе. Например, во многих языках начали активно использовать типизацию. Если же код легаси, то не всегда можно найти автора и расспросить о его устройстве. Поэтому каждый раз опасаешься вносить изменения, потому что неизвестно, как это аукнется.

В те времена после каждого релиза мы всей командой с замиранием сердца следили за графиками. И при любой проблеме приходилось долго искать причину: «Что и где отвалится, если я удалю этот кусок кода и заменю на другой?». С учетом размеров и устройства кодовых баз даже инструменты в IDE не особо помогали справиться с задачей. Часто приходилось пользоваться обычным поиском (всякими креативными способами), чтобы понять заденешь что‑то или нет.

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

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

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

Фича очень простая и не требует глубоких знаний в предметной области. Однако у меня ушло около месяца работы, потому что каждый раз я фактически начинал «с нуля», понимание того, как фича работает в vk.com, никак не помогало реализовать ее в m.vk.com и т. д. Чтобы погрузиться во всё, требовалось много времени. Я сам более‑менее уверенно стал ориентироваться в коде только через полгода.

Как мы выбирали, по какому пути пойдем

Нужно было что‑то менять. Но мнения команды разделились: либо серьёзно рефакторить код, либо всё переписывать с нуля. Много обсуждали и спорили, что‑то по‑мелочи меняли, но долгое время ситуация в целом оставалась прежней. В тот момент проблема была в том, что оба пути были страшными и полными неопределенности. И нельзя было ничего быстро апробировать. Именно поэтому наши дискуссии оставались умозрительными.

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

Для себя я выделял несколько аргументов в пользу переписывания с 0. Возможно, какой‑то из них я рационализировал, когда писал этот текст ):

• Рефакторинг никак не решал проблему гетерогенности кодовых баз. А «выдрать» одну и переиспользовать в других местах было невозможно.

• К команде могут присоединиться новые инженеры. Погружать их одновременно в старые и новые части рефакторинга и нюансы их сочетания будет невероятно сложно и дорого. В нашем же случае мы просто подключали новичков только в новую кодобазу.

• Мы (как и многие другие команды в мире) видели будущее в типизации и очень хотели использовать TypeScript. Кроме того у меня был крайне позитивный опыт использования типов для моделирования предметной области, что помогает избавляться от невозможных состояний в системе. Это распространенная практика в сообществах других ЯП, которыми я интересуюсь (Haskell, Elm, Rust). Для того, чтобы получить максимум от TypeScript, нам нужно было бы включить максимально жесткие ограничения настройки, но из‑за существующего кода это было просто невозможно. Сначала я даже пытался как‑то изменить ситуацию — ходил по всей монорепе vk.com и правил код разных команд. Но таким образом мне удалось «ужесточить» конфиг TypeScript лишь на одну настройку, а потом я просто сдался.

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

А еще в случае с переписыванием у нас все же был понятный путь того как получать выгоду от него сразу, а не через годы. Во‑первых мы достаточно быстро могли заменить и оживить fast‑чаты, которые отображаются на каждой странице и помогают вовлечь в мессенджер больше пользователей. Во‑вторых, одной из важных целей новой кодовой базы с архитектурной точки зрения была «встраиваемость». Поэтому достаточно быстро появилась идея встраивать отдельные значимые кусочки в старый код, которые бы работали на новом состоянии и UI.

Но спорили мы не только о том, рефакторить или переписывать, но и о том, как организовывать код, как описывать модели, бизнес‑логику и все остальное. Однажды споры надоели мне настолько, что я решил в свое свободное время попробовать написать новый прототип десктопного мессенджера. Подумал, что обосновывать плюсы своих идей будет куда проще на примерах реального работающего кода. Потратил на это примерно три недели один, а потом подключил еще одного старейшего члена команды (привет Тиму Чаптыкову!), который помог отполировать его еще пару недель. Прототип умел делать не более 10% того, что было реализовано в текущих клиентах, в то же время не во всех из них поддерживались некоторые фичи из прототипа. Кроме того там были примеры реализации ключевых частей мессенджера — работы со списками чатов и получение и обработки событий с сервера. Потом этот прототип мы показали сначала всей команде веб‑мессенджера, а потом на очередном демо и всем остальным командам мессенджера. Фидбек оказался очень позитивным, к тому же прототип был хорошим пруфом нашему руководству, что мы сможем и начать, и закончить. А чтобы не брать паузу на несколько лет, договорились переписывать по частям. Это заняло немало времени — сказывалась разнородность кодовых баз и используемых в них технологий.

Какие шаги мы предприняли 

Итак, мы определились с тем, по какому пути пойти, но впереди оставалось еще много проблем. Например огромное, количество точек интеграции — несколько десятков.

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

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

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

Хотя мы пошли по пути переписывания с нуля, но часть компонентов мы решили брать или существующие в мессенджере, или у коллег.Например, после интеграции fast‑чатов само поле ввода текста мы позаимствовали из vk.com. Правда в итоге свой мы всё равно написали, потому что нужна была интеграция с виджетами и десктопной версией.

В vk.com есть эффективный механизм определения мастер‑вкладок на основе алгоритма нахождения консенсуса. Благодаря ему мы снижаем количество обращение фронтенда к серверам. Допустим, у вас открыто десять вкладок ВКонтакте, которые могут обращаться к сети за обновлениями от сервера, и чтобы не перегружать бэкенд, лишь одна из открытых вкладок стучится в сеть, получает данные на всех, а потом «раздаёт» остальным вкладкам.

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

Сложностей и ошибок добавляло и то, что VK Мессенджер — очень оживлённая и интерактивная часть ВКонтакте. Здесь всё время что‑то обновляется, одни действия инициируют новые. Поэтому, чтобы повысить общую производительность, мы много времени потратили на оптимизацию.

Чего мы добились 

Благодаря переезду в отдельный репозиторий VK Мессенджер теперь — своего рода пакет SDK, который мы устанавливаем и используем в разных частях ВКонтакте с небольшими доработками. Берём фрагмент кода с новыми фичами и с небольшими адаптациями добавляем во все 4 версии. Встраиваемость была одним из ключевых требований к новой кодобазе и нам удалось здорово с этим справиться благодаря тщательно спроектированным интерфейсам DI. А пятым проектом, который был сделан на основе нового SDK стал виджет мессенджера, который сейчас можно найти, например, в почте Mail.ru. Мы планируем заменить им старый виджет сообщений сообществ, который ранее могли себе встраивать сторонние сайты.

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

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

Раньше мессенджер умел рендериться дважды — в kPHP для server‑side rendering и на клиенте для интерактивных частей. Где‑то мы умели шарить «шаблоны» между kPHP и JavaScript, а где‑то нам приходилось дублировать логику разметки. В новой кодовой базе мы с одной стороны не могли позволить себе server‑side rendering (для этого надо было использовать Node.js, а инфраструктурно этого не хотелось), а с другой хотели ускорить холодный старт вкладки мессенджера. Поэтому мы сделали промежуточный вариант — «транслируем» наши запросы начальных данных в PHP и переиспользуем при загрузке страницы для создания кэша. Благодаря возможности стримить ответ с сервера, которую недавно внедрил KPHP, мы можем параллельно готовить данные и отдавать HTML и статику.

Ещё мы на основании схемы API бэкенда стали генерировать типизацию к этому API. Это помогает избегать ошибок вроде неправильной передачи аргумента. Сейчас типы для API используют все команды на вебе, но когда‑то именно мессенджер был early‑адоптером, приносил фидбек и идеи в реализацию. В этом нам помогает и очень развитая инфраструктура ВКонтакте: мы используем систему тестирования, подгружаем данные напрямую с бэкенда, чтобы у пользователей быстрее открывались страницы.

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

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

История одного факапа

Чтобы никто не думал, что всё всегда было идеально, расскажу историю небольшого факапа. Собственного факапа.

Вместе с запросом на отправку нового сообщения мы подкладываем уникальное число, назовем его ID сообщения. Это нужно, чтобы потом сопоставлять оптимистичное состояние с результатом работы сервера. Так вот, я решил, что неплохим способом формировать такое число будет текущая дата. При этом укладываться наш уникальный ID должен в int32, а значит текущую дату нужно ужать до этих размеров. Абсолютно логичным будет взять ее остаток от деления на желаемый диапазон и дело с концом. Не буду вдаваться в детали, но я почему‑то решил перемудрить с математикой и брать по модулю определенного временного промежутка, который оказался больше половинки int32 (мы берем только отрицательный диапазон).

В результате в какой‑то момент отправка сообщений в fast‑чатах просто перестала работать из‑за переполнения int32. А это обновление уже было в «проде», хоть и на небольшую часть аудитории. К счастью, это было в момент минимальной нагрузки, и мы быстро исправили проблему.

О команде

Команда мессенджера ВКонтакте — лучшая, в которой я когда‑либо работал. Как по профессионализму, так и по отношению к делу. Когда команда была маленькая, у нас даже не было никаких планирований, никто никому не назначал задачи: просто у всех была огромная инициативность. Закончив какую‑нибудь задачу, каждый самостоятельно сразу брал себе новую: сделать фичу, исправить ошибки и т. д. И не просто старались закрыть тикет, а искренне думали — и думают! — о том, как сделать лучше для пользователя. Наверное, такие встречаются везде, но у нас — каждый. И когда тебя окружают такие товарищи, это дополнительно мотивирует, придаёт энергии. Для меня это невероятный опыт.