Version Control and “the 80%” - История изменений

VitaliyFilippov в 16:22, 23 марта 2011

2011-03-23T16:22:17Z

VitaliyFilippov в 15:05, 21 марта 2011

2011-03-21T15:05:48Z

VitaliyFilippov в 15:04, 21 марта 2011

2011-03-21T15:04:00Z

BenderBot: 1 версия

2009-06-30T15:43:37Z

1 версия

StasFomin: /* Последнее слово */

2009-06-30T11:15:56Z

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

WikiSysop: 1 версия

2008-09-03T16:33:11Z

1 версия

StasFomin: {{replicate-from-custiswiki-to-lib}}

2008-09-03T16:31:03Z

Новая страница

<blockquote>
Перевод статьи [http://blog.red-bean.com/sussman/?p=79 {{PAGENAME}}] (Контроль версий и «правило 80 процентов») выполнен сообществом компании [http://www.custis.ru «Заказные ИнформСистемы»].
</blockquote>

{{caution}} Предупреждение: Я собираюсь сделать несколько смелых, возможно даже слишком, обобщений,
основанных на моих 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-система, любой, кто заявит вам что она полностью идеальна для всего — неадекватен.

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

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

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

Я уже написал большое эссе об этом (см. «[[The Risks of Distributed Version Control|Риски распределенного контроля версий]]»).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В результате — она идеально подошла для «80%», и поэтому компания [http://www.collab.net/community/ Collabnet] так успешна в поддержке этой аудитории.

== Будущее DVCS и Subversion ==

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

Как бы то ни было, Карл Фогель заметил в своем [http://svn.haxx.se/dev/archive-2007-06/0780.shtml длинном письме], что перед нами стоит задача, вбирая множество
возможностей 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 — <s>есть счастье для всех даром</s> подойдет всем», или что «большинство слишком глупо, чтобы использовать DVCS, а посему и не используйте…».

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

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

{{replicate-from-custiswiki-to-lib}}
[[category:Статьи о Subversion]]

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

@@ Строка 225: / Строка 225: @@
 И я умоляю евангелистов DVCS поднимать эти темы, а не беспечно отмахиваться от проблем DVCS,
 при этом приговаривая «к свалке» централизованные системы.
 {{replicate-from-custiswiki-to-lib}}
 [[category:Статьи о Subversion]]

← Предыдущая	Версия 15:43, 30 июня 2009
(нет различий)

@@ Строка 44: / Строка 44: @@
 или малых компаний, нанимающих программистов для внутренней автоматизации.
 Да, в большинстве компаний есть немного «20%»-ных парней,
-и именно они в основном выступают против тупых рогоголовых менеджеров,
+и именно они в основном выступают против тупых роговолосых<ref>Отсылка к «роговолосому» (''pointy-haired'') менеджеру из комикса и мультфильма [http://dilbertru.blogspot.com Dilbert].</ref> менеджеров,
 за смену политик и апгрейд инструментария, в частности,
 за использование вменяемой системы контроля версий.
@@ Строка 89: / Строка 89: @@
 == Появление распределенного контроля версий ==
-В 2007, распределенные системы контроля версий (DVCS, Distributed Version Control Systems) широко распространились среди «альфа»-разработчиков.
+В 2007, распределенные системы контроля версий (DVCS, ''Distributed Version Control Systems'') широко распространились среди «альфа»-разработчиков.
-Они все увлечены инструментами типа git, mercurial, bazaar-ng, darcs, monotone…
+Они все увлечены инструментами типа <tt>git</tt>, <tt>mercurial</tt>, <tt>bazaar-ng</tt>, <tt>darcs</tt>, <tt>monotone</tt>…
 и смотрят на Subversion как на динозавра.
@@ Строка 97: / Строка 97: @@
 Многие из пионеров DVCS оказываются либо чрезвычайно претенциозными и самоуверенными
-(типа Линуса Торвальдса!), либо просто являются бездумными фанатами, которые
+(типа [[Линус Торвальдс о GIT на Google Talks|Линуса Торвальдса]]!), либо просто являются бездумными фанатами, которые
 предпочитают DVCS, потому что они новые и клевые.
@@ Строка 143: / Строка 143: @@
 Что можно сказать о применимости DVCS для них?
 * Большинство DVCS систем не работают под Windows вообще.
-* Большинство DVCS не имеют интеграции с GUI-инструментами или системной оболочкой; они только для коммандной строки.
+* Большинство DVCS не имеют интеграции с GUI-инструментами или системной оболочкой; они только для командной строки.
-* Большинство из 80% кодеров обнаруживают в TortoiseSVN кучу новых, интригующих концепций, таких как «update» и «commit».
+* Большинство из 80% кодеров обнаруживают в TortoiseSVN кучу «новых и интригующих» концепций, таких как «update» и «commit».
 Им вообще трудно использовать контроль версий, а вы собираетесь объяснять им разницу между «pull» и «update»,
@@ Строка 210: / Строка 210: @@
 Поймите, что все инструменты имеют компромиссы, и что разные команды имеют разные потребности и ограничения.
-Нет серебрянной пули для контроля версий, нет!
+Нет серебряной пули для контроля версий, нет!
 Любой, кто говорит, что DVCS таковой является, либо впаривает вам что-то, либо

← Предыдущая	Версия 16:33, 3 сентября 2008
(нет различий)