This page is an archived copy on Gagin.ru personal site

InterNet magazine, number 15
Сюжеты | Тема номера
Виктор Лавренко

Сапоги для сороконожки

Сегодняшние разговоры о совместной работе интересны представителям широкого круга профессий. Программисты, специалисты по информационным технологиям стараются сделать легче и веселей жизнь журналистов, переводчиков, менеджеров... Но сапожники, к счастью, позаботились и о своих сапогах. Виктор ЛАВРЕНКО, sapogi@lavrenko.pp.ru

Зачем...

Основное назначение систем обеспечения совместной работы программистов, о которых пойдет речь в этой статье, - разрешение конфликтов. Нет, они не спасут тружеников от того, что в один прекрасный момент все перессорятся, выясняя, должна ли ширина отступов в тексте программы равняться двум или четырем пробелам. Но они помогут им распределить роли, договориться, кто за что отвечает, и не допустят, чтобы программист NN с похмелья внес в самый важный модуль вместо исправления ошибку.

Cистема управления версиями (version control system, VCS) не даcт двум программистам сделать изменения одной и той же функции или файла (или даст, но потом предупредит, если эти изменения конфликтуют между собой). Более продвинутые системы позволят вести развитие нескольких вариантов программы параллельно, а когда настанет судный день и за основу дальнейшей разработки будет взят только один вариант, система позволит влить в него все то ценное, что было реализовано в других.

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

Почему...

Отвлекусь немного от основной темы статьи и расскажу о самих линуксовых (группирующихся вокруг операционной системы Linux) сообществах. ОС Линукс и основные программы для нее - свободное программное обеспечение. Этот эпитет означает, что они хотя и могут продаваться, но для них можно бесплатно получить исходный код. Таким образом, кто угодно может продавать эти программы, при этом не делая никаких отчислений программистам, которые эти программы написали.

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

Часто такие проекты спонсируют коммерческие фирмы, но не из-за нескончаемого благородства и желания помочь ближнему, а преследуя чисто прагматические цели. Например, фирма SGI (www.sgi.com), занимающаяся производством быстродействующих компьютеров серии Cray (www.cray.com), спонсирует разработку сложного ресурсоемкого программного обеспечения, которое является мультиплатформенным, т.е. может работать не только под ОС Linux, но и под операционными системами IRIX и UNICOS. Последние системы довольно близки к Linux (прародителем обеих является ОС UNIX фирмы AT&T), поэтому обеспечение мультиплатформенности не требует от программистов больших усилий. Будучи бесплатными, эти программы быстро распространяются, приобретая массу пользователей. И всем им также понадобятся быстродействующие машины. Конечно, не все пользователи обязательно предпочтут именно машины SGI, но какая-то часть обязательно остановит свой выбор на них. В выигрыше и SGI, и программисты.

Кроме того, участие в разработке такого ПО можно назвать инвестициями в самого себя. Это актуально и в нашей стране, причем подобное вложение гораздо эффективнее, чем, скажем, покупка акций очередного "Хопра".

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

Участие в некоммерческом проекте с открытым исходным кодом может дать вам все эти плюсы. Допустим, в вашем городе требуются специалисты для написания драйверов. Конечно, не имея опыта создания подобных продуктов, устроиться на эту работу будет весьма проблематично. Выход прост: вы присоединяетесь к проекту Linux (www.linux.org) и пишете там парочку простеньких драйверов к устройствам, для которых они еще не написаны, либо улучшаете уже существующие драйверы - в ОС Linux для огромного количества устройств применяются общие драйверы, не использующие особенностей каждой конкретной модели устройства (опять же, к сожалению). Вот вам и опыт.

Парадоксально, но работая в линуксовых проектах, можно стать уникальным специалистом по Windows, например, подключившись к проекту Wine (www.winehq.com), который трудится над созданием эмулятора Windows API. Успешно поработав в нем, вы будете знать и все достоинства народной ОС, и все недостатки, и даже ошибки - ведь хороший эмулятор должен работать не по спецификации (которая у продуктов Microsoft часто расходится с серой действительностью), а по факту - т.е. должен воспроизводить не только корректную работу, но и все глюки: ведь разработчикам часто приходится их затыкать. Если же глюк отсутствует, то ошалевшая затычка может работать неправильно, несправедливо обрушивая хорошую программу. При этом претензии будут не к авторам Windows, а к создателям эмулятора - пользователей мало волнует, почему происходит данная ошибка, им просто нужно, чтобы их программы работали.

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

...И как

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

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

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

Вспоминается забавная история. Как-то бедные и, простите, провинциальные программисты попросили у своего начальника денег на покупку пиратского компакта с операционной системой. Когда они в двух словах объяснили боссу, что это за программа, умный начальник парировал их просьбу фантастически верной репликой: "Программа? Ну вы ведь программисты, вот сами и напишите эту программу".

Не стоит писать те программы, которые уже написаны. Поэтому расскажу вкратце про ту систему обеспечения групповой работы программистов, которая используется разработчиками свободного ПО. Я имею в виду RCS и CVS (www.cyclic.com/cvs/info.html).

"Ну вот, - скажут искушенные читатели, - опять про эти юниксовые программки с интерфейсом командной строки". Действительно, в них не встроен графический интерфейс. Просто в юниксах все сделано по-умному. CVS управляет работой RCS и как бы является для нее интерфейсом - таким образом, человеку, работающему с CVS, нет нужды разбираться в ключах и командах RCS. В свою очередь, для CVS мне известны четыре графических интерфейса (tkCVS - www.cyclic.com/tkcvs/, RADCVS - www.radsoft.com/radcvs, gCVS - www.arachne.org/software/gcvs/ , CVL - www.sente.ch/software/cvl/), два Java-интерфейса (jCVS - www.ice.com/java/jcvs/, cvsClient - www.extreme.indiana.edu/pseware/vc/cvsClient) и даже веб-интерфейс (CVS Web - www.freebsd.org/~fenner/cvsweb/), используя которые, вам уже не придется работать с командной строкой. Можете (как всегда, бесплатно) скачать из Сети любой (или даже несколько; можно даже все семь - и тоже на халяву, только не забывайте принимать таблетки от жадности) и наслаждаться знакомой графикой.

Многие линуксовые текстовые редакторы, включая наиболее популярный среди юниксоидов - Emacs, позволяют работать с RCS напрямую. Даже в WYSIWYG-подобный процессор документов LyX (www.lavrenko.pp.ru/lyx) встроена возможность общения с RCS.

Существует специальный модуль, который можно встроить... в Microsoft Developer Studio C++ и наслаждаться возможностями CVS под ОС Windows (depc14.gsi.de/Hades/cvc-msdev.htm). Многие другие среды разработки программ, включая, например, CodeWright (www.premia.com), тоже могут быть соединены с CVS.

CVS и RCS полезны не только для программистов. Я часто использую RCS при написании заметок, т. к. по привычке от программирования очень люблю их резать. Если по каким-то причинам я хочу вернуться к старой версии, RCS помогает мне "вернуть прошлое".

Кроме того, CVS можно успешно использовать, например, при разработке сайтов, о чем красноречиво свидетельствует оставленная на всеобщее обозрение внутренняя информация этой программы на сайте ее автора (www.cyclic.com/CVS/).

Оба продукта существуют довольно давно - CVS ведет свою историю с 1989 года, а RCS скоро отпразднует свое совершеннолетие - он появился аж в 1982 году. Это не значит, что они устарели. Программы развиваются - например, в 1995 году в CVS встроили свой собственный протокол, по которому легко получить удаленный доступ к хранилищу CVS через Интернет. До сих пор к RCS прилагается список возможностей на сотню строк, которые авторы собираются реализовать в ближайшем будущем. Если захотите, можете к ним присоединиться (hammer@math.purdue.edu).

Суть функционирования RCS состоит в хранении нескольких версий одного файла. Эти версии могут быть как последовательными улучшениями, так и различными вариантами (branch) реализации, если автор (или авторы) еще не решил, какой из вариантов лучше. Основные операции в RCS - это захват на редакцию, когда программист как бы вытаскивает файл-листок из виртуального портфеля, запрещая другим программистам изменять этот файл (об этом заботится сама RCS), и его заливка, когда программист, протестировав сделанные изменения, кладет файл-листок обратно в портфель.

Если RCS работает с файлами, то CVS манипулирует целыми каталогами. Важно, что в CVS отсутствует фаза захвата файла на редактирование (есть все же команда edit, но она не осуществляет монопольного захвата, а лишь позволяет проинформировать других разработчиков о том, что данный файл изменяется). Все изменения сваливаются в общую кучу, и если в изменениях нет никаких конфликтов, система спокойно сливает их в единый слепок. Это действительно очень важно, т.к. иногда требуется исправить небольшую ошибку в файле, над которым в данный момент трудится очень умный, но не слишком расторопный NN, а заниматься поддержкой нескольких параллельно развивающихся версий всего лишь одного файла не всегда удобно.

Когда программу выпускают в свет, администратор CVS порождает новый вариант, соответствующий, скажем, версии 1.0. Отметим, что версии (version) релизов и версии (revision) файлов - это разные, хотя и связанные друг с другом, понятия. Тем временем программисты сразу же начинают работу над новой версией 2.0. Написать совершенно безошибочную программу невозможно, поэтому к версии 1.0 начнут выходить исправления - 1.1, 1.2 и т.д. Разумеется, все эти исправления должны отразиться и на коде версии 2.0. Таким образом, возникает два варианта кода: стабильный и находящийся в состоянии разработки.

Когда коллектив сравнительно большой, невозможно синхронизировать работу всех так, что к моменту релиза версии 1.0 все будут чем-то заняты. Кто-то сделает свою работу раньше, кто-то - позже. Во время тестирования программисты тоже редко загружены на все сто процентов и уже могут начинать работу над следующей версией. В этом случае может появиться еще больше вариантов: скажем, одни программисты подчищают все ошибки в версии 1.0, другие принялись за 2.0, а третьи - реализовывают первые функции из версии 3.0. Здесь без системы контроля версий обойтись будет трудно.

Еще более сложная ситуация может сложиться, когда программный продукт дорастет, скажем, до версии 5.0 - тогда у каждой версии с первой по пятую будут свои пользователи. Конечно, можно действовать по принципу Microsoft и поддерживать пользователей только последней версии, предлагая всем остальным заплатить деньги за обновление. Но так поступают не все - например, фирма Sun осуществляет выпуск обновлений ко всем девяти релизам своей операционной системы Solaris (это к вопросу о том, по каким критериям следует выбирать операционную систему). Если вы решились последовать ее примеру, CVS будет для вас незаменим.

Итог - RCS стоит пользоваться, даже если вы работаете всего лишь с десятком файлов, а CVS - отличное к ней дополнение. В конце концов не для каждой юниксовой программы найдется семь различных интерфейсов - о чем-то это да говорит.


В оглавление номера This page is an archived copy on Gagin.ru personal site