Emo Coder

Разные сервисы в пайплайне (или как это назвать?) от постановки задачи до деплоя оперируют разными понятиями, и это невероятно бесит. Например, задача создаётся в Jira, код коммитится в GitLab, тесты гоняются в Jenkins. В итоге у нас есть как минимум три разных сущности: задача, код, результат тестов.

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

Код
Как минимум, у нас есть три сущности: ветка в гите, мерж-реквест в Гитлабе и пайплайн со ссылкамии на Дженкинс. Нахрена мне всё это? Навигация в том же самом Гитлабе вообще сделана через жопу, потому что переходишь ты от пайплайна к ветке, а в мержреквест уже нельзя. Да и как инструмент код-ревью он тоже местами так себе: "This diff is collapsed. Click to expand it." Нормально вообще? Пришёл код смотреть, а тебе ещё и развернуть всё надо.

Тесты
Тесты запускаются на Дженкинсе. Для каждого запуска есть отдельная джоба, все джобы хранятся в одном пуле без разделения по юзерам и уж тем более по тикетам. А если что-то упало в процессе сборки, то знаете, почему будет провален запуск тестов в Дженкинсе? Потому что не удалось опубликовать отчёт по тестам! И иди потом ищи в логах, что и где упало.

И чо
Мне как разработчику все эти сущности вообще не всрались. В идеале у меня должно быть описание задачи, тут же лежит код-ревью со всеми комментами, результаты запуска тестов, кнопки, чтобы всё это говно перезапустить, если надо. Переходишь в какой-нибудь там условный Дженкинс, а у тебя список из тикетов, которые ты делал, результаты тестов по каждому, и все зелёные.

Всё равно не звучит, как упрощение, но тут они хотя всё собрано в кучу. Между всеми штуками есть ссылки, тебе не надо возвращаться в описание тикета, чтобы из тестов попасть в код.

Кажется, что решения от одного вендора вроде Atlassian должны избавлять от такого количества сущностей. Но есть проблемка: вы видели хоть одну команду или компанию, где вся эта инфраструктура была построена на стеке одного производителя? Вот и я не видел. Всегда встречаются купленные сервисы вместе с опенсорсными поделками, которые специально обученная служба поддержки пытается подружить между собой. Почему так? Хуй его знает, экономят, наверное.

Как я это вижу
Я не хочу ничего решать, я хочу оперировать только одной сущностью.
Я хочу нажать кнопочку «В разработку» в трекере задач, а дальше магия:
1. Положить в стеш все текущие изменения
2. Создать ветку под задачу и залить в неё последний мастер (а если работаешь над задачей больше одного дня, то ещё и подливать туда мастер по утрам)
3. Заново налить БД, если в прошлой задаче были миграции (а лучше просто заново налить БД)
4. Поднять всю инфраструктуру для проекта и залогинить меня
5. Вообще топ это заодно ещё создать новые ручки API, вытянув инфу из нужных полей задачи, или запилить контейнер для нового (микро)сервиса

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

Дальше начинается самое интересное:
1. Пофиксить мерж-конфликты.
2. PUSH DENIED, потому что ты забыл поставить двоеточие после номера тикета.
3. Перезапустить тесты.
4. Обнаружить, что тебя опять разлогинило в дженкинсе (в гитлабе кнопку перезапуска ещё не приделали).
5. В очередной раз сбросить доменный пароль, потому что кто ж его помнит-то.
6. В дженкинсе используется ЕЩЁ ОДИН пароль.
7. Поправить опечатку после код-ревью.
8. Повторить ещё раз.

У нас есть обёртка над docker-compose, название которой заканчивается на e, у этой обёртки есть команда bash. Каждый раз, когда я пытаюсь зайти в какой-то контейнер, а блядская клавиатура-бабочка на макбуке срабатывает лишний раз, у меня получается что-то типа docker-compose ebash, и я думаю, что ещё не все технологии проёбаны, можно работать дальше.

Бесит, когда одно и то же называют разными именами в разных местах.

response.status? Или, может response.status_code? А response.http_status не хочешь?

Ах, это прекрасное чувство, когда ты находишь заёбистый баг, который тебе мешает закрыть тикет. Ковыряешься с ним целый день, описываешь шаги воспроизведения, пинаешь коллег. Кто-то из них тебе рассказывает, что на улучшение этого куска проекта уже есть тикет, а ты радостный бежишь описывать всё это говно туда. Ура, спихнул баг на коллег! Ты радуешься даже больше, чем от закрытия своей задачи, потому что этот баг фиксить долго и нудно.

Через неделю та самая соседняя задача прилетает тебе ¯\_(ツ)_/¯

«Ухудшающий эксперимент»

Плачу, вместе с тем пишу документацию в reStructuredText. Там можно пометить текст как (под)заголовок с помощью «подчёркивания»:

Headline
########

Причём, что очень важно, количество подчёркивающих символов должно совпадать с количеством символов в строке выше. Например, вот на такой код парсер выдаст ошибку:

Headline
#####

Title underline too short.

То есть, если у меня супер-длинный в штан^W^W заголовок, то я должен запилить длиннющую строку с решётками или другими символами заголовка:

Replicated Data Consistency Explained Through Baseball
######################################################

Ну как так-то, а? Хотя ладно, есть и плюсы, например, эта хрень вроде не так уж плохо смотрится даже без рендера, сразу понятно, где тут заголовки.

— Надо приделать вот такие вот штуки, там всего одна новая моделька.
— ОК, админку под них делать? Как создавать будете?
— Да забей, руками через базу сделаем.
— А документацию надо?
— Да забей, пока в публичный доступ не выкатываем.

Через два месяца:
— Слушай, нам админка нужна.
— okay.jpg
— И не забудь про документацию!
— Ну бля :(

Наконец-то понял главное правило код-ревью, если пишешь на языке с динамической типизацией, на Питоне, например, или ещё каком Луа. Странно, что этого не произошло раньше, но лучше сейчас, чем никогда.

Во время ревью обращай внимание на изменения сигнатур функций. Недавно у нас чуть всё не взорвалось, потому что одна там функция стала возвращать кортеж (как это по-русски?) из двух списков вместо одного списка. Конечно, код, который это использует, не поменялся. Тесты были зелёными, потому что эта часть проекта замокана с ног до головы, и это довольно сложно покрыть на 100%.

Деплой нового кода у нас обычно проходит легко и без вмешательства разработчиков, но для особо заёбистых задач есть специальный тег «не катить в пятницу». Очевидно, что он запрещает катить в пятницу. Кроме того, он запрещает катить задачу, если исполнителя нет на рабочем месте, чтобы успеть быстро потушить пожар, если всё внезапно распидорасит.

#процессыёпта

Делаешь ручку (да, вы всё правильно поняли) апи, тестируешь на локалхосте, на стейджинге, всё ОК. Ручка-то простейшая — взять данные из таблицы и отдать в джсоне. Отдаёшь на ревью, там тоже всё в порядке. Тестирование тоже на ура проходит.

После деплоя, через N дней, когда нашёлся единственный человек с нужным правом, прилетает ошибка: «SELECT command denied to username»