Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

В 1978 году я работал в Teradyne над телефонной тестовой системой, о которой упоминал ранее. Система состояла примерно из 80 тысяч строк кода ассемблера M365. Исходный код хранился на магнитных лентах.

Ленты напоминали 8-дорожечные стереокассеты, которые были так популярны в 1970-е годы. Лента была склеена, а накопитель мог перематывать только в одном направлении. Ленты в кассетах имели длину 10, 25, 50 и 100 футов. Чем длиннее была лента, тем больше времени занимала «перемотка», так как накопителю приходилось просто перематывать ее вперед до «точки загрузки». Перемотка 100-футовой ленты до точки загрузки занимала около 5 минут, поэтому мы осмотрительно подходили к выбору длины лент. [54]

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

На полке в лаборатории лежала эталонная 100-футовая копия ленты с исходным кодом. Чтобы отредактировать файл, мы ставили в один накопитель эталонный экземпляр, а в другой – 10-футовую пустую (рабочую) ленту. Эталонная лента проматывалась до нужного файла, после чего файл копировался на рабочую ленту. Тогда мы «перематывали» обе ленты в начало, и эталонная лента ставилась обратно на полку.

На доске в лаборатории была прикреплена специальная распечатка эталонной ленты. Когда мы создавали копии файлов, которые требовалось отредактировать, мы прикрепляли цветную булавку рядом с именем этого файла. Так производился контроль изменений!

Редактирование производилось в экранном режиме. Мы пользовались очень хорошим текстовым редактором ED-402 – близким аналогом vi . Страница читалась с ленты, мы редактировали ее содержимое, записывали ее обратно и читали следующую. Страница обычно состояла примерно из 50 строк кода. Мы не могли «заглянуть вперед» на ленту и увидеть предстоящие страницы и не могли вернуться назад к уже отредактированным страницам. Поэтому мы использовали листинги.

В листингах отмечались все предстоящие изменения, после чего файлы редактировались в соответствии с пометкой. Никто не писал и не изменял код спонтанно! Это было бы самоубийством.

После внесения изменений во все файлы, которые требовалось отредактировать, мы объединяли их с содержимым эталонного экземпляра. Полученная лента использовалась для проведения компиляции и тестирования.

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

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

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

В том, что касается управления исходным кодом, обычно стоит использовать программы с открытым кодом. Почему? Потому что они пишутся разработчиками и для разработчиков. Иначе говоря, разработчики пишут программы с открытым кодом для самих себя, когда им понадобится работоспособное решение.

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

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

Вы можете регистрировать исходный код в «корпоративной» системе в конце каждой итерации (каждые две недели или около того), а в середине итераций использовать систему с открытым кодом. Все будут довольны, вы не нарушите корпоративных правил, а ваша производительность останется высокой.

В 1980-е годы пессимистическая блокировка казалась хорошей идеей. В конце концов, простейший путь к решению проблем параллельного обновления – их распараллеливание. Если я редактирую файл, то вам лучше к нему не прикасаться. Система цветных кнопок, использованная нами в конце 1970-х, была своего рода механизмом пессимистической блокировки. Если файл был помечен кнопкой, то другие не должны были его редактировать.

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

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

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