Как вы обеспечиваете качество кода, если в вашем проекте работает более слабый программист?

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

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

1. Хорошие образцы кода из существующей базы кода. Возможно, у вас есть код звездного качества в существующей базе кода (с ожидаемым форматированием/стилем, соглашениями об именах, хорошо спроектированным и проверенным ). Сообщите об этом своему младшему разработчику, чтобы он мог оценить критерии, которым он должен соответствовать.
2. Статический анализ кода. Потратьте некоторое время на поиск подходящего инструмента статического анализа для вашего проекта (если у вас его еще нет). Существуют инструменты, которые помогают исправить стиль кодирования, найти технические дефекты, такие как цикломатическая сложность и проблемы с безопасностью. Однако это может занять время. Но инструмент статического анализа сократит накладные расходы на сеансах проверки кода. Будет полезен для всей команды. (Несколько примеров из мира java - checkstyle , Findbugs )
3. Рецензии коллег. Сможете ли вы найти хотя бы еще одного разработчика такого же уровня? (не уровень навыков, а структура команды). Если это так, вы можете ввести экспертную оценку между всеми младшими членами до того, как код будет проверен старшим. Таким образом, у старшего рецензента будет меньше накладных расходов. Если возможно, избегайте экспертных оценок только для рассматриваемого разработчика. Это может создать негативную динамику в команде. Также это будет хороший опыт для всей команды.
4. Проверка кода старшим/ведущим разработчиком. При выполнении вышеуказанных шагов до достижения этой точки накладные расходы будут меньше.

Подводя итог вышесказанному,

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

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

С другой стороны, в парном программировании вы вместе начинаете задачу с нуля. Пусть он возьмет на себя инициативу, выслушает, как он хочет решить проблему, и внесет предложения о том, как сделать это лучше. Делайте это в течение 1 часа или 2, максимум. Затем он должен некоторое время продолжать самостоятельно. После этого вы можете сделать код-ревью. Вы обнаружите, что таким образом гораздо меньше поводов для критики. И он почувствует воодушевление из-за этого и из-за сотрудничества. Повторите этот ритуал и поменяйтесь парами. Через некоторое время он усвоит ваши ценности и улучшится. И, в конце концов, может быть, вы тоже можете чему-то научиться у него;)

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

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

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

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

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

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

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

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

К сожалению, Peopleware по-прежнему актуален и более актуален, чем когда-либо.