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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

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