Version Control and “the 80%”

Ссылки сюда (1) →

Перевод статьи Version Control and “the 80%” (Контроль версий и «правило 80 процентов») выполнен сообществом компании «Заказные ИнформСистемы».

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

Два типа программистов

Итак, есть два «класса» программистов-разработчиков, назовем их «20%» и «80%».

20% парней это те, кого можно назвать «альфа» программистами — лидеры, новаторы, законодатели новых течений, парни, за которыми гоняются компании типа Google или Fog Creek software.

Эти парни — те самые пионеры домашних инсталляций Linux в 90-х, те, кто пишут компиляторы Лиспа и «по-приколу» учат Haskell за выходные, активные участники open-source проектов, всегда в курсе последних, крутейших тенденций и инструментариев в разработке ПО.

Но основная движущая сила индустрии программного обеспечения — это «80%»-ные парни. Нет, они не глупые, они вполне себе профессионалы-кодеры.

В школе/колледже/институте/ПТУ они более-менее терпимо освоили Java/C#/C++, получили работу по внутренней автоматизации банков, государственных служб, торговых и промышленных компаний и т.д.

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

Они безропотно используют любые инструменты, спускаемые им Microsoft — обычно это VS.NET, если они работают с С++, ну, или может быть, GUI IDE типа Eclipse или IntelliJ для Java-разработки.

Они никогда не использовали Линукс и никак им не интересовались. Многие даже никогда не использовали хоть какую-нибудь систему контроля версий, а если и использовали, то это были только инструменты, поставляемые Microsoft (типа SourceSafe), или какой-нибудь унаследованный антикварный хлам.

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

Жуткая правда №1

Основной объем производимого в мировом производстве ПО — создается вышеупомянутыми «80%» программистов.

Да, индустрия в основном состоит из небольших контор для разработки под Windows или малых компаний, нанимающих программистов для внутренней автоматизации. Да, в большинстве компаний есть немного «20%»-ных парней, и именно они в основном выступают против тупых роговолосых менеджеров, за смену политик и апгрейд инструментария, в частности, за использование вменяемой системы контроля версий.

Жуткая правда №2

Большинство «альфа-гиков» забывают «жуткую правду №1».

Люди, которые работают над open-source, рубяться в жарких спорах о криптографии на Slashdot и качают последние релизы GIT, чрезвычайно склонны упускать из виду вообще факт существования «80%».

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

Признаюсь, я сам тоже в свое время потерял эти «80%» из виду.

Заглядывая назад в далекий 2000, когда меня нанял Collabnet для «проектирования замены CVS», я и пара моих коллег реально удивляемся.

Тогда, все ребята из «20%» использовали CVS, особенно в проектах с открытым кодом, и мы смотрели на свою работу, как на возможность завоевать сердца и умы open source-сообщества и, конечно, привлечь внимание всех этих альфа-чудаков.

Вышло иначе.

Угадайте, что случилось, когда мы наконец выпустили первый релиз Subversion в 2004? Стройные толпы «20%»-парней стали переводить свои open-source проекты на Subversion?

Неа, на это пошли только несколько небольших проектов.

Но вместо этого, нас окружили и просто затоптали дюжины маленьких компаний, слезающих с Microsoft SourceSafe, ведь их сотни «80%»-сотрудников ломились в наши списки рассылки за консультациями.

Сегодня, Subversion прошла путь от «крутого революционного продукта» к «проверенному варианту» для обоих аудиторий — и «20%» и «80%».

Компании из «80%», сидевшие на убогом контроле версий (или вовсе без такового) сейчас обсуждают SVN в блогах и форумах, например веб-разработчики дают друг другу «полезные советы» по использованию контроля версий (и Subversion в частности) для управления их вебсайтами в их маленьких вебстудиях.

То, что было новым и необычным для людей из «20%», в конце концов скатилось до статуса повседневного инструмента среди «80%».

Ирония (как показал Карл Фогель на одном из своих слайдов на OSCON) в том, что Subversion изначально предназначалась для того, чтобы перевернуть мир open source.

Эта переворот в некоторой степень произошел, но наиболее революционным он оказался именно в «корпоративном» мире!

Появление распределенного контроля версий

В 2007, распределенные системы контроля версий (DVCS, Distributed Version Control Systems) широко распространились среди «альфа»-разработчиков.

Они все увлечены инструментами типа git, mercurial, bazaar-ng, darcs, monotone… и смотрят на Subversion как на динозавра.

Передовые open source проекты переходят на DVCS.

Многие из пионеров DVCS оказываются либо чрезвычайно претенциозными и самоуверенными (типа Линуса Торвальдса!), либо просто являются бездумными фанатами, которые предпочитают DVCS, потому что они новые и клевые.

А почему бы не любить DVCS? Ведь это действительно круто.

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

Жуткая правда №3

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

Почему? Да, потому, что:

1. В DVCS есть компромисcы, которые допустимы далеко не для всех команд,
2. «80%»-ным парням DVCS просто сносит башню.

Так, сначала о компромиссах.

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

Я уже написал большое эссе об этом (см. «Риски распределенного контроля версий»).

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

Необходимо будет прилагать специальные усилия для обмена кода и самоорганизации в некоторую командную структуру.

Да, я знаю, что DVCS может имитировать работу централизованной системы; но поведение по-умолчанию имеет значение.

А поведение по-умолчанию — «ветвить», а не сотрудничать!

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

Да, правильные практики возможны с DVCS, но они не поощряются, что заставляет меня беспокоиться о будущем разработки с открытым исходным кодом (хотя может быть большая свобода стоит этого — время, как обычно, покажет…).

Далее, как быть с теми 80% людей, работающих в маленьких Windows-кодерских конторах? Что можно сказать о применимости DVCS для них?

• Большинство DVCS систем не работают под Windows вообще.
• Большинство DVCS не имеют интеграции с GUI-инструментами или системной оболочкой; они только для командной строки.
• Большинство из 80% кодеров обнаруживают в TortoiseSVN кучу «новых и интригующих» концепций, таких как «update» и «commit».

Им вообще трудно использовать контроль версий, а вы собираетесь объяснять им разницу между «pull» и «update», и между «commit» и «push»? Собираетесь? Смотрите мне в глаза и попробуйте еще раз повторить это c серьезной мордой лица.

• Корпорации по своей природе являются централизованными сущностями, причем центролизована не только их управленческая структура, но и их разделяемые ресурсы.

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

• Клонирование репозитория исходных кодов очень опасно с точки зрения корпоративной безопасности. Большинству корпораций абсолютно необходим контроль доступа к своему коду — например, важная интеллектуальная собственность отдельных частей репозитория доступна для чтения/записи только для определенных команд. Никакая DVCS сможет обеспечить детальное управление доступом, ведь полная история проекта лежит на локальном диске в каждом личном репозитарии.

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

Опять, повторю, в чем заключается ирония: Subversion проектировалась для чудаков из мира open source, но случилось так, что SVN больше прижилась в корпоративной разработке.

Итак, напомню:

• Subversion централизована;
• Subversion работает под Windows, как клиент, так и сервер;
• В Subversion реализован детальный контроль доступа.
• У него есть просто убийственный графический интерфейс (TortoiseSVN), который делает доступным контроль версий для людей, которые с трудом представляют, что это.
• SVN интегрируется со всеми графическими средами разработки типа VS.NET и Eclipse.

В результате — она идеально подошла для «80%», и поэтому компания Collabnet так успешна в поддержке этой аудитории.

Будущее DVCS и Subversion

Большинство разработчиков Subversion знакомы с новыми клевыми возможностями, DVCS, и уже идет множество дискуссий о том, как развивать Subversion 2.0 в этих направлениях.

Как бы то ни было, Карл Фогель заметил в своем длинном письме, что перед нами стоит задача, вбирая множество возможностей DVCS, удерживать Subversion максимально простой. Нет, мы не забудем о «80%»!

Subversion 1.5 очень близка к релиз-кандидату, и это должно остановить длительную критику со стороны DVCS о том, что «слияние в Subversion ужасно».

Ветвление по прежнему остается быстрой (constant-time) операцией, но теперь вы уже можете периодически сливать одну ветвь с другой без поиска по истории, чтобы узнать, какие именно опции слияния необходимы.

Subversion автоматически отслеживает, какие изменения уже слились, а какие — все еще сливаются.

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

Кстати, у нас также реализовано блестящее интерактивное разрешение конфликтов, вы даже можете подключить туда вашу любимый «слиятель» от Mercurial (и может передумаете от нас уходить?).

Также скоро выйдет переносимый формат заплаток-патчей.

Subversion 2.0 некоторые из нас представляют как централизованную систему, но уже с некоторыми децентрализованными возможностями:

• Мы хотим позволить рабочим копиям хранить «оффлайн коммиты» и даже управлять «локальными ветками», которые могут быть добавлены в центральный репозиторий, когда вы снова выйдете в сеть.
• Наша основная цель — сохранять интерфейс пользователя простым, чтобы избежать проклятия интерфейса DVCS (которые часто имеют 40, 50 и даже 100 различных команд!).
• Мы также планируем централизовать метаданные нашей рабочей копии в одном месте, и это должно ускорить многие клиентские операции.
• И наконец, мы возможно даже нагло сопрем формат репозитория «revlog» из Mercurial в качестве замены формата FSFS, имеющего несколько узких мест по части ввода/вывода.

Последнее слово

Позвольте мне заявить всем фанатикам DVCS: «да, это круто, но подумайте о перспективах!».

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

Любой, кто говорит, что DVCS таковой является, либо впаривает вам что-то, либо вообще забывает о «80%» — тогда ему следует оторваться от Slashdot и оглядется вокруг.

Обновление, 10/18/07: Множество комментариев явно свидетельствует, что мой пост следует слегка пояснить.

Я не ставил себе целью утверждать что «Subversion — есть счастье для всех даром подойдет всем», или что «большинство слишком глупо, чтобы использовать DVCS, а посему и не используйте…».

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

У меня нет сомнений, рано или поздно системы DCVS туда попадут и это будет прекрасно! И я умоляю евангелистов DVCS поднимать эти темы, а не беспечно отмахиваться от проблем DVCS, при этом приговаривая «к свалке» централизованные системы.

---

Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».