Как встроить совместную работу в реальном времени в приложение, созданное с помощью ИИ (не ломая чужую работу)

Что происходит, когда два человека редактируют одно приложение одновременно?

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

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

Задача 1: Купить продукты
Задача 2: Позвонить маме
Задача 3: Назначить встречу

Коллега А отметил «Купить продукты» как выполненную. Коллега Б добавил «Починить роутер». Оба нажали «Сохранить».

Когда коллега А обновил страницу, он увидел:

Задача 1: Купить продукты (выполнено)
Задача 2: Позвонить маме
Задача 3: Назначить встречу

«Починить роутер» исчезла. Работа коллеги Б пропала.

Это коллизия: одновременные записи, изменения одного человека потеряны. Звучит как отдельная функция, но на деле это исправление потери данных. Без него ваше приложение ломается в тот момент, когда его касаются два человека одновременно.

Какие ошибки совместной работы в реальном времени встречаются чаще всего?

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

Сбой 1: потерянная запись (незаметная потеря данных)

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

Реальная история: организатор свадеб и её ассистент работают над списком гостей. Ассистент добавляет три подтверждения, пока организатор помечает два как «окончательные». Пометки организатора исчезают. Никто этого не замечает, пока при повторных звонках она не начинает дважды приглашать людей, которые уже согласились прийти.

Большинство реальных приложений решают это, сохраняя каждое нажатие клавиши, а не только по клику на «Сохранить». Так делают Google Sheets, Notion, Figma. Вашему приложению нужно такое же поведение.

Сбой 2: устаревшее обновление (отображение старых данных)

Человек А редактирует задачу. У человека Б открыта та же страница — он видит старую версию. Он вносит изменение, основываясь на устаревших данных. Теперь есть конфликт, который для него незаметен.

Реальная история: страховой оценщик и подрядчик работают над одним делом. Оценщик меняет «предварительную стоимость ремонта: $3000» на «$5000» на основе новых фотографий. У подрядчика страница всё ещё показывает $3000. Он отправляет форму согласования на $3000. Позже обнаруживается конфликт.

Без обновлений в реальном времени оба человека думают, что работают с одной и той же версией. Это не так.

Сбой 3: каскадное противоречие (две правды)

Пользователь удаляет запись. Другой пользователь в этот момент смотрит на детали этой записи. Один видит «удалено», другой — по-прежнему полную запись. Теперь они действуют, исходя из разных фактов.

Реальная история: координатор волонтёров помечает смену как «отменена». Волонтёр ещё не обновил страницу и по-прежнему видит её как «открыта». Он начинает набирать на неё людей. Через несколько часов на несуществующую смену приходят двое.

Как исправить ошибки совместной работы в реальном времени?

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

Исправление 1: обнаружение конфликтов записи (инкрементальные сохранения)

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

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

Изменение человека А применяется первым.
Изменение человека Б применяется вторым.
Побеждает человек Б (принцип «побеждает последняя запись»).

Это жёстко, но честно: как минимум один человек увидит, что его изменение не сохранилось, и сможет повторить его.

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

Исправление 2: обновление без потери локальных правок

Если вы опрашиваете базу данных каждые 5 секунд (или передаёте обновления через WebSocket), объединяйте новые данные, не затирая текущие правки пользователя.

Неправильный способ: перезагрузить всю страницу. Все локальные правки теряются.

Правильный способ: обновлять только те поля, которые пользователь сейчас активно не редактирует. Если он печатает в заголовке — не трогайте его. Если он не касается срока выполнения — обновите его данными с сервера.

Задача для разработчика: при получении свежих данных из базы объединяйте их: сохраняйте локальные правки, обновляйте всё остальное. В реальном фреймворке это обычно две строки кода. Проверьте: отредактируйте одно поле в одном окне и другое поле — в другом окне одновременно. Оба изменения должны сохраниться.

Исправление 3: чётко показывайте правду

Когда возникает конфликт или устаревшие данные — покажите это. Не скрывайте.

Примеры:

«Эта задача была удалена кем-то другим. Отменить?»
«Пока вы печатали, кто-то добавил в этот список три пункта. [Посмотреть, что нового]»
«Вы смотрите на версию двухминутной давности. Обновите, чтобы увидеть актуальную.»

Задача для разработчика: при загрузке проверяйте, есть ли у отображаемых данных временная метка. Если ей больше 30 секунд и пользователь пытается редактировать — покажите предупреждение и запросите данные заново. Если вы показываете список, добавьте кнопку «Обновить», которая воспринимается как осознанное действие пользователя, а не как признак сбоя.

Как выглядит совместная работа в реальном времени, когда задача решена полностью?

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

Каждое нажатие клавиши сохраняется немедленно — без ожидания кнопки.
Конфликты разрешаются по правилу — если мы оба редактируем одно и то же слово, система выбирает победителя (обычно побеждает последняя запись, либо вам показывают запрос на разрешение конфликта).
Обновления приходят мгновенно — через WebSocket, Server-Sent Events или базу данных, которая сама рассылает изменения (например, Firebase).

Большинству приложений это не нужно с первого дня. Начните с инкрементальных сохранений (Исправление 1). Добавьте опрос с объединением (Исправление 2), когда приложением одновременно начнут пользоваться два человека. Добавляйте мгновенную рассылку обновлений только если конфликты действительно причиняют боль.

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

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

Тест 1: одновременное сохранение

Откройте приложение в двух окнах браузера.
В окне 1 отредактируйте поле X и сохраните.
В окне 2 сразу после этого отредактируйте поле Y и сохраните.
Обновите оба окна.
Пройден: оба изменения на месте. Провален: одно из изменений исчезло.

Тест 2: устаревшие данные

Откройте приложение в окне 1. Не трогайте его.
В окне 2 внесите значительное изменение (добавьте/удалите строку, измените заголовок).
Вернитесь в окно 1 (там всё ещё старые данные).
Попробуйте отредактировать устаревшую версию в окне 1.
Пройден: вы получаете предупреждение, либо изменения объединяются корректно. Провален: вы перезаписываете изменение из окна 2.

Тест 3: обновление страницы

Начните значимую работу (наполовину заполненную форму, черновик сообщения).
Обновите страницу.
Пройден: ваша работа всё ещё на месте. Провален: она исчезла.

Сохранять при каждом нажатии клавиши или ждать кнопку «Сохранить»?

Сохраняйте при каждом нажатии клавиши. Одно это решение проведёт вас 80% пути к совместной работе в реальном времени — всё остальное сводится к тому, чтобы сделать это видимым и научиться обрабатывать коллизии.

Сегодня пользователи ожидают именно этого. Gmail, Google Docs, Slack — так устроено любое современное приложение. Ваше должно работать так же.

Первое, что нужно сделать: заставьте каждое изменение сохраняться автоматически. Покажите небольшой индикатор («сохранение…», который затем исчезает). Понаблюдайте, что происходит, когда два человека редактируют одновременно. Если чьё-то изменение пропадает — это ваше следующее исправление. Решать проблемы по одной эффективнее, чем пытаться построить идеальную совместную работу с первого дня.