Парное и групповое программирование: как это происходит

Адаптированный перевод статьи «Pair Programming, Trio Programming, Sextuplet Programming?!».

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

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

Вуаля! Началась сессия парного программирования.

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

Совместный просмотр разноцветных строк алгоритмов это не обязательно то, что планируется заранее. (Хотя, пожалуй, все agile-команды считают обязательным устраивать такие сеансы по крайней мере раз в месяц). Это просто происходит. Это заложено в самой природе того, чем мы занимаемся. Да если б мы не учитывали мнение окружающих, мы бы даже Git не пользовались. Вспомните, когда последний раз вы делали пул-реквест в репозиторий, где вы единственный контрибутор? Старые добрые времена!

Словом, всегда следует быть готовым к «обеду» на двоих. И это настоящий праздник обмена опытом и обучения. Это отмечали многие разработчики до меня: когда вы объясняете свое использование Promises (или любое другое свое «колдунство»), вы сами лучше усваиваете этот материал. И это касается не только начинающих разработчиков. Объяснение это двойное обучение, это настоящая магия!

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

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

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

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

Вся эта возня может привлечь внимание других хищников…

Программирование с ревьюером

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

…И тогда третий программист присоединяется к веселью! Теперь мой код атакуют два профессионала одновременно! (За что я премного благодарен, поскольку это хороший шанс чему-нибудь научиться).

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

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

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

Программирование вшестером

Я знаю, что мой код может напоминать автомобильную аварию. Но даже не подозревал, что, как и настоящая авария, он может привлекать зевак. Тем не менее, вот уже за моей спиной стоят пятеро других разработчиков и следят за моими действиями. Со стороны может показаться, что я как минимум успешно хакнул базу данных ФБР.

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

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

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

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

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх