четверг, 30 июня 2022 г.

Бездна отчаяния многих фич

Если бы я сел писать книгу про программирование в эпоху постмодернизма, она бы назывлась "Как Писать Хороший Код, Даже Если Твои Менеджеры Мудаки". И глава первая называлась бы "Бездна отчаяния многих фич".

В общем, представим себе, что есть команда программистов из N человек, где N - натуральное число. К ним приходит менеджер проектов и говорит "я хочу фичу А в проекте Ы". Если проект Ы недоразвитый, то программисты делают фичу А, редактируя файлы и отлаживаясь прямо на сервере, который у них единственный. Но обычно должна быть система контроля версий, в идеале - с удобными веточками, как git. Если N мало, а проект Ы маленький, то программисты фигарят все изменения, после отладки и тестирования на локальных компах, прямо в мастер. И деплоят. Потом идут показывать менеджеру проектов: вот, мы сделали!

Бывает так, что менеджер проектов (или кто угодно, кто отвечает за качество проекта) не хочет тестировать то, что там прошграммисты налепили, прямо на продакшене, и тогда заводится отдельный серверочек для тестирования. И это - первый шаг к бездне отчаяния многих фич.

Менеджер проектов просит несколько разных фич, программисты их делают, лепят изменения в мастер, выкатывают на тестовый сервер. Менеджер смотрит, говорит, мол, хорошо, фичу А выкладываем на продакшен, фичу Б дорабатываем. Программисты рвут на себе волосы и быстро придумывают новую схему:
- есть отдельная ветка, например, "стейдж" для тестового сервера
- и отдельная ветка, например "стейбл" для продакшена
Программисты ответвляют себе веточку от текущей последней ревизии стейбла, делают там какую-то фичу, мерджат в стейдж. Когда задача проверена, ту же веточку мерджат в стейбл. Данный подход хорош тем, что можно в разное время разные независимые фичи выкладывать в продакшен независимо друг от друга. Если они там затрагивают одно и то же место, то конфликт разбирается на стейдже ещё до того, как попадёт в продакшен. Минусы данного подхода тем существеннее, чем дольше идёт тестирование задач. В конце концов может оказаться такая ситуация, то веточка, ответвлённая от последней ревизии стейбла, уже не смерджится в стейдж нормально, потому что там уже очень всего наворотили. Такая ситуация кажется нереальной? Ваш покорный слуга с таким сталкивался. Не надо недооценивать жестокую реальность. А ещё кто-то чинил аврал и херачил коммиты прямо в стейбл, только потом поленился их забрать в стейдж, в котором зато кто-то другой нахерачил других коммитов, которые, явно, в стейбл уже не попадут.

Программисты рвут на себе волосы и делают навороченную систему, как это сейчас можно говорить, непрерывной интеграции.
Есть одна главная ветка, пусть называется "мастер". Программист, когда хочет разработать новую фичу, ответвляет себе веточку от последней ревизии мастера, делает там что-то своё... и никуда ничего не мерджит. После пуша в эту ветку умная система (гитлаб или дженкинс) берёт, разворачивает новый виртуальный хост, куда выкладывает изменения из этой ветки. Получается, что на каждую фичу есть свой отдельный тестовый сервер типа feature_a.my_project.dev.company.org, и эти изменения попадают обратно в мастер, только когда их аппрувят. Минус этой системы очевиден - эта система сложна для поддержки и понимания, поэтому некоторые... ох, как бы пополиткорректнее выразиться? Аутсорсеры из одной далёкой страны, когда что-то ломается в системе этой автоматической выкладки, не всегда в состоянии всё починить за адекватное время. Ещё один минус - менеджеры не видят то, как между собой взаимодействуют задачи. Если сто менеджеров попросят каждый по одной кнопке, то в ста разных тестовых ветках будет по одной аккуратной кнопке, зато, когда всё соберётся в мастер, там будет месиво.

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

Однако, даже такой вариант не является полностью мудакозащищённым. Если задача очень долго тестируется, код в отдельной ветке может оказаться настолько отставшим от мастера, что потом придётся всё переделывать. Если программист не очень хорошо понимает, что куда откуда ветвится в системе контроля версий, и как это вообще работает (такие программисты с SVN-основанным сознанием обычно не признают теорию множественности миров Эверетта и не могут находить парадоксы и дебильные несостыковки сюжета в фильмах про путешествия во времени), он может случайно напутать и поломать. Вышеупомянутые лентяи из одной далёкой страны вообще не парятся ни о чём, и будут херачить всё в мастер, а если у них нет права на коммит в мастер, они сделают себе ветку с названием типа india_dev, и будут все хором коммитить туда вообще всё, потому что им так типа удобно.

А у простого сеньёр-софтваре-инженера нет прав на то, чтоб пиздить людей по голове линейкой. Более того, если он будет сопротивляться, отказываться принимать говнокод и требовать, чтоб все всё делали как надо, в те моменты, когда менеджерам что-то всралось, и они кричат, что всё надо сделать как можно скорее, то он получит по голове линейкой от менеджерья сам. Просто бездна отчаяния.

Комментариев нет:

Отправить комментарий

Ублюдочный Гугл поломал форму комментариев. Извините.

Примечание. Отправлять комментарии могут только участники этого блога.