Совместная работа: от теории к практике

Дорогие читатели! Просим вас простить нас за долгое отсутствие. Надеемся, что вы следили за Renga в других источниках и знаете, что здесь долго не было заметок не потому, что нам было не о чем сказать.

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

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

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

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

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

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

Второй тип - это заключение сделки. Он предполагает обмен чем-то, проводится по определённым правилам, а в результате заключения сделки меняются отношения между ее участниками. То есть один человек становится, например, продавцом, а другой покупателем. Программное обеспечение, которое предназначено для такого вида взаимодействия должно надежно хранить новые статусы участников. К такому программному обеспечению относят системы управления транзакциями, например, 1С:Предприятие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Минусы:

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

Данный вариант распространен в AEC-системах. Принимая во внимание минусы, продолжаем поиск.

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

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

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

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

Если вернуться к выбору стратегии организации совместной работы в Renga, преимущества несомненно подкупают, а с недостатком придется побороться.

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

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

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

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

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

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

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

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

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

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

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

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

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

Смотрите также:

Организация совместной работы

Важное о совместной работе в Renga

Как грант помог усовершенствовать Renga