07.06.2008 17:11:50

Я имею в виду, конечно, не компиляторы, IDE и прочие отладчики, без которых нельзя ничего разработать в принципе, а средства, обеспечивающие связанные с разработкой функции. Или всё то, что принято сейчас называть программной инженерией.

Разработчики программного обеспечения сейчас не страдают от недостатка инструментов. Скорее даже, наоборот, страдают от их переизбытка.

Представьте, что вам наконец-то подвернулась возможность начать свой собственный программный проект. То есть вы и только вы решаете, сколько вам нужно людей и какой квалификации, как распределить роли в команде и самое главное - как заставить всё это работать. А поскольку вы айтишник (вы же айтишник?), вы уже знаете, что в рутинной работе вам обязан помогать компьютер. Нет, не знаете? А вы точно айтишник?

Производители программ и изобретатели хитрых (или, наоборот, суперпростых) методик наперебой предлагают вам свои "самые лучшие" инструменты, заманивают вас на семинары, на которых скрыто или безо всякого стеснения рекламируют RUP, Jira, "обезжиренные багтрекеры" и прочая, и прочая. И вы понимаете, что всё это действительно полезно, и неплохо было бы всё это освоить и изучить, но... без чего же действительно нельзя обойтись? Какие инструменты нужно выбрать ещё до начала работы над проектом?

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

Во-первых, средство управления версиями.

Во-вторых, средство учёта ошибок (багтрекер).

Управление версиями

Это может показаться невероятным, но есть ещё программисты, не знающие, что это такое. Как, вы тоже не знаете?! Значит, это и правда ваш первый проект. :) Что, вы знаете, но не видите необходимости в его использовании?! Товарищ... а вы как вообще сюда попали? Ах, погреться зашли... Ну грейтесь, только руками ничего не трогайте.

Серьёзно, если перед вами стоит задача создания чего-то более сложного, чем программа класса "Hello, world!", то без системы управления версиями вам не обойтись.

На самом деле, я бы и "Hello, world!" поместил в репозиторий. Зачем? А вам никогда не приходилось при создании нового консольного приложения снова и снова вспоминать, какие же заголовочные файлы должны быть включены вместо stdafx.h? Нет? Ну, значит, это только у меня память такая дырявая.

А ещё шутники говорят, что первое существо, которое создал Бог, говорило только "Hello World!" и умирало. Интересно, далеко бы Он продвинулся без репозитория на ДНК...

В общем, как вы поняли, я не готов даже обсуждать вопрос "to use or not to use" применительно к системе управления версиями. Вопрос стоит только в выборе конкретного средства.

А на вопрос "какое средство выбрать" я вам сразу отвечу: не знаю. Это зависит от многих особенностей вашего проекта. Заходите сюда и выбирайте любое.

Может быть, вам помогут уже проведенные кем-то сравнительные исследования разных средств.
Например, это (Осторожно! Плохо скрытая реклама!).
Или это.


Я же могу только поделиться своим опытом.

Моё знакомство с системами управления версиями началось с PVCS. Хоть эта система и была навязана компании, в которой я тогда работал, польза от её внедрения была очевидной. До этого программисты хранили все предыдущие версии своих программ в zip файлах, которые (файлы) ежедневно записывались на кассеты системным администратором, которые (кассеты) потом навсегда терялись где-то в тёмных и мрачных углах серверной комнаты, в которые (углы) мы боялись заходить.

Найти какую-то раннюю версию программы, отправленную несколько месяцев назад клиенту, было практически невозможно. Клиент же тупо твердил: "Мы потратили на тестирование версии 4.236-56/11g полгода, в ней всё работало, а потом вы всё сломали! Мне нужна именно эта версия, только поменяйте на чеке надпись GREY SHIT на логотип нашей компании!" (Распространённая программистская шутка, не правда ли? Я и сам так когда-то шутил, до тех пор, пока на одной важной презентации демонстрационная версия моей программы не обозвала заказчика, случайно нажавшего ту самую кнопку, законченным кретином.)

PVCS изменил ситуацию. Теперь каждая когда-то отправленная версия в любой момент могла быть извлечена из хранилища, при необходимости подчищена и скомпилирована заново. А в качестве бонуса можно было вычислить, кто же поместил злосчастный "GREY SHIT" в исходники. Может, поэтому многие программисты поначалу приняли PVCS в штыки? Вряд ли. Просто программисты до сих пор очень не любят заниматься чем-то, не являющимся программированием.

Это, кстати, одна из причин, по которой систему управления версиями нужно выбрать и установить до начала разработки. Все члены команды должны принимать её как нечто данное свыше, всякая попытка подискутировать на эту тему должна считаться ересью и караться по суровым законам Великой инквизиции.

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

Короче, у меня не было выбора: я мог использовать только Visual Source Safe, потому что он и так уже входил в состав Microsoft Visual Studio, а покупка других программ бюджетом не была предусмотрена. Да, я не забыл сказать, что постоянного доступа в Интернет у нас тогда тоже не было?

В общем, VSS оказался довольно неплохим решением для маленькой команды. В нём нашлось всё необходимое: и возможность назначать метки выпускаемым релизам, и разделение файлов между несколькими проектами, и интерфейс командной строки для автоматизированных сборок. Разочаровало только утверждение Microsoft о том, что VSS является клиент-серверной системой. Коротко: это наглая ложь маркетологов. Ну да ладно, к этому все давно уже привыкли.

Иногда диву даёшься, как долго могут влиять на вашу жизнь когда-то принятые второпях решения. Мы до сих пор используем эту базу Visual Source Safe. Размер репозитория перестали отслеживать, после того как он перевалил за четыре гигабайта. Мы только периодически покупаем более мощный файл-сервер и более быстрые диски.

Вокруг VSS выстроены практически все наши процедуры разработки.

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

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

Откуда берутся эти версии? А это, как раз, в-третьих. Если что-то с какой-то целью извлекается из VSS, то на этом чём-то должна лежать уникальная метка релиза, назначенная по специальным правилам - простым, но жёстким (при нарушении этих правил приложение просто не соберётся).

Но приближается очередная критическая точка: скоро еженедельные архивы перестанут помещаться на один CD. Некоторые старые файлы VSS уже не в состоянии восстановить, за ними нужно лезть в бэкап. Да и для генерации отчётов об изменениях давно уже приходится отрывать пятую точку от стула и идти к файл-серверу или подключаться к нему через Remote Admin, потому что попытка сгенерировать отчёт в клиенте VSS на своём локальном компьютере намертво блокирует сеть на полчаса.

В общем, я начал присматриваться к Subversion, в комплекте с TortoiseSVN. Скачал, поставил локально, и храню в нём исходники своих интернет-проектов. И, похоже, у него есть все шансы стать моим любимым средством контроля версий на ближайшие несколько лет. А программистов, которые попытаются возражать, я сожгу на костре. Шютка.

Своими соображениями по поводу багтрекера поделюсь в следующий раз.