🍀 Стоя в офисе у окна, я нервно сжимал кружку чая всё сильнее, не веря, что потеря исходного кода произошла по моей вине. Мне тогда исполнилось 24 года - я только что внедрил первую версию своего первого проекта, учился в аспирантуре и считал себя самым умным.
Господи, как же я тогда был глуп, неопытен и наивен... В результате, мой первый корпоративный проект на Delphi теперь пребывал сразу в трёх состояниях: "основной", "фича-бранч" и "архив с бэкапом".
Фича-бранч (Feature Branches) - это отдельные, короткоживущие ветки для разработки новой функциональности. Разработчик делает ответвление, пишет код, проверяет гипотезу, затем отказывается от него или "вливает" изменения в "главную ветку".
Как это и бывает в жизни, та неудача явилась важным уроком моей проф-пригодности в разработке программного кода.
Я бы может и не вспомнил её, если бы буквально только что не увидел, что на эти "грабли" наступил мой коллега. Историю о нём я поведаю вам в четвертой, заключительно части статьи.
Знаете, я перечитал предыдущие выпуски блога и понял почему забросил его более года назад: мне самому был скучно писать!
🔥 Сегодня я предлагаю вам рефакторинг моего стиля повествования и очень жду обратную связь.
Пожалуйста, честно напишите в комментариях: зашло вам или нет? И как, на ваш взгляд, я мог бы сделать свой блоггерский продукт лучше?
Заранее огромное вам спасибо!
Итак, сегодня поговорим о разумном обращении с исходным кодом... ☕️
02.03.2025, Воскресенье, 15:00. Рубрика: Будни сеньора. Время на чтение: 5 мин.
🔸Часть 1. Спор о потерях кода
На дворе стояло жаркое лето 2007 года, Git уже был изобретен Линусом Торвальдсом, но не был известен в России, а GitHub и вовсе существовал только в умах своего создателя Тома Престон-Вернера.
Ничего про это я не мог знать, поэтому тестировал новый функционал в копии проекта, тогда как баги и срочные доработки правил в основной копии. При этом я по вечерам делал бэкапы то одного, то другого, перебрасывая через почту и иногда дописывал проект на других компьютерах 🤖
Тщательнейшим образом я записывал и запоминал: где, что и зачем поправил? Не нужно быть гением, чтобы понять чем всё однажды фатально закончилось - я запутался.
Слово "копия" в данном случае - это красная нить повествования, тот звоночек, который должен вас насторожить в вашей собственной работе. Кстати, аналогичная проблема есть и с несколькими копиями списков дел и задач, но сегодня не об этом.
Это уже теперь я понимаю, что не должно быть никаких копий в плоскости разработки. Тогда как в понимании DevOps или админов конечно же нужно бэкапить данные, но разработчик не должен об этом думать.
Каждое моё тогдашнее решение, взятое по отдельности, казалось невинным и преисполненным заботой к своему детищу:
☠️ регулярное сохранение в отдельные архивы текущей версии;
☠️ работа над проектом не только с офисного компьютера (перебрасывание копии проекта через e-mail);
☠️ тестирование новых идей отдельно (с нежеланием сломать основной код);
Просидев два или три вечера до ночи, благодаря построчной (!) сверки кода и такой-то матери я восстановил исходный код проекта и впервые задумался как жить дальше.
Любопытно было то, что даже когда жизнь садит тебя в первый ряд и показывает шоу, то урок не сразу доходит. Нужно чтобы ты сам наступил на каждые грабли и лишь отметины на собственном лбу будут символами надежды, что ты усвоил урок.
О каком шоу я пишу? Буквально месяцем ранее в нашем отделе случилась довольно неприятная история, когда умный и усатый дядечка, преподаватель вуза, сотрудничающий с компанией по договору запорол исходный код своего проекта 🙀
Всегда очень надменно и лихо подкручивающий усы во время своих глубокомысленных рассуждений, он вдруг стал выглядеть как провинившийся ученик.
В тот день я был увлечен перепиской на сайте знакомств (24 года, гормоны, все дела) так что до меня не сразу дошло происходящее. И только когда обычно уравновешенный начальник отдела начал ругаться с преподом на повышенных тонах я прислушался и погрузился в контекст.
Оказалось, что дядечка совершил ровно то, что спустя месяц было уготовано и мне, только я об этом еще не знал. Он додумался скопировать проект, чтобы вносить правки в университете, а затем приходил отрабатывать часы по договору у нас в отделе и прилежно переносил все правки в "основную" копию проекта.
Процесс жонглирования копиями длился второй месяц и масштаб правок в обоих копиях был так велик, что проще было начать писать проект с нуля, копирую туда куски реализованного кода шаг за шагом, чем восстановить одну из друх копий без боязни потерять контроль над проектом.
Помню, мой начальник справедливо настаивал, что усач потерял исходный код в тот момент когда сделал копию, а тот в ответ всё повторял и повторял, что ничего ошибочного в ведении двух веток кода нет 🙈
Ха, ха и еще раз ха! Я сейчас вспоминаю и испытываю безудержное веселье. Господи, какой неразвитой еще была разработка ПО в те годы!
Мне потребовалось набрать 40+ лет жизни и 20+ лет опыта коммерческой разработки, чтобы теперь смеяться не останавливаясь - в том споре нечего было обсуждать. Был прав начальник - "отличающихся копий" (как бы противоречиво это не звучало) исходного кода быть не может.
Это как раз одна из тех мыслей, которыми я хочу делиться с вами в этой рубрике - научиться смотреть на мир через призму сеньора.
Поверьте наслово: вы рано илии поздно потеряете свой исходный код или хлебнете с ним лиха, пока будете нарекать копии "основными", "запасными", "тестовыми", "альтернативными", да хоть "любимыми".
Актуальный исходный код в каждый момент времени должен существовать в "единственном" экземпляре.
Достичь этого нам поможет система контроля версий и ничто другое.
🔸Часть 2. Публичный контроль кода
Как и подавляющее большинство современных программистов, мой путь в контроле над кодом лежал через три инструмента: VSS, SVN и наконец GIT. Это дорожная карта приключений, где мы неминуемо должны оказаться в финальной точке этого маршрута под названием GIT. Если вы оказались не там - желаю удачи!
В 2015 году, будучи уже в должности начальника отдела разработки я активно использовал VSS и вновь считал себя самым умным, пока однажды не испытал следующий болезненный разрыв шаблона мышления.
Мой подчиненный решил уволиться и я попросил передать исходный код его проекта. На что он дал Интернет-ссылку на Bitbucket 😵
Я молча принял её, чтобы не показаться некомпетентным. Но ни черта не понял и весь тот вечер изучал невиданный мной ранее инструмент 🤯
Не спрашивайте почему я не проконтролировал где именно хранится исходный код - тогда я еще не научился управлять сотрудниками, работал по 70 часов в неделю и едва всё успевал.
⁉️ Меня повергла в шок публичность. Идея, что исходный код можно выложить в Сеть на всеобщее обозрение коррелировала с идеей прийти на работу совершенно голым. Более того, в те годы считалось, что исходный код - это секретный секрет любой компании и он и данные в базе данных должны храниться физически (облачные сервисы и виртуализация серверов еще только стучалось в умы российских разработчиков).
На тот момент Bitbucket и GitHub имели примерно одинаковую популярность в России, оба имели в качестве ядра Git - революционный принцип, который перевернул мир управления исходным кодом, также как Linux когда-то изменил мир операционных систем (у этих проектов один автор).
К тому времени как я узнал про Гит, уже поутихли баталии дискуссий и он стал стандартом де-факто. Поэтому на каком бы ЯП не писал программист владеть пониманием git - стало безоговорочным требованием.
🔸Часть 3. Командная разработка
Надо отметить, что после перехода в 2017 году в другую компанию, где над флагманским продуктом работала команда из 30 программистов я быстро впитал командный дух VSS (у предыдущего работодателя каждый программист был закреплен за своим проектом).
Я писал бизнес-логику на SQL и законченными единицами моего труда являлись серверные хранимые процедуры. Их было довольно много, в том числе универсальных или пересекающиеся функционалом между задачами, поэтому нередки были случаи, когда ты получал наследие от одного человека, трудился над улучшениями неделю-другую, а затем передавал знамя следующему разработчику.
В таком режиме особенно хорошо проявлялся принцип check-in/check-out, когда ты как бы бронировал эксклюзивную работу над исходным кодом процедуры для себя, тем самым "лочил" её для всех других.
Это позволяло избегать конфликтов в правках, правда давало основание поймать тебя в столовой или у кофе-машины и отчитать, что долго держишь файл.
Клиентские коллеги использовали SVN и гордо бросались понятиями бранч и транк (основная ветка, через которую пойдет выставление), но я то видел, что там тоже часто возникали склоки и разборки, когда один разработчик вливал в trunk не осознавая, что там есть изменения другого и это обнаруживалось только при "деплое".
Чувствовалось, что обе замечательные системы VSS и SVN содержали какой-то общий дефект логики, который не позволял без трудностей и конфликтов пользоваться контролем кода.
Так было до мая 2021, пока мы не перешли на GIT и реальность изменилась на "до" и "после".
🔸Часть 4. Мультивселенная исходного кода
Теперь каждый из нас мог плодить сколько угодно веток разработки - тестируя гипотезы, переключаясь между задачами, исправляя один и тот файл в рамках нескольких задач. Одновременно существует бесчисленное множество единственной версии репозитория актуальной для этого проекта!
Когда смысл в отдельно взятой ветке отпадает и она должна раствориться в другой, то происходит "слияние" (сожалею, но коротко и легко описать нюансы этого процесса я сходу не смогу).
Идея безумно проста, красива, но требуется сменить мышление, чтобы принять её.
Так вот, недавно я наблюдал показательную ситуацию, когда один уже довольно опытный программист решил изменить концепции Гит - схитрить, выложить дорогу в Ад своими благими намерениями.
И "Ад" в данном случае не метафора, а эмоциональное состояние сотрудника, который загоняет себя в многоверсионность кода.
На платных курсах успешного программирования об этом не рассказывают, правда? 😈
Любопытно напомнить, что схожая (хотя и не равнозначная) проблема с много версионностью существует и не только среди прикладных разработчиков, но и системных разработчиков и администраторов.
DLL hell (DLL-ад) - тупиковая ситуация, связанная с управлением динамическими библиотеками DLL в операционной системе MS Windows. Аналогичная проблема в других ОС носит название "ад зависимостей".
Сущность проблемы заключается в конфликте версий DLL, призванных поддерживать определённые функции.
Ад зависимостей - антипаттерн управления конфигурацией, разрастание графа взаимных зависимостей программных продуктов и библиотек. В сложных случаях различные установленные программные продукты требуют наличия разных версий одной и той же библиотеки.
Святой GIT решает буквально адскую проблему!
Человек, о котором я пишу, для обхода общепринятой в компании парадигме выставления кода решил выставлять "bug fix" и небольшие изменения... прямо в prod минуя git. Сначала это было одно изменение. Ведь никому плохо от этого не стало, правда?
Да, не стало.
Потом еще один и еще. Он всё фиксировал и помнил что где и по какой задаче "залито" и "выставлено" (глаголы, которые в РФ реально чаще всего применяют для описания процесса транспортировки кода на целевой сервер, а вовсе не модное, якобы жаргонное "деплоить").
Потом был больничный, новые проекты, отпуск и новый год, да много чего еще...
По мере прочтения моей статьи вы тоже могли уже изменить мышление и предвосхитить, что же произошло дальше.
Однажды он запутался.
И в какой момент он потерял исходный код?
⚠️ Правильно, в тот самый момент, когда своим решением создал две копии кода - один на проде сервера, второй в git-репозитории.
И вот вдруг выяснилось, что наступил его личный ад, а заодно и у всей компании - один и тот же кусок кода (считайте - "модуль" или "хранимая процедура", что ближе к истине, поскольку речь идет о серверном коде для СУБД) вдруг должен одномоментно быть в нескольких вариациях для разных сервисов и функциональности, которая его использует.
Подобные нестыковки - вполне рутинная рабочая задача под названием "слияние" (merge - сличение, аудит, автоматическое объединение). Но только если это делает автомат, инструмент, а не человек.
Невозможно при нагрузке в 200+ методов в год удержать в голове какая правка для чего и в какой момент требовалась.
Итогом явилось расследование и "охота на ведьм", teamlead-ы и руководители департаментов занялись обнаружением масштаба проблемы, устранением и выявление всех, кто действует во благо, а также активизация работы по построению единого pipeline в контроле над кодом.
Как я и сказал в начале статьи - провал это всегда точка роста для личности или компании.
Главное - сделать правильные выводы.
🍏 Меня зовут Андрей, я Senior SQL Developer и уже более 20 лет смотрю на мир через призму SQL-запросов.
Мира и добра Вам! Поддержите, пожалуйста, статью лайком и комментарием.
До встречи в следующем выпуске!
Выпуск №17, Санкт-Петербург, дата написания 01.03.2025