Version Control and “the 80%”
Перевод статьи 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%»-ных парней, и именно они в основном выступают против тупых роговолосых[1] менеджеров, за смену политик и апгрейд инструментария, в частности, за использование вменяемой системы контроля версий.
- Жуткая правда №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-система, любой, кто заявит вам что она полностью идеальна для всего — неадекватен.
Почему? Да, потому, что:
- В DVCS есть компромисcы, которые допустимы далеко не для всех команд,
- «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».
Репликация: База Знаний «Заказных Информ Систем» → «Version Control and “the 80%”»