У нас есть концепция, что весь код в запросе Pull в master должен быть готов к работе. Это имеет смысл и является справедливым утверждением, на мой взгляд.
Идея здесь заключается в том, что, как только вы создадите PR, вы заявляете, что вы бы ввели это в мастер, но хотели бы, чтобы некоторые рецензенты просто «согласились» с вами и обнаружили все, что вы пропустили.
Поскольку мы всего лишь люди, мы совершаем ошибки и надеемся, что другие рецензенты могут найти элементы, которые не могут быть найдены в модульных тестах - орфографические ошибки, неправильные javadocs и т. Д.
НО, является ли Запрос на извлечение места тем местом, где мы должны предоставлять некоторый уровень помощи / обучения разработчикам и, если да, до какого уровня?
Каждый раз, когда вы отправляете новые изменения, рецензенты должны пересматривать ваши изменения, что отнимает у них время разработки и вызывает пересмотр изменений.
Итак, сколько тренировок ожидается, должно быть разрешено, в запросах на извлечение? Часть меня чувствует, что это изменяется от младших до старших. Однако я также чувствую, что это не должно быть место для поиска огромного количества проблем - даже для юниоров.
Кто-нибудь еще борется с попытками заставить разработчиков достичь цели «Мой запрос на извлечение должен быть готов к работе»?
источник
Если код, который нарушает основные принципы проектирования или стандарты команды, доходит до стадии запроса на извлечение, то он обязательно должен быть там решен. И обзоры кода могут быть хорошим средством передачи стандартов команды и методов проектирования.
Но это лучшее место? Вот несколько причин, почему я бы сказал нет:
Парные программы и обзоры дизайна являются предпочтительными площадками для более широкой обратной связи.
Тем не менее, было бы еще хуже позволить коду проходить из-за страха, что обращение к нему во время проверки кода «неверно», и могут быть некоторые обстоятельства (например, удаленные команды), когда это лучшее, что вы можете сделать. В этом случае, решите проблемы в обзоре кода, а также решите проблемы в вашем процессе разработки, которые он получил настолько далеко.
Хотя поиск проблемы во время запроса на извлечение может быть не идеальным, он, безусловно, лучше, чем при тестировании или в производственной проблеме.
источник
Я бы сформулировал это больше, так как запросы на извлечение не должны быть единственным местом, где вы обучаете людей. Кроме того, младшие разработчики - не единственные, кому может потребоваться некоторое обучение в запросе на извлечение. Подрядчики, участники с открытым исходным кодом, разработчики из других отделов, которые не знакомы с местным кодом или стандартами, и даже опытные программисты нуждаются в случайных напоминаниях, когда становятся довольными.
Удерживать открытый запрос на некоторое время очень мало. Оставьте столько откликов, сколько пожелаете, столько людей, сколько захотите, и оставьте это в покое, пока авторы снова не сообщат вам, что, по их мнению, они готовы к слиянию. Запрос на извлечение является отличным центральным инструментом для информирования о предлагаемых изменениях кода, независимо от того, полностью ли они готовы или требуют большой работы.
Некоторые проверки запросов на получение запросов оказываются всего лишь штампом, а некоторые из них, которые представляют собой внешнюю заявку в команду, могут занять месяц назад и вперед. Первый вид хорош, когда вы можете его получить, но это не значит, что второй вид не имеет ценности. Попытки заставить людей постоянно отправлять идеальные запросы на получение доступа просто разочаровывают всех.
источник
Я всегда чувствовал, что одним из отличительных признаков хорошего лидера является тот, кто проводит дополнительное обучение по мере необходимости во время каждого цикла разработки. Для меня это означает, что я не только сам кодирую или рецензирую код, но и сижу с более молодыми разработчиками, парные программисты с ними, чтобы помочь им избежать наземных мин, на которые я наступил.
Главным образом, у меня нет иллюзий, что наша основная цель - это образование, это не так. Являетесь ли вы старшим, ведущим или младшим разработчиком, цель не ваше назидание. Цель всегда состоит в том, чтобы предоставить качественный код клиенту. Желательно вовремя, по бюджету, делать то, что они хотят. Однако я признаю, что я не могу выполнить всю работу самостоятельно, поэтому на меня возложена обязанность помочь всем помочь команде добиться успеха. А это означает признание возможностей обучения, когда они появляются в природе.
Итак, на ваш вопрос о том, являются ли запросы на вытягивание местом обучения юниоров, я должен был бы сказать, что во время этих моментов нередко возникают обучающие моменты. Эй, вам придется иметь дело с вашим первым конфликтом слияния, давайте разберемся с этим после обзора. О, смотрите, вы не включили никаких модульных тестов для вашего DAO, мы отложим ваш обзор до тех пор, пока у нас не будет возможности осветить эти новые методы. Почему вы думаете, что в этом финансовом расчете лучше использовать двойные примитивы, чем BigDecimals? Да, это не редкость.
Так что, хотя я бы сказал, что это, безусловно, может произойти, но это явно не главная цель запроса на удаление. Также я не чувствую, что код в запросе на получение готов к работе. Часто это не так.
Если вы используете ветки функций и выпусков в стратегии ветвления в стиле gitflow, то ваши запросы извлечения становятся чем-то более похожим на кандидаты на выпуск. Не готов к производству, но что-то более приближенное к нему. Вы знаете, что ваш код компилируется (справа), и у вас достаточно тестов, чтобы сделать достойное заявление о том, что он соответствует целям пользовательской истории. И поскольку вы уже провели несколько интеграционных тестов в своей среде разработки, у вас есть отличная демоверсия, готовая к запуску, если вас попросят продемонстрировать изменения, которые вы будете делать, во время проверки вашего PR.
В конечном счете, я чувствую, что мы должны оказывать помощь при рассмотрении PR, но эта помощь не связана с общим кодированием. Вместо этого это связано с подготовкой предложенного кода для включения в рабочую базу кода производственного качества. PR - это возможность для разработчиков продемонстрировать, что они имеют обоснование и твердое понимание каждого изменения, которое они включили в PR. И даже тогда - даже после того, как мы взвесили их с помощью модульных тестов, демонстраций и множества вопросов - все еще не ожидается, что предлагаемые изменения готовы к производству.
Код близок после всего этого. Но тогда мы позволим QA мучить его.
источник
Я хочу поблагодарить всех за их вклад и помочь мне понять, что люди говорят по этой теме.
Это мой ответ после предоставленной обратной связи, и мое понимание теперь основано на полученных ответах и комментариях. Спасибо всем.
Резюме
источник
Можете ли вы рассказать больше о культуре вашей компании с точки зрения технических команд? Если вы боретесь с идеей того, чтобы код был готов к работе, когда разработчик хочет объединиться с основной веткой, то что вы на самом деле говорите своим разработчикам? Вы говорите им, что когда их работа «сделана», ничего страшного, если она не работает? Это нормально, если это сломает систему? Если они добавляют технический долг, может быть, это нормально, если они могут оправдать это и знать, что они делают, и показать, что они могут вернуться и провести рефакторинг позже. Но если они не замечают, почему они делают что-то опасное, сколько раз вы позволите этому пройти?
Если у вас есть младший разработчик, его первые несколько запросов на получение, очевидно, будут иметь проблемы. В конце концов они должны научиться этому. Если вы обнаружите, что у них продолжают возникать проблемы, то, возможно, вы назначаете им работу, к которой они еще не готовы?
Или, может быть, вам нужно нанять заменяющего младшего и уволить того, кто не смог это выяснить?
Вы знаете, что я видел? Люди, которые не являются компетентными разработчиками, продолжают работать в компании годами только из-за кумовства. Поэтому, конечно, их запросы на получение требуют многократных обзоров. На языке Lean это «пустая трата времени» - перетаскивание команды и перетаскивание в нижней строке.
Таким образом, вы должны решить для себя: сколько запросов на получение ответа потребуется вашим юниорам, чтобы проявить компетентность, и у вас есть смелость отпустить тех, кто этого не делает?
источник