Совместная работа в Renga 3.3

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

Уже в ближайшее время вы сможете работать всем отделом над одним проектом в Renga, не разговаривая со своими коллегами (шутка, мы категорически рекомендуем общаться).

Если коротко, то для совместной работы вам понадобится Renga Server и всего две кнопки в вашей Renga: Синхронизировать и Опубликовать. В общем-то можно отделаться парой слов. Но мы знаем наперед, что эти две команды (а вернее, отсутствие каких-либо других команд) могут стать яблоком раздора, и чтобы не возникло недопонимания, хотим рассказать вам о нашем замысле подробно.

Начнем наш разговор с теории.

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

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

Надеемся, что возражений нет, продолжаем.

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

Одновременно? На этом придется остановиться поподробнее. Когда люди работают параллельно над одной задачей, самая неприятная ситуация, которая может возникнуть, это конфликт, то есть ситуация, когда разные пользователи изменяют одни и те же данные одновременно и по-разному. Поэтому ключевой вопрос, над которым бьются разработчики ПО, как обрабатывать конфликты.

Попытки ответа на данный вопрос привели к возникновению трех основных стратегий организации совместной работы:

1. Оптимистичный контроль параллелизма (Optimistic concurrency control). Предполагается, что изменения, полученные от разных пользователей при работе приложения, могут применяться, не мешая друг другу. Во время работы данные не блокируются. Перед записью данных каждая транзакция проверяет, что никакая другая транзакция не изменила прочитанные данные. Если проверка выявляет конфликтующие изменения, транзакция отменяется и может быть перезапущена.
2. Пессимистичный контроль параллелизма (Pessimistic concurrency control). Предполагается, что два или более пользователя обновляют одни и те же данные одновременно, что приводит к конфликту. Чтобы его предотвратить, приложение блокирует обновляемые данные, и пока блокировка не будет снята, то есть пока первый пользователь не закончит редактирование данных, доступ к ним будет ограничен для других пользователей.
3. «Выигрывает последний» (Last writer wins). В этой стратегии данные просто перезаписываются последним.

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

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

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

Посмотрим, что происходит в этом случае. Кто-то открывает проект, блокируется часть, с которой он работает. Тут есть свои плюсы и минусы.

Плюсы:

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

Минусы:

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

Принимая во внимание минусы, продолжаем поиск.

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

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

Но в нашей работе есть одно серьезное «но»:

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

Вероятность возникновения конфликта можно уменьшить двумя способами:

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

Конфликты при таком подходе к проектированию здания случаются редко, поэтому мы остановились на стратегии Оптимистичного контроля параллелизма, и пользователи Renga получат следующие преимущества:

• Одновременно внесение изменений.
• Работа без блокировки.
• Автономная работа.
• Передача минимального набора данных для синхронизации с сервером.

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

Не переборщили с теорией? Переходим к практике.

• Итак, до начала работы на каком-то компьютере в локальной сети, назовем его сервер, нужно запустить Renga Server.

• Кто-то из команды создает проект, в котором добавляет необходимую информацию и, возможно, создает модель здания. Когда он готов поделиться своей работой и продолжить работу над проектом в команде, он нажимает кнопку Опубликовать, а затем отправляет своим коллегам файл проекта любым удобным способом.

• Коллеги сохраняют файл проекта на своих компьютерах там, где им удобно, могут даже переименовать его.

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

В общем, как только выйдет версия 3.3, скачивайте, устанавливайте и пробуйте работать вместе на реальных проектах. А если после прочтения появились вопросы, задавайте их прямо сейчас!

Иллюстрации @sonya8berg