Одно на самом деле не делает другое лишним

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

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

Несколько примеров, когда есть смысл применить обе практики вместе.

  1. Два младших разработчика объединились для выполнения одной задачи на день и верят, что их код готов к развертыванию. Следует ли более опытному разработчику проверить свой код перед тем, как он будет объединен с мастером и запущен? Скорее всего, да. После проверки кода юниоры получат быструю обратную связь и возможность извлечь из нее уроки. Рецензент будет уверен, что код действительно готов к работе.
  2. Создавая пары, вы нашли элегантное решение проблемы и внесли важные изменения в систему. Хотели бы вы сообщить об этом остальной части вашей (потенциально удаленной) команды? Да, возможно. Каждый член команды будет знаком с новым решением или с важным изменением и получит возможность прокомментировать это.
  3. При объединении задачи вы достигли точки, когда закончили кодирование и убедились, что код работает должным образом. Возможно, вы все равно захотите взглянуть на разницу перед объединением кода в мастер, чтобы убедиться, что код не только хорошо выглядит для вас сегодня, но и будет иметь смысл для вас обоих через шесть месяцев.

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

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

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

А пока я хотел бы порекомендовать эти статьи по парному программированию и обзору кода:

Если вы нашли этот пост полезным, дайте несколько хлопков ниже или поделитесь им в социальных сетях. Спасибо за внимание!