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

• Обучение и онбординг новичков.
• Шеринг кода/процессов и обмен опытом.
• Пара решает проблему быстрее и реже обращаются за помощью.
• Повышение производительности.
• Сплочение коллектива.
• Увеличение скорости ревью.

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


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

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

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

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

Так же и в парном программировании.

Меня зовут Дима Вдовин, я разработчик команды корпоративных рисков. Сегодня я хотел бы поговорить о джунах и их интеграции в команду разработки. С одной стороны, тема банальная и известна всем, а с другой, о ней часто забывают или игнорируют. Почему-то многие команды и руководители считают, что джун вольется в коллектив и работу над проектом как-то «самостоятельно», без активной поддержки, а если не вольется — значит он не справляется и не подходит. Это не так.

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