Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО
Редактирование производилось в экранном режиме. Мы пользовались очень хорошим текстовым редактором ED-402 – близким аналогом vi. Страница читалась с ленты, мы редактировали ее содержимое, записывали ее обратно и читали следующую. Страница обычно состояла примерно из 50 строк кода. Мы не могли «заглянуть вперед» на ленту и увидеть предстоящие страницы и не могли вернуться назад к уже отредактированным страницам. Поэтому мы использовали листинги.
В листингах отмечались все предстоящие изменения, после чего файлы редактировались в соответствии с пометкой. Никто не писал и не изменял код спонтанно! Это было бы самоубийством.
После внесения изменений во все файлы, которые требовалось отредактировать, мы объединяли их с содержимым эталонного экземпляра. Полученная лента использовалась для проведения компиляции и тестирования.
Когда мы завершали тестирование и убеждались в том, что изменения работают, мы смотрели на распечатку. Если на ней не было новых кнопок, то рабочая лента просто переименовывалась в эталонную, а наши кнопки снимались с доски. Если на доске появлялись новые кнопки, то мы снимали свои и передавали рабочую ленту их владельцу для слияния результатов.
В группе было трое разработчиков. У каждого были кнопки своего цвета, поэтому мы могли легко определить, кто взял на редактирование те или иные файлы. А поскольку мы все работали в одной лаборатории и постоянно говорили друг с другом, текущее состояние кодовой базы постоянно хранилось в наших головах. Так что распечатка часто оказывалась излишней, и часто мы обходились без нее.
Инструменты
Современным разработчикам доступны самые разнообразные инструменты программирования. От некоторых стоит держаться подальше, но есть и такие, которыми должен уверенно владеть любой разработчик. В этой главе описан мой личный текущий инструментарий. Я не привожу полного описания всех представленных инструментов, так что обзор не является исчерпывающим. Я описываю лишь то, что использую сам.
Управление исходным кодом
В том, что касается управления исходным кодом, обычно стоит использовать программы с открытым кодом. Почему? Потому что они пишутся разработчиками и для разработчиков. Иначе говоря, разработчики пишут программы с открытым кодом для самих себя, когда им понадобится работоспособное решение.
Существует немало дорогих, коммерческих «корпоративных» систем контроля версий. По моему мнению, они продаются не столько разработчикам, сколько руководителям, менеджерам и «инструментальным группам». Список функций таких программ выглядит впечатляюще. К сожалению, в нем часто не оказывается того, что действительно нужно разработчикам. И главной проблемой обычно оказывается скорость.
«Корпоративные» системы управления исходным кодом
Вполне возможно, что ваша фирма уже вложила целое состояние в «корпоративную» систему управления исходным кодом. В таком случае примите мои соболезнования. Вероятно, по политическим соображениям вы не сможете просто сказать: «Дядюшка Боб говорит, что ей не надо пользоваться». Тем не менее существует простой выход.
Вы можете регистрировать исходный код в «корпоративной» системе в конце каждой итерации (каждые две недели или около того), а в середине итераций использовать систему с открытым кодом. Все будут довольны, вы не нарушите корпоративных правил, а ваша производительность останется высокой.
Пессимистическая и оптимистическая блокировка
В 1980-е годы пессимистическая блокировка казалась хорошей идеей. В конце концов, простейший путь к решению проблем параллельного обновления – их распараллеливание. Если я редактирую файл, то вам лучше к нему не прикасаться. Система цветных кнопок, использованная нами в конце 1970-х, была своего рода механизмом пессимистической блокировки. Если файл был помечен кнопкой, то другие не должны были его редактировать.
Конечно, у пессимистической блокировки есть свои недостатки. Если заблокировать файл и уйти в отпуск, то все остальные пользователи, которые захотят работать с файлом, окажутся в тупике. Даже если файл останется заблокированным на день-два, это задержит работу других.
Современные инструменты значительно лучше справляются со слиянием параллельно редактируемых исходных файлов. Ведь это нетривиальная задача: программа анализирует два разных файла и предка этих двух файлов, а затем применяет различные стратегии для определения способа интеграции параллельных изменений. И надо сказать, хорошо справляется с этой работой.
Так что время пессимистической блокировки прошло. Теперь нам не нужно устанавливать блокировку файлов при редактировании. Более того, вообще не нужно беспокоиться о блокировке отдельных файлов – мы запрашиваем сразу всю систему и редактируем нужные файлы.
Когда все будет готово к регистрации изменений, выполняется операция обновления. Она сообщает нам, не было ли более ранней регистрации изменений другими пользователями, выполняет автоматическое слияние большинства изменений, находит конфликты и помогает выполнить остальные слияния. После этого объединенный код регистрируется в базе.
Позднее в этой главе я достаточно подробно освещу роль автоматизированных тестов и непрерывной интеграции в этом процессе. А пока достаточно сказать, что код, не прошедший всех тестов, ни при каких условиях не должен регистрироваться в базе. Никогда.
CVS/SVN
Одна из традиционных систем управления исходным кодом – CVS – была хороша для своего времени, но в современных проектах она уже начинает отставать. Хотя CVS отлично подходит для работы с отдельными файлами и каталогами, она не слишком хорошо справляется с переименованием файлов и удалением каталогов. А уж подкаталоги Attic… Чем меньше говорить об этом, тем лучше.
С другой стороны, система Subversion работает очень хорошо. Она позволяет получить доступ ко всей системе за одну операцию. В ней легко выполняются операции обновления, слияния и закрепления изменений. При отсутствии разветвляющихся изменений системы SVN достаточно просты в управлении.
Разветвление
До 2008 года я избегал любых форм ветвления, кроме простейших. Если разработчик создает ветвь, то эта ветвь должна быть возвращена в основную линию до конца итерации. Но я так сурово относился к ветвлению, что оно крайне редко применялось в тех проектах, в которых я участвовал.
Если вы используете SVN, то я по-прежнему считаю, что это хорошая политика. Однако в последнее время появились новые инструменты, которые полностью изменяют ситуацию. Я говорю о распределенных системах управления исходным кодом. В этой категории моим любимым инструментом является git. Сейчас я расскажу об этой системе более подробно.
git
Я начал использовать git в конце 2008 года. Эта система полностью изменила мой подход к управлению исходным кодом. Объяснения того, почему эта программа так сильно изменила правила игры, выходят за рамки книги. Тем не менее сравнение рис. П.1 с рис. П.2 красноречивее многих слов, которые я здесь приводить не буду.
Рис. П.1. Проект FitNesse под управлением Subversion
На рис. П.1 показан ход разработки проекта FitNesse за несколько недель под управлением SVN. Вы видите эффект моей жесткой политики отказа от ветвления. Мы попросту не использовали его, зато в главной ветке часто выполнялись операции обновления, слияния и закрепления.
На рис. П.2 показана структура нескольких недель разработки того же проекта с использованием git. Как видно из рисунка, операции ветвления и слияния происходят постоянно. Дело не в том, что я ослабил свою политику ветвления; просто такой рабочий процесс стал самым очевидным и эффективным. Отдельные разработчики создают ветви с очень коротким сроком жизни, а затем объединяют их с результатами своих коллег тогда, когда считают нужным.
Также обратите внимание на то, что на рисунке не видна «настоящая» главная ветвь. Дело в том, что ее попросту нет. Разработчики хранят на своих локальных компьютерах копию всей истории проекта. Они вносят изменения и регистрируют их в своей локальной копии, а затем синхронизируют с копиями коллег по мере надобности.
Рис. П.2. Проект FitNesse под управлением git
Правда, я поддерживаю специальный эталонный репозиторий, в котором хранятся все опубликованные версии и внутренние сборки. Но называть его «главной ветвью» значило бы совершенно не понимать суть дела. В действительности это всего лишь удобный «снимок» всей истории, которая сохраняется локально всеми разработчиками.
Если вы не поняли что-то из сказанного, это нормально. На первых порах git вызывает немало затруднений. К тому, как работает эта система, нужно привыкнуть. Но будьте уверены: git и другие подобные системы – это будущее управления исходным кодом.
