Зачем выбирать, если можно и то, и другое?

Запросы на вытягивание

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

Запрос на вытягивание - это момент, когда вы просите своих коллег просмотреть и проверить изменения вашего кода.

Обычно его также используют:

  1. Для обсуждения стиля кода.
  2. Чтобы обнаружить потенциальные ошибки.
  3. Для архитектурных или дизайнерских обсуждений после того, как решение будет готово.

Запросы на вытягивание - не лучший инструмент для всего

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

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

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

  1. Обсуждения стиля кода. Стиль кода не следует обсуждать в PR. Уже должен быть CI, запускающий средство проверки стиля кода, вот и все. Если вы хотите поговорить о стиле кода, запросите изменение в программе проверки стиля кода, но не в случайном PR.
  2. Выявление ошибок. Ошибки и желаемое поведение должны быть покрыты автоматическими тестами. Разработчик - первое ответственное лицо по этой теме.
  3. Обсуждения архитектуры или дизайна. Как только конкретное решение разработано и готово к рассмотрению, обычно действительно сложно «откатить» эту идею и переписать ее снова. Потому что «зачем тебе это делать? По какому-то субъективному мнению? Это уже сделано. И, похоже, все работает нормально. "

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

Какова должна быть цель запроса на слияние?

  1. Обмен знаниями о предлагаемых изменениях с командой.
  2. Обеспечение согласованности и согласия команды по многочисленным изменениям, которые поступают каждый день, чтобы поддерживать правильное направление проекта. Да, это может включать в себя перепроверку схемы результатов, но… Что, если это уже слишком поздно? Как мы могли решить все эти проблемы?

Парное программирование

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

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

Парное программирование помогает команде работать вместе.

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

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

Парное программирование - это постоянный обзор кода

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

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

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

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

После нескольких лет работы по этой теме

Паттерн, который отвергает парное программирование, - это, по сути, «страх» и выход из зоны комфорта. И это из-за неправильного понимания истоков самой концепции парного программирования.

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

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

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

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

Все зависит от конкретного контекста и людей: разработчиков, пар, задач, настроения.

Все еще неудобно использовать парное программирование?

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

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

Практика делает мастера.

Резюме

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

Не знать всего - это нормально. Самое главное - уметь работать вместе.