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

95

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

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

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

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

Zalomon
источник
7
Сколько времени вы потратили, чтобы убедиться, что он знает, каковы ваши ожидания?
Blrfl
13
@gnat Я думаю, что это не тот случай, моя проблема не в том, что мы превышаем оценки или переусердствуем в коде. На самом деле мы опережаем график. Мой вопрос состоит в том, как уравновесить грань между обучением парня и не выгорать его постоянной критикой, для младшего может быть неприятно, если вы скажете ему переделывать то, что на его взгляд работает.
Заломон
4
Я отредактировал это, чтобы сделать это больше по теме. Я считаю, что это не так, как связанный дубликат вопроса.
enderland
3
Некоторые вещи, которые я пробовал, помогают в этом: парное программирование - узнайте, как он работает и думает, и, возможно, познакомите его с вашими мыслительными процессами, когда вы будете просматривать код. Найдите задачи, в которых он хорош - иногда вы получите лучшие результаты, бросив ему кучу мелких ошибок по сравнению с большой функциональностью. Технические разработки - дайте ему первый шанс на разработку программного обеспечения, не касаясь кода. Это позволяет ему думать о структуре и процессах, против того, чтобы опускать голову и набирать код. Наконец, удачи. Иногда требуется больше настойчивости, чем ожидалось, но оно того стоит, если он становится продуктивным.
Сэнди Чепмен

Ответы:

84

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

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

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

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

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

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

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

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

enderland
источник
65
@ 9000 Удивительно, как часто люди расстраиваются из-за того, что люди не вносят свой вклад в соответствии со своими стандартами, когда эти стандарты нигде не документированы ...
enderland
32
Имена переменных крайне важны для описания цели кода; имена методов / функций, тем более. Правильные имена - это не бесполезный перфекционизм, он необходим для удобства обслуживания.
9000
9
@Zalomon Определенно упомяните это ему; более того, включите это в обсуждение. Будучи младшим разработчиком, я работал с несколькими разными старшими разработчиками. Мой лучший опыт был с разработчиком, который рассказал мне все свои рекомендации - даже «маленькие», например, немного лучшее имя для переменной. Я не только многому научился у него, но я чувствовал себя настолько хорошо, что он слушал мои мыслительные процессы и включал меня в дискуссию - это заставило меня захотеть, чтобы он пересмотрел мой код, чтобы я мог узнать больше. (продолжение)
dj18
6
@Zalomon (продолжение) С другой стороны, старший разработчик, который делал изменения за моей спиной (даже если вы скажете ему потом, что он все еще за спиной), полностью деморализует - это заставило меня чувствовать, что я работаю с автократом, что я пришлось выяснить, как понравиться.
dj18
6
Мой (небольшой) опыт наставничества младших разработчиков показывает, что заставить разработчика задуматься о правильном имени и выразить назначение данных в имени переменной стоит того. Это помогает разработчику на самом деле понять, что делает их код, гораздо менее волнистым способом, чем они привыкли. Иногда это приводит их к поиску логических ошибок в соответствующем коде или просто к лучшему способу выражения чего-либо. (То же самое работает для меня; разница в том, что я усвоил дисциплину, благодаря строгим рецензентам кода, которые у меня были в прошлом.)
9000
19

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

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

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

Язык тела

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

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

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

Легато
источник
2
Что касается словоблудия: когда вы должны использовать личное местоимение, просто выбор «мы» вместо «вы» также обезличивает критику, по моему опыту, с обеих сторон обзора кода.
Джош Касвелл
6

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

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

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

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

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

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

Мачадо
источник
5

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

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

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

JimmyJames
источник
Один из способов избежать бесконечных циклов проверки кода - сделать небольшие изменения. Ни один пулл-запрос не является смехотворно маленьким, если он вносит полезные изменения (я сделал свою долю в 1-символьных PR) Чем меньше, тем лучше. Безжалостно сокращать объем билетов, вручаемых младшим разработчикам, и заставлять их делать свои дела. Как только они справятся со всем процессом чтения-понимания-проверки кода-проверки-развертывания, область применения может увеличиться.
9000
1
Я не думаю, что было бы хорошей идеей сказать разработчику «они не очень важны», если они достаточно важны, чтобы OP мог вернуться и измениться позже.
enderland
3
@enderland По моему опыту, идеальный код не существует. Вы всегда можете улучшить это позже, так что это не очень важно здесь. ОП говорит, что это «исправить, если у меня будет свободное время». Есть два вида проблем. Вещи, которые должны быть исправлены, и вещи, которые не должны быть исправлены. Последнее может или не может быть исправлено, и они звучат так, как будто они попадают в эту категорию. На каком-то уровне это призыв к суждению, но я думаю, что если вы, как опытный разработчик, не уверены, стоит ли называть это обязательным изменением, скорее всего, это не так.
JimmyJames
5

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

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

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

gnasher729
источник
3
Или «(б) И я знаю, что вы можете сделать лучше». Если он спрашивает «научи меня», ты знаешь, что он на правильном пути. :)
Мачадо
1
На моей предыдущей позиции мы использовали Stash / BitBucket в качестве инструмента для проверки кода. У него была возможность заблокировать пул-запрос путем установки невыполненной задачи или полного отклонения пул-запроса. Я бы использовал их только для необходимых изменений. Если бы произошло косметическое изменение (например, незначительная читаемость кода, улучшенная структура данных, рефакторинг), я бы указал на это с предложениями, но не добавил бы задачу блокировки, сделайте это, если у вас есть время. Это также предотвращает несоблюдение сроков над мелкими суетами
Hand-E-Food
4

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

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

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

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

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

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

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

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

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

JacquesB
источник
2

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

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

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

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

closeparen
источник
1

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

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

Кевин Крумвиде
источник
Фактически он сказал мне, что чувствовал себя глупым. Я пытаюсь держать критику в позитивном ключе, и я сказал ему, что доволен его работой, я также объяснил ему, что у меня были подобные сомнения, когда я начинал, но я должен предположить, что некоторые отзывы о том, чтобы дать ему чтобы улучшить его работу, это выходит из-под контроля.
Заломон
2
Объясните, что вы не будете тратить время на тщательную критику его кода, если не ожидаете, что он станет лучшим программистом. И будьте внимательны при разграничении между «вам нужно исправить это, чтобы код был приемлемым» и «вот что вы можете сделать еще лучше в следующий раз» Предоставление большого количества проницательной и точной критики - самый большой подарок, который вы можете сделать младшему программисту. Неспособность сделать это делает их хуже программиста. Критика должна начать уменьшаться. Вы должны совершать каждую ошибку только один раз, может быть, дважды, а ошибок так много.
Дэвид Шварц
1

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

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

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

Zak
источник
0

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

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

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

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

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

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

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

200_success
источник
-1

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

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

acithium
источник
-1

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

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