Тяни просит место для подготовки юниоров

11

У нас есть концепция, что весь код в запросе Pull в master должен быть готов к работе. Это имеет смысл и является справедливым утверждением, на мой взгляд.

Идея здесь заключается в том, что, как только вы создадите PR, вы заявляете, что вы бы ввели это в мастер, но хотели бы, чтобы некоторые рецензенты просто «согласились» с вами и обнаружили все, что вы пропустили.

Поскольку мы всего лишь люди, мы совершаем ошибки и надеемся, что другие рецензенты могут найти элементы, которые не могут быть найдены в модульных тестах - орфографические ошибки, неправильные javadocs и т. Д.

НО, является ли Запрос на извлечение места тем местом, где мы должны предоставлять некоторый уровень помощи / обучения разработчикам и, если да, до какого уровня?

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

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

Кто-нибудь еще борется с попытками заставить разработчиков достичь цели «Мой запрос на извлечение должен быть готов к работе»?

Риан Шутте
источник

Ответы:

13

Нет. Тяговые запросы не место для обучения. У вашей команды правильная идея. PR означает «Я думаю, что это хорошо. Могу ли я получить второй взгляд на это на случай, если я что-то пропустил. В конце концов, я человек». И я подозреваю, что это именно то, что делает ваш ученик. Они честно думают, что это хорошо, чтобы пойти.

Вот крайняя идея (каламбур). Парная программа с учеником, который дает вам изжогу. Как более старший член команды, ваша задача - поднять их и заставить их работать продуктивно.

Резиновая утка
источник
Спасибо @RubberDuck. Парная программа - отличная идея, и мы делаем это - Сорта. Я подозреваю, что мы должны делать это больше. Однако некоторые правильные метрики или инструменты для измерения, если одна из ваших «капель» в океане неоднократно совершает одни и те же ошибки, помогли бы узнать, кому также нужна эта пара-программирование. Я уверен, что эта проблема усугубляется с большими командами !?
Риан Шутте
2
Что ж, я бы сказал, что большую часть времени нам всем нужно спариваться . Один из наших учеников уловил больше, чем несколько моих ошибок, и я один из самых старших в команде. Возможно, вы могли бы запросить количество комментариев по запросу, но я бы не рекомендовал это делать. Кое-что об отдельных лицах и взаимодействиях ... Серьезно, хотя. Ваша работа - поднять этого разработчика. Получить им копию чистого кода или что-то.
RubberDuck
1
На рабочем месте, где каждый разработчик работает над заказной работой для клиента (без внутренних проектов, которые финансируют себя), парное программирование не так просто, но остается важным! Похоже на то, что компании, возможно, просто придется раскошелиться и инвестировать, если мы хотим, чтобы более продуктивные разработчики работали по расценкам.
Риан Шутте
1
Хм ... почему это не так просто? Разве клиент не получает столько же человеко-часов и, что более важно, лучшее соотношение цены и качества? Желаем удачи, приятель. Полегче с ребенком.
RubberDuck
3
Это распространенное заблуждение @ Энди. Это просто неправда. Да, это противоречит интуиции, я знаю.
RubberDuck
9

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

Но это лучшее место? Вот несколько причин, почему я бы сказал нет:

  1. Если потребуется несколько итераций проверки кода для устранения фундаментального недостатка проекта или крупномасштабной проблемы, то возникнет сильное искушение игнорировать более незначительные проблемы, упомянутые выше, из-за крайних сроков или общего исчерпания обзора. В идеале команда должна быть достаточно устойчивой, чтобы противостоять этому искушению, но, вероятно, лучше не создавать ситуацию, которая привела бы к этому.
  2. Получение обзора кода с большим количеством комментариев не является хорошим опытом для младшего / нового разработчика. Да, реагирование на отзывы - это навык, который им нужно будет развить, но также верно и то, что разработчики не всегда умеют тактично реагировать на код, который им не нравится.

Парные программы и обзоры дизайна являются предпочтительными площадками для более широкой обратной связи.

Тем не менее, было бы еще хуже позволить коду проходить из-за страха, что обращение к нему во время проверки кода «неверно», и могут быть некоторые обстоятельства (например, удаленные команды), когда это лучшее, что вы можете сделать. В этом случае, решите проблемы в обзоре кода, а также решите проблемы в вашем процессе разработки, которые он получил настолько далеко.

Хотя поиск проблемы во время запроса на извлечение может быть не идеальным, он, безусловно, лучше, чем при тестировании или в производственной проблеме.

JohnMcG
источник
5

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

Удерживать открытый запрос на некоторое время очень мало. Оставьте столько откликов, сколько пожелаете, столько людей, сколько захотите, и оставьте это в покое, пока авторы снова не сообщат вам, что, по их мнению, они готовы к слиянию. Запрос на извлечение является отличным центральным инструментом для информирования о предлагаемых изменениях кода, независимо от того, полностью ли они готовы или требуют большой работы.

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

Карл Билефельдт
источник
Спасибо за ваш ответ @ Карл-Билефельдт. Договорились, что можно ожидать некоторой подготовки, но вопрос в том, насколько уместно, на каком уровне. Ваше заявление "... готовы ли они полностью или требуют много работы". Я бы сказал, что пиару мастеру никогда не нужно много работать. Большая работа подразумевает недостатки дизайна, недостатки реализации, а не помогает мне определить, что я пропустил. Тем не менее, я согласен и испытал: «Попытки заставить людей постоянно отправлять идеальные запросы на получение ответа просто разочаровывают всех».
Риан Шутте
2

Я всегда чувствовал, что одним из отличительных признаков хорошего лидера является тот, кто проводит дополнительное обучение по мере необходимости во время каждого цикла разработки. Для меня это означает, что я не только сам кодирую или рецензирую код, но и сижу с более молодыми разработчиками, парные программисты с ними, чтобы помочь им избежать наземных мин, на которые я наступил.

Главным образом, у меня нет иллюзий, что наша основная цель - это образование, это не так. Являетесь ли вы старшим, ведущим или младшим разработчиком, цель не ваше назидание. Цель всегда состоит в том, чтобы предоставить качественный код клиенту. Желательно вовремя, по бюджету, делать то, что они хотят. Однако я признаю, что я не могу выполнить всю работу самостоятельно, поэтому на меня возложена обязанность помочь всем помочь команде добиться успеха. А это означает признание возможностей обучения, когда они появляются в природе.

Итак, на ваш вопрос о том, являются ли запросы на вытягивание местом обучения юниоров, я должен был бы сказать, что во время этих моментов нередко возникают обучающие моменты. Эй, вам придется иметь дело с вашим первым конфликтом слияния, давайте разберемся с этим после обзора. О, смотрите, вы не включили никаких модульных тестов для вашего DAO, мы отложим ваш обзор до тех пор, пока у нас не будет возможности осветить эти новые методы. Почему вы думаете, что в этом финансовом расчете лучше использовать двойные примитивы, чем BigDecimals? Да, это не редкость.

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

Если вы используете ветки функций и выпусков в стратегии ветвления в стиле gitflow, то ваши запросы извлечения становятся чем-то более похожим на кандидаты на выпуск. Не готов к производству, но что-то более приближенное к нему. Вы знаете, что ваш код компилируется (справа), и у вас достаточно тестов, чтобы сделать достойное заявление о том, что он соответствует целям пользовательской истории. И поскольку вы уже провели несколько интеграционных тестов в своей среде разработки, у вас есть отличная демоверсия, готовая к запуску, если вас попросят продемонстрировать изменения, которые вы будете делать, во время проверки вашего PR.

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

Код близок после всего этого. Но тогда мы позволим QA мучить его.

Майкл Пикок
источник
Спасибо за ваш ответ @ Майкл-Павлин. То, что вы говорите, звучит правдоподобно для компаний, которые имеют отдельный отдел контроля качества или тестировщиков, которые проходят через следующий этап. Но когда разработчики также являются тестировщиками, PR сопровождает все: от разработки до тестирования и слияния с мастером. В этом рабочем процессе код должен быть готов к производству после утверждения PR. Я предполагаю, что вопрос также загружен предположением о том, какой рабочий процесс вы используете.
Риан Шутте
Я бы сказал, что даже если у вас нет выделенной команды QA, еще более важно убедиться, что вы добавили интеграционное и / или приемочное тестирование в свой рабочий процесс и дали время для потенциальной доработки, если объединенный код провалит ваши тесты. Вы можете автоматизировать некоторые приемочные испытания с использованием Selenium и Cucumber, чтобы снять с разработчиков часть нагрузки, но я думаю, что важно не предполагать, что код готов к работе, пока вы не продемонстрировали это в ходе тестирования.
Майкл Пикок
Я полностью согласен, следовательно, почему мы все код требует соответствующих тестов с ним. Если вы затем выполните ребазирование мастера до слияния, вы можете быть уверены, что тесты пройдут успешно и код должен работать так, как ожидалось.
Риан Шутте
2

Я хочу поблагодарить всех за их вклад и помочь мне понять, что люди говорят по этой теме.

Это мой ответ после предоставленной обратной связи, и мое понимание теперь основано на полученных ответах и ​​комментариях. Спасибо всем.

Резюме

  • Не ожидайте и не выполняйте совершенные запросы на вытягивание битой, поскольку это только расстроит всех участников.
  • Но продолжайте делать это нашей целью для совершенных запросов на тягу.
  • Ожидайте некоторое количество сотрудничества / помощи в запросах на выгрузку. В конце концов, это то, что вы, по сути, запрашиваете, создавая запрос на извлечение.
  • Если из-за недостатков проектирования или недостатков реализации получится немного, потратьте время с этим разработчиком и проведите парное программирование, чтобы собрать их и приблизить их код к цели . Это роль всех старших разработчиков.
  • Юниорам понадобится больше сеансов парного программирования, чем промежуточным разработчикам. Поэтому ожидайте, что запросы на включение будут отражать это требование.
  • Поощряйте разработчиков проводить совещания по разработке / внедрению перед тем, как прикасаться к коду, чтобы уменьшить любые переделки, указанные в запросах на извлечение.
Риан Шутте
источник
1
Замечательное резюме и ответ. Я бы совсем не обиделась, если бы вы поставили себе галочку.
RubberDuck
Спасибо @RubberDuck, но мое резюме не может существовать без ответов и комментариев каждого на мой вопрос. Приветствия.
Риан Шутте
0

Можете ли вы рассказать больше о культуре вашей компании с точки зрения технических команд? Если вы боретесь с идеей того, чтобы код был готов к работе, когда разработчик хочет объединиться с основной веткой, то что вы на самом деле говорите своим разработчикам? Вы говорите им, что когда их работа «сделана», ничего страшного, если она не работает? Это нормально, если это сломает систему? Если они добавляют технический долг, может быть, это нормально, если они могут оправдать это и знать, что они делают, и показать, что они могут вернуться и провести рефакторинг позже. Но если они не замечают, почему они делают что-то опасное, сколько раз вы позволите этому пройти?

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

Или, может быть, вам нужно нанять заменяющего младшего и уволить того, кто не смог это выяснить?

Вы знаете, что я видел? Люди, которые не являются компетентными разработчиками, продолжают работать в компании годами только из-за кумовства. Поэтому, конечно, их запросы на получение требуют многократных обзоров. На языке Lean это «пустая трата времени» - перетаскивание команды и перетаскивание в нижней строке.

Таким образом, вы должны решить для себя: сколько запросов на получение ответа потребуется вашим юниорам, чтобы проявить компетентность, и у вас есть смелость отпустить тех, кто этого не делает?

RibaldEddie
источник
Спасибо за ваш ответ @RibaldEddie. Мы ожидаем, что разработчики написали бы модульные тесты, вручную протестировали бы и рассмотрели свою собственную работу до такой степени, что они утверждали бы, что этот код великолепен, и если бы им было предоставлено, они слились бы с мастером, но заставит 2 рецензентов рассмотреть его и, надеюсь, подтвердить это утверждение. Мы не несем никакой технической задолженности и полностью отходим от исправлений в пользу решений. Таким образом, ожидается, что код отвечает этим требованиям.
Риан Шутте
@ Риан, кто рецензенты?
Рибальд Эдди
Любой из технических ведет к юниорам. Обычно это один старший / средний рецензент вместе с младшим / промежуточным рецензентом. (2 рецензента)
Риан Шутте
@Riaan, то со временем я бы ожидал, что младшие члены команды будут дифференцироваться. Вы сможете сказать, кто добросовестный, а кто неадекватный. Я считаю, что разработка программного обеспечения выполнена хорошо - это деятельность, хорошо подходящая для менталитета, ориентированного на детали. Некоторые люди могут не справиться с этим. Вам нужно решить, что с ними делать. Но в целом вы должны ожидать, что разработчики, отправляющие код для объединения, уверены, что он работает как задумано и готов к работе. Даже если у вас большая, сложная команда QA, ваши разработчики должны по-прежнему готовить PR-код.
Рибальд Эдди