Григорий Петров: VCS — они как бэкапы

Сейчас трудно найти разработчика, который бы не использовал Git, SVN или другую штуку для управления исходным кодом. Но если спросить разработчика «а зачем ты ими пользуешься?», то большинство ответов, если убрать словесную шелуху, сведутся к «чтобы исходники не потерялись». И VCS действительно хорошо справляются с этой задачей: доведенный до автоматизма push в GitHub или GitLab надежно защищает многолетние труды от сгоревшего жёсткого диска или нечаянно удаленной функциональности. Ну, или почти надежно, если вспомнить недавний инцидент с GitLab. Хотя исходники у них все же выжили.

Но VCS — они не только об этом. Скажу больше — они совсем не об этом. Если бы единственной задачей было «не потерять исходный код и иметь возможность вернуться к старым версиям», то такое можно сделать намного проще, сохраняя все в фоновом режиме и не отвлекая разработчика на все эти коммиты и пуши. Хранение кода — простой и понятный побочный эффект, который многие знакомые мне программисты считают самой главной штукой в VCS. Сетуют, что push/pull надо делать вручную и пишут сообщения к коммитам «111».

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

Страшная сказка из жизни программистов

Назначение VCS легко проиллюстрировать на примере. Представьте себе крупную компанию, много лет успешно разрабатывающую программный продукт. Неважно какой. И вот, в один прекрасный момент, разработка стопорится о непонятный фрагмент кода, который явно что-то осмысленное делает, но совершенно непонятно зачем он это делает и как делаемое дальше поддерживать. Помедитировав пару дней над кодом, и не разобравшись в сотне мегабайтов исходников, команда неожиданно вспоминает, что у них же есть VCS! А в VCS есть такая замечательная штука как Blame, показывающая кто и когда менял каждую строчку любого исходного файла.

И вот тим лид торжественно запускает блейм, команда задерживает дыхание и их взору открывается коммит. Коммитище. Большой. Очень большой. В несколько десятков тысяч строк кода, затрагивающий разные части программы и явно что-то очень важное и нужное в нее добавляющий. А самое страшное в этом коммите будет связанное с ним сообщение. Это будет строчка «111» или «feature». Такая же, как у нескольких десятков коммитов до и после этого.

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

Дорогой дневник, хочу рассказать тебе о фиче…

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

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

Как раскладывать сложность: делай раз

Как я уже писал, сложность пропорциональна количеству информации в проекте. А распределять информацию удобно вот в такой последовательности:

• Имена в коде. Если можно вынести сложность в осмысленные имена переменных, функций и модулей, понятно разбить код на части, чтобы он хорошо читался — то это лучший вариант.
• Если в коде не получилось, то следующий по привлекательности вариант — это, как раз, коммиты. Хороший коммит содержит одно логическое изменение, а сообщение к коммиту отвечает на вопрос «зачем». А не на вопрос «что», как это любят делать. На вопрос «что» отвечает diff коммита. Также очень круто, если сообщение к коммиту ссылается на тикет в системе управления задачами.
• Если информацию не получилось добавить в коммит, то все плохо. Следующая надежда — это система управления задачами. Тикет, в котором подробно описано, что и зачем делалось. С комментариями, связанными тикетами и прочей информацией, которая в будущем может спасти разработчиков. И ссылка на этот тикет в сообщении коммита.
• С этого момента начинаются боль и страдание. Если на вопрос «зачем» не может ответить ни код, ни коммит, ни тикет – значит, происходит что-то очень странное и непонятное. Стоит приложить все усилия, чтобы это отметить и не получить через пару лет мину замедленного действия. Первое, куда стоит попробовать переложить информацию — это статья в системе управления знаниями. Раньше для этого мы использовали MediaWiki и Confluence, но сейчас, когда VCS обзавелись удобным графическим интерфейсом на стороне сервера, все большую популярность получают Markdown файлы. Которые, что удобно, лежат рядом с кодом и меняются в тех же коммитах.
• Если в статью информация тоже не влезает, то последнее, что можно сделать — написать комментарий в коде. Относительно комментариев есть два сильно отличающихся мнения. Многие разработчики считают, что информацию стоит помещать в комментарии не в последнюю очередь, а сразу, если не получилось поместить в сам код. Я же считаю, что минусов у такого подхода больше, чем плюсов, так что за исключением специфических случаев, вроде автоматизированного документирования API, лучше вначале попробовать сообщения к коммитам. И научить, наконец, команду пользоваться Blame при ответе на вопрос «зачем это здесь».
• Отдельным пунктом идут фреймворки и Continuous Integration. С фреймворком все понятно, мы помещаем в него сложность на этапе выбора. А вот Continuous Integration в последнее время интегрируется с VCS так же, как и системы управления знаниями. Конфигурация сборки проекта и его развертывания сейчас лежит рядом с исходным кодом, меняется теми же коммитами и доступна для манипуляций через удобный веб-интерфейс VCS. Информация о том, как собирать, тестировать и развертывать проект естественным образом перемещается в эти файлы, сами файлы упоминаются в README.md — и проект готов к встрече с автором через полгода. Когда автор сам забудет, что писал.

И это далеко не все

Современные VCS, а точнее веб-интерфейсы к ним, позволяют выжать максимум пользы от помещенной в коммиты информации. Это уже упомянутые системы управления знаниями в виде Markdown файлов, и Code Review в виде Pull Requests, и Continuous Integration, и многое другое. Освоение всего этого инструментария — дело долгое и, местами, контринтуитивное. Но оно того стоит!