Чистый Контроль Версий

Вступление

Всем привет, Серега ^[1] снова с вами. Извиняюсь за долгое молчание и отсутствие в комментариях. Времени на интернет совсем не было. Выпускали очередную версию GPA ^[2]. Кстати уже пятый раз в этом году — рекорд для нашей команды.

При таком темпе чем-то еще заниматься очень сложно. Особенно когда в сжатые сроки нужно портироваться на OsX, придать «человеческий» вид версии под Ubuntu и одновременно проникнуть внутрь изоляции приложения Windows 8 Store. Опять было множество споров о внешнем виде и работе System Analyzer. Очень сложно сделать инструмент красивым, простым и легким и в то-же время очень полезным.

Кстати, об OsX — впечатления от нее неоднозначные. По крайней мере, количество претензий в ее адрес во время портирования превзошло аналогичный показатель для Ubuntu. Отдельного упоминания заслуживает XCode — маковская интегрированная среда разработки ПО. Она даже не предупреждает о том, что у меня остались какие-то не сохраненные файлы и она не может их сохранить. Просто не счесть сколько раз нам приходилось заново выставлять настройки сборки всех проектов нашего продукта. Проектов много, настройки совершенно интуитивно не понятны и возиться с ними приходится долго — тут легко остаться недовольным.

Лично я уверен, что IDE обязано сохранять любые изменения при первой же возможности, без всяких этих «а вы уверены?» и просьб со стороны пользователя. За долгие годы работы у меня уже выработался рефлекс нажимать Ctrl+S чуть ли не после каждой точки с запятой. К сожалению это не работает, когда меняются настройки проекта или сборки, что и приводит к досадным недоразумениям. Если же возникнет необходимость какое-то изменение отменить, то на этот случай опытный программист всегда и везде приспосабливает систему контроля версий исходников.

Храните коды в системе контроля версий

К сожалению, культура использования системы контроля версий исходных файлов практически всегда приходит сверху. Программист, использующий такую систему по собственной инициативе даже для своих экспериментов — большая редкость. По этому, наличие у программиста и использование им такой системы, способность создавать метки и ветвления яркий признак профессионализма. А список изменений в этой системе — подтверждение или опровержение этого признака. Например изменение «исправил ошибку такую-то, и такую-то, заменил А на Б, оптимизировал то и ускорил время сборки» сразу выдает непрофессионала. Если в таком изменении обнаружится ошибка, то не сразу понятно, где искать. А если из-за ошибки придется изменение отменить, то отменятся все перечисленные исправления и улучшения, хотя сбой был только в одном. Еще подобное описание изменений может свидетельствовать о человеке, не способном сфокусироваться на чем-то одном, а постоянно скачущем с одного занятия на другое, пытающегося делать кучу дел одновременно и с трудом доделывющего начатое до конца.

Правильный подход к использованию системы контроля версий следующий:

• Вносимые изменения должны быть небольшими и содержать какое-то одно конкретное и законченное действие. Даже исправление некоторых ошибок иногда лучше разделить на несколько последовательных изменений. Однако сильно увлекаться и вносить в систему каждую строчку кода по отдельности тоже не стоит. Тут нужно руководствоваться голосом разума. При напряженной разработке внести 1 — 4 изменений в день — нормально. В час — перебор. В неделю — явный недобор.
• При работе в команде в момент внесения изменений каждый раз необходимо синхронизироваться с изменениями коллег, чтобы изменения включались в работу как можно быстрее и ошибки в них находились как можно раньше.
• При работе над изменением сначала нужно определиться, что вы собираетесь сейчас делать и делать именно это. Все идеи того, что еще можно и нужно поправить следует заносить в TO_DO список, а не бросаться их воплощать прямо здесь и сейчас. В этот список нужно смотреть каждый раз когда возникает вопрос «что делать дальше?». Запись из TO_DO списка потом обычно с минимальными изменениями переноситься в название вносимого изменения.

Система контроля версий также является и системой генерации отчетов о проделанной работе. Взять изменения за некоторый период времени; обобщить некоторые слишком детальные подробности; добавить общих слов и скриншотов — и самый правильный отчет программиста готов. Если сделана куча работы, а внесенных в систему изменений по пальцам пересчитать — это значит, что программист занят чем-то другим: исследованием, тестированием, рисованием презентаций, сидением в интернете и много чем еще. Все это может быть очень важным и нужным, но это не заменяет главного — написание нового кода и развитие продукта.

Я на домашнем нетбуке для управления всеми своими экспериментами, включая примеры для этих статей, использую Git. Под Ubuntu он легко ставится из репозитория и нужно лишь создать базу, выполнив одну команду. Приятно радует тот факт, что ему не требуется операция «взятие файла на редактирование» (check out). Можно не вспоминать о нем до момента вноса в базу сделанных изменений. В общем, рекомендую попробовать и попрактиковаться.

Автор: Softogen

Источник ^[3]