Есть несколько вещей, которые мне очень помогли с получением обзоров кода:

Не говорите «вы» или его варианты («ваш код» и т. д.).

Вы не разбираете «его» код или «его» решение. Это наш код или это решение, и нам нужно что-то с ним делать.

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

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

Используйте позитивный язык и избегайте негатива, насколько это возможно.

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

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

Я был в такой ситуации много раз. И первое, что я обычно говорю: извините...

Да, верно... потому что, если он не усвоил простейшие вещи, например, соглашения об именах, это означает, что вы (или тот, кто за него отвечал) не очень хорошо познакомили его с ними...

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

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

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

Первое: если он правильно понимает задачу, но код неправильный, то углубитесь в код-ревью.

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

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

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

TL;DR: возьмите на себя ответственность за качество кода, извинившись за то, что недостаточно рассказали ему, что делать / чего ожидать, а затем позвольте ему самому исправить свой код.

Другими словами (очень известная цитата):

Скажи мне, и я забуду,
научи меня, и я запомню,
вовлеки меня, и я научусь

Прежде всего, не настаивайте на определенном способе получения обратной связи и извлечения из нее уроков .

В частности, отсутствие заметок на бумаге не обязательно является признаком того, что джуниор не получает ничего/достаточно от проверки кода. Для большинства обзоров кода в стиле программирования я никогда не делал бумажных заметок, потому что я больше сосредотачиваюсь на разговорах о коде и размышлениях о «правилах» и их преимуществах в то время, когда у меня есть кто-то, кто может обсудить это прямо рядом со мной, чем быть занятым написанием материала. И у меня все равно есть "заметки" - в репозитории кода! (По крайней мере, я должен был!). Сосредоточение внимания на реальной проблеме помогает мне гораздо больше, чем записывать вещи, а затем бросать листок бумаги в кучу других заметок, чтобы никогда больше не смотреть на них. Если меня заставят делать записи, все, что я вынесу из собрания, это то, что я не хотел бы работать с этим старшим, потому что он'

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

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

Покажи ему, что он не один, иди на публику

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

Кроме того, если вы чувствуете, что он занимает оборонительную позицию, проведите (некоторые) обзоры кода со всей группой, но начните с некоторых из ваших более старших коллег и относитесь к ним точно так же, как вы относитесь к нему: говорите об их коде, а не о них. . Почти всегда есть что-то, что стоит обсудить, даже в коде от старших. И если это только случай «да, это сделано так из-за а), б) и в), но можно было бы сделать это более общим / следуя принципу X, выполнив Z, но это будет иметь недостаток Y». Убедитесь, что вы используете одинаковый тон и нейтральность для всех. Это показывает младшему, что вы не пытаетесь запугать его своими дурацкими правилами, но что все находятся под одинаковым контролем и что это не «ваши» дурацкие правила, а общие правила команды — предпочтительно основанные на преимуществах команды как целое любит иметь. Кроме того, младший также может учиться на ошибках (или удачных дизайнерских решениях) других. Это делает его еще менее личным для него и дает ему возможность соприкоснуться с другими областями бизнес-логики и принципами программного обеспечения, прежде чем работать над ними - таким образом, у него может быть необходимое время, чтобы «переварить» их, прежде чем применять / работать над их.

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

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

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

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

• Проект был закончен вовремя.

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

В разработке программного обеспечения совершенно естественно иметь неоптимальные архитектуры и улучшать их.

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

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

Я бы начал с самого простого.

«Соглашения об именах»

• В вашей компании наверняка есть гид. Книга Code Complete 2 тоже может быть неплохим руководством. Он объясняет, почему и дает контрольный список.
• Я заставлю его написать шпаргалку и приклеить ее к монитору своего компьютера.
• Если он не войдет в привычку следовать соглашениям компании или собственной шпаргалке. Заставьте его вести бумажный и карандашный словарь всех имен переменных, которые он использует в табличном формате. Это тоже всегда должно быть на его столе рядом с клавиатурой.

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

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

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

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

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

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

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

Вместо того, чтобы начинать с кода младшего разработчика, начните с нуля.

На мой взгляд, это имеет следующие преимущества:

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

С другой стороны, вы действительно пытаетесь наставлять этого разработчика и внедрять навыки, которые принесут пользу команде в будущем. Одним из таких навыков является то, как учиться на обратной связи и сохранить это обучение в будущем. Итак, в этом контексте:

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

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

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

Наконец, как правило:

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

Сопряжение

Вместо code review я бы предложил заняться с ним парным программированием. Неважно, в вашем это проекте или в его, но это может быть полезно для некоторых из них. Когда он печатает и вы замечаете, что что-то можно улучшить, просто задайте нежные наводящие вопросы, например: «Как вы думаете, есть ли способ это улучшить?» Пусть он проработает несколько вариантов, а затем используйте подсказки, чтобы направить его к вашему решению. Тем не менее, попытайтесь проанализировать каждый вариант, который он предлагает, чтобы помочь объяснить обоснование и плюсы/минусы. В конце концов, некоторые варианты лучше других, но не являются лучшим вариантом, и важно понимать причины. Всякий раз, когда он дает хороший ответ или удивляет вас своими знаниями, хвалите его, чтобы он получил вознаграждение во время спаривания.

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

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

Сократический метод

В общем, люди лучше учатся, когда чувствуют, что сами нашли решение, особенно если у них есть «Эврика!» момент. Таким образом, вместо того, чтобы сказать: «Вы должны сделать X. Это лучше всего», я предпочитаю говорить: «Я заметил, что вы делаете X. Вы видели, чтобы кто-нибудь решал это другим способом? О, почему вы предполагаете, что Алиса использовала Y вместо X? Как насчет этого сценария? Какое решение, по вашему мнению, лучше?" Таким образом, задавая наводящие вопросы, вы можете бросить вызов статусу-кво и направить своего коллегу по более просвещенному пути. Иногда вам просто нужно предложить несколько реальных сценариев, которые иллюстрируют, почему Y лучше, чем X, даже если у вас нет под рукой примеров кода. Но если я смогу довести кого-то до того, что онискажем принцип, к которому я веду, я нахожу, что он гораздо лучше подходит, потому что они пришли к этому через свои собственные ответы и выводы, что означает, что они согласны с принципом.

Тестирование

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

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

Я бы не стал уделять слишком много внимания вашему текущему опыту работы с их кодом.

Я думаю, что для всех младших разработчиков лучше всего работает тесное сотрудничество с разработчиками среднего и старшего звена. Это не всегда возможно.

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

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

Ключ:

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

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

Основные проблемы в логике

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

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

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

неясные соглашения об именах

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

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

[У меня] не было достаточно времени, чтобы обсудить «почему» все, что я рекомендовал и помогал ему.

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

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

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

он находится под пристальным вниманием нашего босса по поводу его работы

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

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

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

что еще я могу сделать, чтобы смягчить удар, когда я просматриваю длинный список вещей, которые он сделал неправильно в коде?

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

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

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

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

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

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

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

int xj6b7 = 99.2;

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

x = x / 2; // divide x by 2

Можете ли вы сказать мне, почему вы написали этот комментарий? Кому вы пытаетесь объяснить этот код?

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

Насколько это успешно, зависит от личности учащегося (и от моего таланта в его применении). Что я стараюсь делать в таких случаях, так это задавать вопросы , а не делать заявления.

Примеры:

• «Что делает эта подпрограмма? …… О, тогда, может быть, мы могли бы назвать его так, вместо того, чтобы называть его «M400»?
• «Этот цикл делает что-то отличное от того? …… О, тогда они могут быть учтены в подпрограмме?

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

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

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

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

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

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

Отделение себя от продукта своей работы:
«Вы не являетесь своим кодом».

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

Но опять же, ценность кода для бизнеса и пользователей заключается в том, насколько хорошо этот код работает, а не в том, насколько умен или независим человек, который его создал. Ценность разработчика не в том коде, который он уже создал; это их способность создавать полезный код в будущем . И чем дольше они работают с данной технологией или бизнесом, тем выше должна быть эта ценность, но единственный способ увеличить ее — это вложить в нее время и усилия. А это означает обратную связь о выполненной работе и (надеюсь) больше информации о целях бизнеса, а не только о списке задач.

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

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

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

«Я никогда не забуду свою первую работу после окончания колледжа. (Даже если это было «в колледже»)».

Вот мое предложение:

«Есть одна вещь, которая объективно объединяет вас обоих : созданный исходный код».

А также:

«Процесс , который привел («давайте оба подмигнем, притворимся, что (она) анонимный ...») Разработчик-X создал Исходный код-Y в ответ на Требование-Z».

Расскажите о рабочем продукте ... исходном коде... и рабочем процессе. Не о работнике. Дайте абсолютно (!) ясно понять, что занятость этого человека не находится под угрозой… «Если бы мы не думали, что вы хорошо разбираетесь в этом, мы бы никогда не наняли вас». Дайте понять, что компания теперь твердо намерена помочь этому человеку расти.

Полное раскрытие: «Первая компьютерная программа, которую я когда-либо написал [на Бейсике], состояла из восьми строк, на ее написание у меня ушло шесть месяцев [в конце 1970-х], и в ней была ошибка».

«Разработка компьютерного программного обеспечения — это чертовски сложное дело», и нам нужно всегда ясно давать понять, что мы это понимаем. «Да, мы знаем, что это тяжело, и… мы тебя прикроем».

Убедитесь, что он приносит ручку и бумагу на проверку кода.

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

Затем, когда он будет готов начать, разберите его код и объясните, почему он плохой и почему ваш способ лучше. Придерживайтесь только фактов; не строить догадок о его мотивах. Если есть что-то, что он сделал хорошо, начните и закончите проверку кода с этих областей — «техника бутерброда» для обратной связи. Если он начинает проявлять эмоции или обороняться, остановитесь на мгновение и убедитесь, что ему ясно, что вы не нападаете на него, а пытаетесь ему помочь. Он не сможет стать лучше, если не поймет, в каких областях у него не все в порядке.

Разделите две вещи:

• формальная часть
  1. соглашения об именах
  2. неиспользованный код
  3. форматирование кода
  4. стиль комментариев
• Опыт/логика/архитектура

Формальная часть, которую вы должны адресовать в «извините, я ваш босс / руководитель проекта», сделайте это. Если вы этого не сделаете, то будут дисциплинарные последствия. Скажите мне, сколько времени вам нужно, и мы спланируем это.

В остальном попросите его/ее показать вам набросок или набросок того, как будет реализован новый код, прежде чем начинать его, и обсудите с вами. Объявите, что некоторые вещи пока запрещены (я сделал это в проекте, когда дело касалось структуры данных).