|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Version Control and “the 80%”Материал из CustisWikiВерсия от 18:05, 21 марта 2011; VitaliyFilippov (обсуждение | вклад)
СодержаниеДва типа программистовИтак, есть два «класса» программистов-разработчиков, назовем их «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), или какой-нибудь унаследованный антикварный хлам. Их знаний в точности достаточно, чтобы сделать свою работу, затем пойти домой на выходные и забыть о компьютерах.
Да, индустрия в основном состоит из небольших контор для разработки под Windows или малых компаний, нанимающих программистов для внутренней автоматизации. Да, в большинстве компаний есть немного «20%»-ных парней, и именно они в основном выступают против тупых роговолосых[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 освобождают пользователей, дают возможность работать без доступа в интернет, делают ветвление и слияние тривиальными операциями.
Почему? Да, потому, что:
Так, сначала о компромиссах. Хотя DVCS кардинально уменьшает начальные временные затраты для нового участника проекта (просто клонировать репозиторий и начать делать локальные коммиты), он также поощряет антисоциальное поведение. Я уже написал большое эссе об этом (см. «Риски распределенного контроля версий»). Вкратце: с централизованной системой, людей принуждают взаимодействовать и просматривать работу друг друга; с децентрализованной системой, поведение по умолчанию состоит в скрытом ветвлении проекта каждым разработчиком. Необходимо будет прилагать специальные усилия для обмена кода и самоорганизации в некоторую командную структуру. Да, я знаю, что DVCS может имитировать работу централизованной системы; но поведение по-умолчанию имеет значение. А поведение по-умолчанию — «ветвить», а не сотрудничать! Это поощряет людей забираться в пещеры и кодить там объемные доработки, а затем «сбрасывать» эти «кодовые бомбы» на своих товарищей, причем до момента «сброса» код не может быть кем-либо проверен. Да, правильные практики возможны с DVCS, но они не поощряются, что заставляет меня беспокоиться о будущем разработки с открытым исходным кодом (хотя может быть большая свобода стоит этого — время, как обычно, покажет…). Далее, как быть с теми 80% людей, работающих в маленьких Windows-кодерских конторах? Что можно сказать о применимости DVCS для них?
Им вообще трудно использовать контроль версий, а вы собираетесь объяснять им разницу между «pull» и «update», и между «commit» и «push»? Собираетесь? Смотрите мне в глаза и попробуйте еще раз повторить это c серьезной мордой лица.
Итак, напомню:
В результате — она идеально подошла для «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: «да, это круто, но подумайте о перспективах!». Поймите, что все инструменты имеют компромиссы, и что разные команды имеют разные потребности и ограничения. Нет серебряной пули для контроля версий, нет! Любой, кто говорит, что DVCS таковой является, либо впаривает вам что-то, либо вообще забывает о «80%» — тогда ему следует оторваться от Slashdot и оглядется вокруг.
Я не ставил себе целью утверждать что «Subversion — Я просто представил список — список проблем, которых нужно решить DVCS, чтобы войти в мейнстрим-инструменты разработки корпоративного ПО. У меня нет сомнений, рано или поздно системы DCVS туда попадут и это будет прекрасно! И я умоляю евангелистов DVCS поднимать эти темы, а не беспечно отмахиваться от проблем DVCS, при этом приговаривая «к свалке» централизованные системы.
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». Репликация: База Знаний «Заказных Информ Систем» → «Version Control and “the 80%”» |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |