Привет, Хабр! Когда разработчик — это только код? А когда — полный хаос, в котором виноваты дизайнеры, 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 вы используете?