Тесты, ревью и флоу вокруг разработки

В одной из компаний, где я работал, была замечательная надпись на стене — «97 дней без багов». Это была одна из немногих компаний, где ревностно следили за чистотой кода, за процессом деплоя и флоу вокруг программирования, что позволяло выдавать стабильность работы всего портала. А портал был далеко не маленький.

Сейчас я опишу эти практики и, надеюсь, кто-то возьмёт их себе на вооружение.

Локальные тесты

Зачем писать тесты, когда тут очевидно всё работает? Важно — выдать скорость, потому что именно скорость видит тимлид, замечают менеджеры и начальство. Ты продуктивен, быстр и хорош собой. Глядишь, и повышение не за горами.

Вот ты написал очередной модуль. Потыкал запросы, посмотрел на ответы и с ухмылкой победителя отправил очередной PR (или, прости господи, сразу залил в прод). Через пару недель ты добавишь ещё одну сущность, напишешь к ней обвязку в виде репозиториев, хелперов и сервисов, потом пробросишь всё это в несколько старых классов, потыкаешь через Postman только что написанный модуль и закроешь очередную задачу в jira.

А через пару часов прибежит тестировщик, если такой имеется, и начнёт кричать что всё сломалось, ничего не работает и вообще. Открываем логи, а там много страшных стек-трейсов уровня 500+, пугающих ошибок и непонятных слов.

Ага, щас решим. Shift + Shift, название файла, Ctrl + G, номер строки. А что тут у нас? А тут у нас не хватает аргумента у класса, в который недавно добавил ещё пару зависимостей, а о том, что он используется тут — забыл. Отгоняя паническую атаку и тестировщика от своего стола ты начинаешь решать ошибки: дописывать зависимости, настраивать связи и менять связные сущности, временами чувствуя на себе злой взгляд тимлида, который сидит через пару столов от тебя.

Все задачи, которые планировались на сегодня — пролетают мимо, потому что ты решаешь карточки с пометкой «СРОЧНО». Сейчас даже через Postman не всегда есть время тыкать, ты правишь баг и сразу пушишь изменения. Знакомая ситуация?

Лично у меня такая ситуация была, и была часто. Решилось это просто — сменой работы, получением пиздюлей от старших коллег и приучением писать тесты параллельно коду. Всегда, когда тебе будет казаться, что тесты — это потеря времени — вспоминай, что на самом деле это экономия времени, отсутствие нервов и чистый код. Несколько дней твоей работы, а в худшем случае и работы всего отдела, могут быть сэкономлены, если на каждый новый класс ты создашь test-метод, мокнешь всё, что глубже чем твоя проверка и удостоверишься, что основная логика выполняется.

Ревью

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

Алгоритм — простой. Создал задачу — создал одноимённую ветку, свичнулся в неё из develop, сделал задачу (не забыв написать тесты, само собой), создал pull-request в develop. Ссылочку на PR кинул в общий чат, с призывом посмотреть твой код.

Ещё круче, когда ревью проводят коллеги из соседних отделов, и когда их количество фиксировано. У нас было так — тебя должны проверить как минимум 2 бэкендера из соседних команд + пара человек из твоей команды. Потратив все нервы, узнав много нового про себя и свой код и с 5-ого раза собрав все апрувы, ты можешь более-менее быть уверенным, что твой код не содержит хотя бы очевидных багов.

Тесты на среде

Прошёл ревью? Собираешься залить в master? Ха.

На этой работе я понял и ощутил всю мощь таких ребят, как Dev-Ops’ы. Каждому из команды они сделали свой виртуальный сервер — небольшая среда, где было полностью настроено всё окружение под проект.

Зачем это нужно? Во-первых, у твоего виртуального сервера был свой домен. Ты писал проект, разворачивал его на среде, и мог скинуть ссылку тестировщику — без его апрува катить задачу дальше ты не мог.

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

И, немаловажный этап, — тесты. На среде, к твоим локальным тестам добавлялась часть интеграционных, которые можно было выполнить только в определённом окружении.

JIRA

Сейчас, как мне кажется, это самый удобный инструмент для трекинга задач и интеграции с процессом деплоя.

Никакие trello, доски в github или gitlab не дают такого простора, как jira.

У всех команд была особенная доска — Release Board — доска релизов. Когда ты понимал, что все тесты пройдены и пора катить в мастер — ты ставил задаче особенный статус — pre-release. Задача, силами скриптов от devops-отдела, улетала в первую колонку борды и запускался массив тестов.

Чем хороша jira — так это возможностью настраивать пайплайны и привязывать их к визуальному режиму — ты можешь просто двигать задачу руками по колонкам, а где-то на фоне будет происходить сборка, слияние и разворачивание твоего билда на проекте.

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

twitter — https://twitter.com/SeniorJun

подарить чашку кофе — https://www.patreon.com/junsenior

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *