Представьте себе человека, который несколько лет отчаянно пытался завести ребенка. Что бы вы подумали о них, если бы они оставили малыша сразу после его рождения? Если вы не психопат, вы, вероятно, заметили бы, что ему не хватает ответственности, преданности и логики.
Зачем тогда git commit, git push и забыть?
Что делает средний разработчик…
Одна из вещей, которая мотивирует нас, разработчиков, - это вызовы. Сложные задачи, требующие исключительных навыков решения проблем. Или новая технология, которая является интересной, и ее освоение становится центром внимания.
Также есть определенные ситуации, которые нас раздражают. Критическая ошибка, которая отвлекает нас от нашей работы и должна быть устранена как можно скорее. Это неприятная задача, которая, надеюсь, нам никогда не будет поручена.
Будь то функция, которая нас волнует, или исправление ошибок на целый день, которое нас расстраивает, мы иногда склонны забывать, что наша ответственность не заканчивается после того, как мы поместили код в репозиторий.
… И что делает гениальный
Обычная задача кодирования состоит из нескольких этапов жизненного цикла, которые выглядят примерно так:
- Задача возлагается на разработчика.
- Он «в процессе», то есть в данный момент его кодирует разработчик.
- Задача завершена, и разработчик переносит ее в ветку.
- Разработчик настраивает проверку кода / запрос на вытягивание.
- Задача тестируется QA-инженерами.
- Он объединен с основной веткой.
- Наконец, он развернут.
Хотя в вашем случае некоторые из них могут отсутствовать или иметь другой порядок, вы должны получить общее представление. Многие из нас, особенно на ранних этапах карьеры, склонны бросать своего ребенка в пункте 4. Почему?
Хотя творческий процесс выполнения задания интересен, другим может показаться не так. Мы склонны оставлять неинтересные части нашей работы другим и беремся за крутые вещи.
Другие разработчики определенно должны провести обзор. QA-инженеры должны протестировать вашу задачу. Кто-то должен объединить его и развернуть.
Перекладывать ответственность за эти этапы на других - это все равно, что рожать ребенка, а затем сидеть дома и ждать, когда придет обслуживающий персонал и накормит ребенка. Или ждать, пока к вам домой приедет компания по производству одежды и оденет ребенка, после того как его купал представитель детского сада.
Если вы хотите, чтобы ребенок выжил и чтобы вас признали хорошим родителем, вы должны позаботиться об этом.
Получите это!
Вы несете ответственность за свою работу в течение всего указанного жизненного цикла. Вам следует позаботиться о нем, если он не развернут в производственной среде, когда ваша компания часто выпускает релизы. Или - если новая версия становится общедоступной каждые несколько недель, месяцев или лет - когда она находится в основной ветке. Но как?
Обновления прогресса
Прежде всего, в зависимости от того, какой инструмент управления проектами выбрала ваша компания / команда, убедитесь, что вы обновляете статус данной задачи по мере продвижения. Таким образом, вы сделаете счастливым своего мастера схватки или менеджера проекта, и им не придется каждые 2 часа спрашивать вас о вашем прогрессе.
Запросы на вытягивание
Помните правило 30/60, которое я упоминал в одном из предыдущих постов? Вы можете основывать свои действия на временном интервале и при работе с запросами на вытягивание. Давайте разделим жизненный цикл PR на два этапа - оставить и продвинуть. Это нормально, что если вы будете делать это слишком часто, это может сильно расстроить. Вашим товарищам также необходимо сосредоточиться и иметь время поработать, не отвлекаясь. Вот почему мы сначала идем со стадии оставьте это, что означает ожидание, пока кто-то сам рассмотрит. Затем мы переходим к этапу push it, который посвящен лично кому-либо.
Единственное, что здесь сложно, - это разработать структуру для определения того, как долго должна длиться каждая фаза.
Если это исправление, вероятно, неплохо было бы сразу отправить ссылку на отзыв выбранному человеку. Если это действительно срочно, выйдите из-за стола и объясните ситуацию лицом к лицу. Если что-то просто нужно в ближайшее время запустить в производство, действуйте через 2 часа. Если это особенность, действуйте через полдня. Вы можете попросить кого-нибудь взглянуть на него на следующий день, если это подождет, и вы планируете развернуть это через пару дней.
Баланс времени зависит от частоты развертывания и важности задачи. Не стесняйтесь играть с ним. Спросите своих товарищей по команде об их системе рецензирования. Кто-то делает это дважды в день, кто-то делает это сразу, кто-то проверяет только в конце дня. Эта информация может быть полезна для определения этих пропорций.
Тестирование
Если вы передадите свои изменения QA-инженерам, убедитесь, что они знают, что им нужно протестировать их, и могут продолжить. Мы используем целевой процесс и в нашем процессе есть этап «Готово к тестированию». Я написал бота для Slack, который автоматически уведомляет ответственного тестировщика о том, что необходимо выполнить некоторую работу. Вы также можете сделать это вручную. Если возможно, убедитесь, что вы знаете, кто его тестирует, что он знает, что он готов к тестированию. Затем вернитесь в какой-то момент, чтобы спросить о результатах. Это их зеленый свет, которого вы ждете, чтобы перейти к следующему шагу.
Слияние и развертывание
Это действительно зависит от модели выпуска в вашей компании. Если это компания SaaS, вы, вероятно, выпускаете ее часто, иногда несколько раз в день. В таком случае ваша роль заканчивается, когда вы объединяете код, он запускается… и работает.
Совет, который может спасти вашу задницу - постарайтесь как можно скорее запустить свои линии в производство или, по крайней мере, отслеживать, когда они будут запущены. Нет ничего более разочаровывающего, чем ваш товарищ по команде позже позвонит вам и сказал, что он / она только что развернул ваши изменения, а они сломали всю производственную среду.
Это проще, если вы выпускаете редко, так как ваша часть, вероятно, заканчивается после слияния с основной веткой, а все остальное вы оставляете мастерам сборки.
Отслеживание
Если вы используете расширенный инструмент управления проектами, например Jira или Target Process, вы наверняка сможете отфильтровать свою доску спринта, чтобы видеть только назначенные задачи. Обязательно просматривайте их несколько раз в день, чтобы определить, какие действия следует предпринять. Если вас пугает Jira или TP, настройте для себя доску Trello, определите этапы и следите за своей работой на них. Просто убедитесь, что вы отразили свои изменения и в официальном инструменте.
… И расслабься
Это может показаться пугающим, но вы можете (и должны) привыкнуть к тому, чтобы владеть своей работой, и это не займет много времени, если вы овладеете ею. Преимущества безграничны - никто из товарищей по команде не говорит, что ты облажался, никаких сюрпризов на продакшене, никаких задержек из-за того, что ты забыл про пулреквест. Другие плюсы - лучший контроль над своим потоком и меньшее количество людей, спрашивающих вас: «Как насчет того, что вы начали…».
Я надеюсь, что убедил вас, и надеюсь, что владение им теперь имеет смысл. Если тебе это нравится, не сомневайся. Если у вас есть сомнения или комментарии, оставьте их ниже.
