Site icon AppTractor

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exit mobile version