Как бороться с «почти хорошим» кодом от младшего разработчика? [закрыто]

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

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

Мой вопрос: когда мне остановиться? Прямо сейчас, если есть незначительные нарушения стиля кодирования, такие как имена переменных на неправильном языке (предыдущая команда смешала испанский и английский, и я пытаюсь это исправить), или некоторые незначительные структурные проблемы, я отпускаю и исправляю их, если У меня есть свободное время или мне нужно изменить проблемный класс. Я чувствую, что это хорошо для морального состояния команды, поэтому я не буду постоянно возвращать код тому, что новичку может показаться мелочами, что может быть довольно неприятно, но я также беспокоюсь, что слишком «мягкое» может помешать парню от обучения, как сделать что-то.

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

Если вы считаете, что код должен быть исправлен до слияния, сделайте комментарии. Желательно с «почему», чтобы разработчик мог учиться.

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

Однако, если вы делаете комментарии, которые кажутся утомительными, возможно, подумайте:

• Должен ли ваш процесс CI ловить их?
• У вас есть четкое «руководство разработчика» для справки (или все это задокументировано)?
• Действительно ли эти комментарии способствуют качеству кода?

Многие жертвуют производительностью на алтаре процесса или совершенства. Будьте осторожны, вы не делаете этого.

Попробуйте посетить вашего коллегу лично, если это возможно. Или используйте видеозвонки. Построение отношений облегчает управление критикой (даже обзорами кода).

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

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

Сохраняйте критику в отношении кода, а не автора.

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

Один из способов добиться этого - мудро выбирать слова. Хотя люди STEM любят считать себя очень логичными, эмоции являются частью человеческой природы. Используемое словосочетание может быть различием между обидой или избавлением от чувств. Выражение «Это имя функции будет более соответствовать соглашениям, если оно написано на английском», предпочтительнее «Вы написали неправильное имя этой функции, и оно должно быть на английском». В то время как последнее все еще ручное и само по себе может показаться хорошим, по сравнению с первым его недостатки становятся очевидными - при подготовке того, что сказать лично или по электронной почте, проверьте, действительно ли ваш контекст, слова и внимание сосредоточены на проблемах, а не на человек .

Язык тела

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

Дайте честный положительный отзыв

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

Парень открыт для критики и готов учиться, но у меня есть некоторые сомнения в том, насколько я должен подталкивать некоторые вещи.

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

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

Кроме того, если вы сдерживаетесь, вы не помогаете, а покровительствуете.

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

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

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

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

Я верю в концепцию обучаемого момента . Если у разработчика достаточно умственных способностей, он (а) может запросить подробности о том, что вы будете делать по-другому. (S) он не может и это нормально. Люди сгорают, и в начале карьеры может потребоваться много умственной энергии, чтобы выполнить то, что кажется простым позже.

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

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

Поэтому вы не говорите: «Я отказываюсь от вашей работы, потому что она недостаточно хороша». Вы говорите (а) «Я принимаю вашу работу, потому что она достаточно хороша», а затем (б) «Но я хочу ее лучше».

Довольно широко открытый вопрос, но вот пара идей.

1. Рецензии (от младшего разработчика)

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

2. Ранний отзыв / обзор заданий

   Разрешить разработчику участвовать в его собственной разбивке задач. Попросите его записать свой намеченный дизайн в примечаниях к заданию и представить «проверку кода» без изменений и только с заданием. Таким образом, вы можете просмотреть его план, прежде чем он написал одну строчку кода. Как только его задача будет рассмотрена, он может начать кодирование (после чего он отправит еще один обзор кода). Это позволяет избежать деморализующей ситуации, когда разработчик написал кучу материала, и вы должны сказать ему переписать его.

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

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

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

Подумайте о принятии рабочего процесса проверки кода, когда разработчики публикуют свои предлагаемые коммиты в таком инструменте, как Github Pull Requests или Phabricator Diffusion, и получают одноранговый выход, прежде чем вносить свои изменения в общую ветку master.

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

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

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

Я не буду постоянно возвращать код тому, что новичку может показаться незначительными деталями, что может быть довольно неприятно, но я также беспокоюсь, что слишком «мягкое» поведение может помешать парню научиться делать что-то.

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

Предполагая, что у вас есть какой-то рабочий запрос или проверка кода, и кажется, что вы это делаете, я бы порекомендовал отметить «некритические» или «предпочтительные» вещи.

Если вы видите PR в состоянии, аналогичном тому, что вы описываете, с некоторыми незначительными стилистическими проблемами или нуждающимися в некритическом рефакторинге, оставьте комментарий, но также смело одобряйте. Сказав что-то вроде: «В будущем, возможно, постарайтесь избегать названий методов, подобных этому, в пользу чего-то вроде descriptiveMethodName», документируйте свое мнение, не вынуждая их изменить его или не блокируя их разработку.

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

Я имею дело с младшим разработчиком, который работает удаленно с фабрики кодирования.

Это, к сожалению, не идеальная ситуация: один продвинутый программист, отвечающий за одного начинающего программиста, с географическим разделением. Неудивительно, что есть некоторая напряженность, но это несоответствие можно смягчить.

Мне интересно, что ты имеешь в виду под "фабрикой кодирования"? Для меня эта терминология указывает на тревожное отношение, которое может усугубить некоторые из упомянутых вами проблем управления.

… Нарушение SRP, объектов God, бессмысленных имен для методов или переменных; Я указываю, что он должен исправить, и пытаюсь объяснить, почему это неправильно.

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

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

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

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

Всегда говорите им, что они сделали правильно и как они могут улучшить в следующий раз. Мы всегда можем поправиться в какой-то области. Обратная связь имеет решающее значение, чтобы стать лучше во всем.

Еще одна идея справиться с «слишком большой критикой» - это время от времени самостоятельно выполнять задание, и пусть младший разработчик сделает для вас обзор кода. Это имеет как минимум два преимущества:

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