Привет, Хабр! Когда разработчик — это только код? А когда — полный хаос, в котором виноваты дизайнеры, DevOps, тестировщики, кто угодно, но не он? Меня зовут Дарья Корчуганова и я — руководитель команды разработки в Газпромбанк.Тех, IT_ONE. В этой статье на основе моего доклада для FrontendConf поделюсь опытом и размышлениями о том, что и почему должен делать разработчик. Разберём, как избежать фейлов и сэкономить нервы.
Как появилась идея статьи
Кажется, что работа разработчика проста: пиши код, заливай, жди аппрува. Но потом начинается... Задачу забрал другой? Код не попал на стенд? Билд сломался? Кто виноват? Возможно, вам знакомы фразы: «мой код работает, проблема в других», или «пусть тимлид следит за статусом задач», или «тестировать — задача тестеров, я не буду проверять работу кода на стенде», или даже «не собрался билд — это проблемы DevOps», «полетела вёрстка — виноваты дизайнеры».
Их я слышала и от друзей-разработчиков, и от коллег на прошлых проектах, и в кулуарах конференций. Все эти фразы можно свести к одной: «я — разработчик, я должен писать только код». Обычно так говорят выгоревшие разработчики. Это уставшие специалисты, которым либо надоело работать вообще, либо работать по этой специальности, либо у них пропал запал и дух авантюризма. Причин для этого может быть много:
Действительно большая нагрузка.
Непрозрачные процессы в команде.
Физическая / эмоциональная усталость.
«Все от меня чего-то хотят, постоянно дёргают, а я не хочу ничего решать, пожалуйста, дайте мне просто спокойно писать код».
И действительно, когда тебя постоянно отвлекают от написания кода и решения задач, ты каждый раз вынужден заново погружаться и настраиваться. И корень зла здесь один — невнятные, непонятные процессы в команде или компании. Такое случается по многим причинам, например, ошибка тимлида, который не донёс, как и что можно сделать удобнее. А ещё часто процессы нам спускают сверху, и мы не в силах их изменить. Да, мы не можем изменить процесс в корне, но у нас есть возможность добавить/изменить подход к некоторым шагам разработки, что может существенно облегчить жизнь.
Definition of Done (DOD)
Многие в своей работе используют Definition of Done (DOD) — критерий готовности задачи. Причём каждая компания, команда или проект могут выделить свой. Если примитивно – это будет определённый чек-лист. Задача должна этот чеклист пройти, чтобы мы могли выкатить её на продакшен конечным пользователям.
Критерий DOD предлагаю в этой статье разделить на командный и личный. Хотя сам DOD чаще всего на команду единый, но каждый участник команды разработки может сделать собственный DOD. По сути, это будет командный DOD + личные критерии. Чек-лист командного Definition of Done в целом примерно такой:
согласованная аналитика;
согласованные макеты;
груминг и нарезка на задачи;
задача реализована в коде;
код протестирован;
закрыты все замечания от высшего приоритета (high, blocker, critical), и так далее, в зависимости от статусной модели.
Личный Definition of Done — это командный чек-лист плюс личные критерии к коду. То есть ваше отношение к тому, как писать код, можно внести в личный Definition of Done.
4 вида DOD
Рассмотрим четырёх Мистеров Исключительных — обобщённые образы разработчика, каждый из которых ведёт процессы по-своему.
Все кейсы будем оценивать в разрезе одного дня.
Для каждого случая мы будем примерно измерять: сколько человек огорчили — каков накал страстей и масштаб трагедии. Единица измерения — гневные огонёчки.
Ещё будем считать время на задачу. Некоторые из приведённых ниже дискуссий могут занять как 10-15 минут, так и целый час, поэтому я буду использовать среднюю оценку.
DOD Basic Edition. Ад для команды, но рай для разработчика
Представим, что мы в начале спринта: только что завершили релиз и должны выбрать новую задачу. Проснулись, пообщались на дейли, услышали от лида приоритеты по задачам, поняли, что от нас требуется, немного подумали, попили кофе, чтобы настроиться, и переходим к решению задачи.
Дальше процесс в Basic Edition выглядит примерно так.
Заходим на доску с тасками, создаём ветку в Git, неистово пишем код, выкатываем pull request либо merge request — зависит от того, как команда его называет. Опять переходим на доску с тасками, завершая это колесо Сансары.
Мы не видим никаких подвохов, но что-то всегда может пойти не так. К счастью (или к сожалению), все мы — часть команды, и наш код напрямую влияет на то, как она работает.
Что мы сделали неправильно — не назначили себе задачу. В результате к нам приходит коллега, который тоже её увидел, облюбовал и… реализовал в коде. И когда вы залили своё решение и столкнулись с конфликтом. Ведь, как известно, два разработчика могут по-разному решить одну и ту же задачу. И вот наша задача решена дважды! Начинается война: чьё решение выкатить.
Скорее всего, разборки, чьё решение лучше, займут не менее 30 минут. Но ведь разработчики самостоятельно редко приходят к единому мнению. После долгих споров они призовут в качестве арбитра либо техлида, либо тимлида, либо их обоих. На это уйдёт ещё примерно час. Далее каждый будет защищать своё решение. Тимлид и техлид внесут свои корректировки. В итоге мы придём к какому-то решению только через полтора часа. При этом все останутся недовольны.
Но это ещё не всё: мы не перевели статус задачи в нужный после того, как залили решение. Потому в QA просят дать код, чтобы прогнать по нему тесты. Ещё тридцать минут мы рассказываем тестировщику, что всё сделано, отвечаем на уточняющие вопросы. Получаем ещё одного недовольного тестировщика — ещё один огонёчек. Тестировщик уходит.
Тестировщик возвращается и говорит, что на стенде задачи нет. Вы, конечно, всё залили, но на стенде её и правда нет. Где-то 30 минут мы пытаемся доказать тестировщику, что задача сделана, вот код, вот pull request, мы его залили, всё здорово, пусть ищет на стенде. Он не находит. После диагностики проблемы понимаем, что билд не собрался и задача не задеплоилась на стенд. И у нас ушло полчаса на диагностику, чтобы это понять. А ещё понадобится время на починку билда. Возвращаемся к тестировщику, и у нас ещё плюс один огонёчек. Приятного мало: новая задача уже висит в очереди, а мы всё ещё пытаемся решить, что делать со старой, и даже не перешли к тестированию.
На тестировании ловим невероятно много багов, потому что не проверили код локально. Опять все недовольны? Поставим ещё один огонёчек!
Итог. За один день мы потратили три часа рабочего времени на разговоры и выяснения: чья задача, какое решение принимаем, какие баги поймали и что вообще происходит. Вы думаете, что сделали всё правильно, но вокруг хаос.
Потрачено: три часа, шесть гневных огоньков и доверие команды.
DOD Standart Edition. Компромисс между контролем и хаосом
Рассмотрим следующего Мистера Исключительного, попытаемся исправить предыдущие ошибки и посмотрим, что получилось и стоит ли вообще иначе относиться к процессу.
Мы опять создаём ветку в Jira. Уже на этом этапе можем использовать GitFlow, чтобы как-то её назвать. В документации GitFlow приводится стандартный пример разделения на фичи и фиксы:
feat/TASK–1234–add–blue–button
fix/TASK–1235–change–button–color
Этим простым манёвром получаем порядок в Git, даже если не удалили ветки после мержа pull request. Дальше снова неистово пишем код и немножечко тестируем.
Важно, что на этом этапе не предусмотрена проверка автотестами, потому что это долго и дорого. Чаще всего долгие и дорогостоящие проблемы появляются либо в legacy, либо в очень старых проектах, которые только собираются переписать или просто поддерживают. Покрывать их тестами или невыгодно, или просто нет времени и ресурса.
Но есть отличный выход. В одной из компаний мы использовали приёмочные тест-кейсы. Вы можете наладить контакт с тестировщиками и попросить их сделать это. А можете написать самостоятельно. Какой вариант бы вы не выбрали, тест-кейс — самый логичный, глупый алгоритм, который должна выполнить кнопка на странице при нажатии — стандартная процедура. Поверьте, множество глупых ошибок вы сможете отловить и исключить именно благодаря банальному тест-кейсу.
Дальше выкатываем PR/MR и через TeamCity собираем и выкатываем на стенд. Вместо TeamCity это может быть любой другой аналогичный инструмент. Проверяем, что собрался билд. После этого в Jira меняем статус на «готово» — переводим задачу в статус тестирования.
К сожалению, здесь тоже многое может пойти не так. Как минимум, может попасться коллега из предыдущего кейса, который не взял задачу в работу на доске, но выполнил её параллельно и теперь предлагает выяснить, чьё решение лучше. Мы можем от этого уйти, выстраивая процессы, но это не быстро. Поэтому ставим полтора часа и три недовольных огонёчка – за двух разработчиков и тимлида.
Дальше тоже не всё гладко: может прийти бизнес и сказать, что теперь на каждое действие уходит больше времени. Раньше разработчик всё время писал код, а сейчас и в TeamCity лезет, и какие-то тесты проверяет — в общем, происходит что-то не то. Хотя это отчасти справедливое замечание, аргументировать свою позицию можно тем, что в итоге получаем менее забагованную версию фичи и сокращаем количество ошибок. А это уже можно продать.
Итог. Мы сократили количество негативных моментов на час и собрали три огонёчка вместо шести.
Потрачено: два часа на задачу за рабочий день и три огонька.
Уже неплохо. Но есть ещё Premium Edition.
DOD Premium Edition. Продвинутая версия
В Premium тоже начинаем с Jira, берём задачу, меняем её статус и закрепляем за собой. В Git также пользуемся GitFlow, но с немного другим именованием веток — feat/TASK, номер таски и её краткое описание:
feat–TASK–1234
fix–TASK–1235
Таким образом, даже если сотрудник не переведёт на себя задачу или два сотрудника возьмут одну и ту же при создании ветки Bitbucket не даст создать дубль.
Дальше мы снова неистово пишем код. Можно прикрутить автотесты ПО, либо покрыть код тестами. Да, это долго и дорого, но мне кажется, это уже must have, защищающий от многих проблем. Покрытие кода тестами в таких кейсах обычно заложено в проект.
Дальше выкатываем PR, но во время выкатки запускаем SonarQube, чтобы проверить качество кода. У нас в Bitbucket панель выглядит примерно так – я заменила номер задачи, чтобы вы не знали, как они у нас называются:
Проверка с SonarQube — Sonar quality gets passed. Так Sonar убеждается, что нет дубликатов функций, и два разработчика не написали одну функцию в разных местах, а ещё, что нет глобальных переменных и безопасность кода соблюдена.
Этот инструмент серьёзно помогает, в коде не накапливается ненужного мусора, из-за которого потом приходится устраивать глобальный рефакторинг. SonarQube уже на моменте выкатки Pull Request говорит, что нужно отрефакторить, если возникли вопросы к качеству кода или обнаружены дубли. В условиях микрофронтенда, как у нас, это замечательное подспорье.
Дальше переходим в TeamCity и возвращаемся обратно к той же плашке. Это статус pre-build — когда при публикации PR в TeamCity он билдится с веткой, разлитой на стенде. В зависимости от текущего состояния релизной недели это может быть develop или release. Если в этом случае не пройдёт Sonar и pre-build нашего PR, то мы их не сольём никогда в жизни. Это надо исправлять. На этом моменте мы отлавливаем очень много инфраструктурных проблем, которые всё равно позже пришлось бы рефакторить.
После к нам может прийти служба безопасности по поводу небезопасных или ненужных версий библиотек. Все, кто работает в финтехе, знают, что СБ работает чётко, быстро и порой больно. В этом есть и плюсы, ведь она оберегает проект от утечки данных пользователей, за которые мы отвечаем. Как говорится, большая власть — большая ответственность!
После того как все требования PR/MR были выполнены, возвращаемся в Jira, меняем статус на «готово» и запускаем тестирование. И здесь пойти не так может немногое — например, увеличатся затраты на обучение и онбординг сотрудников. Собеседуя сотрудников мы в команде нашего проекта в Газпромбанк.Тех, конечно, смотрим на знания и умения работать с Sonar и TeamCity. Если вы работаете с TeamCity, то сюда же привязываются и навыки во FrontOps, в том числе, то есть работа с DevOps и тестировщиками. И код вновь занимает не главную часть. Мы не можем вычислить количество времени на решение проблемы, потому что как бы мы не улучшали процесс онбординга, в каждой компании он будет разный даже при прочих равных наборах стека и инструментов.
Итог. К сожалению, тут тоже будет огонёчек. Ведь человек, занимающийся онбордингом сотрудников, вряд ли будет очень рад тому, что ему постоянно приходится перестраивать процесс, обучать сотрудников, в том числе, непростым инструментам.
Потрачено: примерно бесконечность времени и один огонёк от недовольного сотрудника.
Хотя недовольных сотрудников может быть и очень много, всё зависит от компании и её масштабов. Например, у нас есть 17 команд. Каждая занимается определённым количеством микросервисов. Если в рамках одной команды у нас один недовольный огонёчек, и то на компанию их получится 17.
DOD Ultimate Edition — делегируй, властвуй, управляй!
Последний вид Definition of Done — это стать тимлидом и переложить весь процесс на других людей.
Руководство командой даёт некоторую власть — вы можете сами согласовывать процесс и на этапе внедрения проекта обязать всех участников придерживаться заданного алгоритма.
Процесс из DOD Standart Edition можно внедрить не только на старте проекта. Сначала можно привести в порядок нейминг веток и продумать план, углубившись в аналитику. А ещё можете запросить доступ в TeamCity, чтобы посмотреть немного шире простого написания кода и передачи его на тестирование.
В Premium Edition мы уже должны согласовать свои планы с другими. Также вы едва ли самостоятельно, без согласования с руководством, подключите к проекту Sonar. Вы должны аргументировать это техническое решение, чтобы затащить его в проект.
Но если вы придёте к своему руководителю и расскажете о проблемах с рефакторингом, то не обязательно сразу же привязывать Bitbucket к Pull Request. Можно начать с того, что на этапе pre build локально проводить Sonar по вашему коду. Это поможет вам убедиться, что вы написали всё верно. Так вы будете подчищать сомнительные моменты, и это уже будет успех.
Работать с TeamCity разработчиков придётся обучать. А затем объединиться с DevOps командой, настроить данные сборки. Это тоже долго и дорого. А ещё дольше вам предстоит договариваться о том, что именно надо тестировать на продакшене, как это будет отрабатывать, и как настроить ошибки, в которых pre-build будет падать с релизной веткой.
И тут мы уходим в бесконечность, потому что тимлид может самостоятельно продвигать Premium Edition. Он может передавать на более высокий уровень какие-то этапы проекта. В конце концов, он может прийти к техническому директору, внести предложение на весь департамент: «Ребята, нам нужен Sonar. Давайте попробуем эту штуку, потому что от него будет зависеть безопасность нашего кода». На такие предложения полномочий у тимлида уже хватит.
Итого. К сожалению, мы уходим в бесконечность не только по возможностям. Мы соберём и огромное количество негативных откликов от всех — ведь у каждого проекта есть бюджет. А рассчитать, согласовать и запланировать все эти изменения — займёт немало времени.
Итоги
Так должен ли разработчик делать что-то, кроме как просто писать код? Нет, не должен. Но это Basic Edition — начальная версия, когда мы просто писали код и отправляли его дальше, не думая и надеясь на манну небесную от тестировщиков. Получили шесть гневных огонёчков и примерно три часа времени на одну задачу.
В Standart Edition с тест-кейсами у нас было всего лишь два часа и три огонёчка. Это уже неплохо и облегчает жизнь. Благодаря такому подходу мы можем спокойно заниматься во фронтенде тем, чем люди и хотят там заниматься — просто писать код. Вы освободите минимум час времени в день, когда вас никто не будет дёргать. Если вам хочется просто писать код и не вникать, то Standart Edition спасёт от лишнего стресса. Если же вы хотите делать крутые продукты, развиваться и не ловить баги в продакшене — добро пожаловать в Premium Edition.
В Premium Edition времени освобождается ещё больше. Точно просчитать, к сожалению, не получится, всё зависит от того, будете ли вы онбордить сотрудников. Если нет, то останется просто разрабатывать и участвовать во внедрении инструментария. Так у вас освободится ещё больше времени на написание кода, потому что техника будет всё делать за вас.
В Ultimate Edition свои сложности — не все хотят быть тимлидами со всеми вытекающими сложностями и затратами по времени и негативу.
Какой путь выбрать — решать вам. Но когда разработчик тестирует свой код, это облегчает жизнь ему, его команде и тимлиду, ускоряет деплой и выкатку в продакшен, снижает напряжение и риск выгорания.
А как у вас построены процессы в команде? Какой DOD вы используете?