Перевод статьи «7 Ways to Get the Most Out of Pair Programming».
Парное программирование занимает значительную часть моего рабочего времени. Я бы даже сказал, что на работе я чаще всего пишу код именно в паре.
В связи с этим я выработал для себя некоторые правила, касающиеся самого процесса парного программирования. Ими я и собираюсь поделиться в этой статье.
Но сперва немного основ.
О парном программировании
Парное программирование зародилось как часть движения экстремального программирования. Вся его суть может быть сведена к ревью кода со знанием контекста.
Ревью это распространенная практика, при которой программист (не автор кода) проверяет предложенные изменения и критикует код или советует что-нибудь.
Когда вы пишете код в паре, каждый программист, собственно, проверят код своего напарника, при этом имея все преимущества знания контекста. Это можно назвать непрерывным ревью кода в режиме реального времени.
Недостаток знания контекста часто затрудняет ревью кода. Ревьюер не всегда может понять, почему автор пошел именно таким путем, если были и другие варианты. Из-за нехватки контекста качество ревью снижается. Поэтому, с точки зрения качества кода, лучше, когда код проверяется буквально во время ввода, а не позже, когда уже предлагается вносить изменения в кодовую базу.
Именно по этой причине, а также в связи с другими преимуществами сотрудничества, практика парного (или даже группового) программирования может принести существенную пользу.
В парном программировании разработка в меньшей степени является творчеством отдельного человека, это скорее синтез идей. И эти идеи обдуманы как минимум двумя программистами, если не больше.
Я считаю, что разнообразие обычно позволяет принимать лучшие решения. Когда двое людей вместе пишут код, это позволяет им взглянуть на проблему с двух разных точек зрения и заполнить «слепые пятна» друг друга.
Наконец, я думаю, что парное программирование приводит к повышению продуктивности и более высокому качеству конечного продукта, чем распределение задач между инженерами, работающими над ними по отдельности. В этом может быть трудно убедить менеджмент, но я не единственный, кто так считает. Некоторые компании даже практикуют исключительно парное программирование.
Вместе с тем парное программирование не всегда приносит ожидаемые плоды. Существует множество плохих шаблонов поведения, которых следует избегать в процессе парного программирования, и хороших шаблонов, требующих внимания.
Далее представлен список (конечно, не полный) простых советов, следуя которым можно невероятно повысить эффективность парного программирования. При составлении списка я представлял парное программирование в классическом понимании, когда двое сидят за одним столом, но те же правила применимы и при удаленной работе.
1. Уважайте друг друга
Демонстрация уважения это ключевой момент всей практики парного программирования.
Чтобы работать в команде, нужно по крайней мере уважать коллег. Это самый минимум и даже странно писать об этом, но мне доводилось видеть немало разработчиков, откровенно грубивших коллегам в ходе парного программирования.
Если вы не способны проявлять уважение к коллегам при написании кода, следует отступить от программирования и пересмотреть ваше понимание эмпатии.
Тем, у кого возникают сложности с этим, я советую почитать книгу Карнеги «Как заводить друзей и оказывать влияние на людей». Из этой книги вы как минимум узнаете, как дать понять людям, что вы их цените.
2. Внимательно относитесь к вашей коммуникации
Хорошую коммуникацию, как и хороший код, может быть сложно определить по каким-то отдельным показателям. Однако, как и случае с хорошим кодом, когда вы видите хорошую коммуникацию, вы понимаете, что это она.
Внимательное отношение к коммуникации связано скорее не с развитием навыков речи. Это больше об умении понимать, что говорят другие люди, и о способности успешно донести свои мысли до окружающих.
Можно рассматривать хорошую коммуникацию как продолжение темы уважения к коллегам. Проявляйте внимание к тому, что они говорят, и обдуманно формулируйте обратную связь.
Внимательное отношение к коммуникации также означает использование общего языка. То, что не следует обижать людей, должно быть очевидно каждому, однако нужно также следить и за тем, чтобы не использовать фразы или сокращения слов, непонятные вашему напарнику. Никому не нравится чувствовать себя невеждой. Если вы непреднамеренно заставляете кого-то чувствовать себя невежественным, он может не захотеть в дальнейшем делиться своими мыслями, и в результате у вас просто испаряется чрезвычайно ценный элемент работы в паре.
Если вы знаете, что ваш язык может быть непонятен другому человеку, постарайтесь смягчить эффект. Например, я стараюсь сразу пояснять термины или жаргонизмы, которые использую во время парного программирования.
3. Озвучивайте свои ожидания
Соблюдение этих первых двух рекомендаций может оказаться сложнее, чем вам кажется. Если вы не чувствуете себя комфортно с вашим партнером, будет хорошей идеей обсудить с ним приведенные выше советы.
Я считаю, что вообще проще заранее озвучить некоторые ожидания, чем сначала делать что-то раздражающее партнера, а затем пытаться это исправить.
Под озвучиванием ожиданий я подразумеваю пояснение, что вы ставите себе целью помогать партнеру, так что с его стороны будет абсолютно нормально задавать вам любые вопросы и свободно делиться своими идеями, не опасаясь бесполезной критики. Это не значит, что не нужно пытаться помочь напарнику, если он неправ или не обладает всей полнотой информации. Просто следует быть конструктивным, давая обратную связь. Это касается обоих партнеров, независимо от уровня мастерства.
Также будет хорошей идеей установить какие-то правила относительно личного пространства и пользования «железом». Мне доводилось видеть немало пар, где партнер наклоняется через другого, чтобы захватить клавиатуру (а это грубо и может обидеть). Думайте о том, как может быть интерпретирован язык вашего тела. Всегда спрашивайте разрешения воспользоваться клавиатурой, прежде чем брать управление на себя.
Возможно, обсуждать все это с напарником будет немного странно. Однако я уверен, что большинство людей оценит, насколько мудро сразу озвучить ожидания от работы в паре, ведь это прямой путь к успешному сотрудничеству.
4. Большую часть времени «водителем» должен быть джуниор
Когда два программиста пишут код совместно, более опытный может испытывать сильный соблазн взять управление (т. е., клавиатуру) в свои руки. Мне такой подход не по нутру, потому что очень часто сеньор забывает пояснять, что именно он делает.
Вещи, которые опытному разработчику кажутся обыденными и очевидными, могут быть не столь очевидны и даже вовсе непонятны менее опытному программисту. Поэтому пояснять каждый шаг процесса разработки напарнику это вообще хорошая идея. Однако, не все программисты это делают.
Я считаю, что есть очень простой способ избежать проблемы отсутствия пояснений: за клавиатурой должен сидеть менее опытный программист. При таком раскладе более опытный напарник попросту не сможет работать над кодом, не поясняя своих действий, потому что для него единственным способом воплотить в коде свои идеи станет пояснение их человеку за клавиатурой.
При этом я вовсе не хочу сказать, что более опытный программист вообще не должен прикасаться к клавиатуре. Многие коллеги вообще не согласны с моими убеждениями на этот счет, потому что «джуниоры» могут учиться у «сеньоров», даже просто наблюдая зи их рабочим процессом.
Поэтому лучше, наверное, соблюдать некий баланс, но я все равно уверен, что должен быть «перекос» в пользу менее опытных программистов.
5. Говорите
Паузы в разговоре вполне допустимы, особенно когда оба участника процесса заняты обдумыванием сложной проблемы. Однако для парного программирования очень важно делиться идеями, это часть процесса работы.
Это не значит, что нужно озвучивать буквально все, что приходит вам в голову (хотя я этим страдаю), но нужно стараться проговаривать свой ход размышлений. Это позволит вашему партнеру на ранних стадиях обнаружить недостатки в ваших рассуждениях, а также будет способствовать обмену опытом.
Я думаю, что следует постоянно искать возможность пояснить свои мысли, чтобы получить возможность узнать, что думает по этому поводу напарник. Это также позволяет вашему партнеру учиться у вас, знакомиться с вашими мыслительными шаблонами, тем, как вы пишете код, с вашими идеями, касающимися процесса разработки. Все это может быть полезно другим людям, так что стоит делиться этим в ходе парного программирования.
Один из самых простых способов зря потратить время, это сидеть молча во время парного программирования, пока напарник работает.
Непрерывное общение также позволяет партнерам сообщать друг другу, когда они нуждаются в перерыве или считают, что пора перейти к следующей задаче. Если вашему напарнику будет легко говорить с вами, это будет очень способствовать хорошей коммуникации и взаимному проявлению уважения.
6. Не диктуйте код
На определенном этапе сессии парного программирования кто-то неизбежно начинает диктовать код. Под диктовкой я понимаю ситуацию, когда программисту буквально говорят, какие символы вводить.
Этой проблемы сложно избежать, и главным образом из-за того, что у людей разный уровень владения языком или парадигмой программирования. Но я все же считаю более полезным проговаривать, чего именно вы пытаетесь достичь, а не напрямую диктовать код.
Вместо того чтобы просить вашего коллегу напечатать «if скобка х равно true скобка», лучше сказать, что вы считаете необходимым проверить какое-то значение на соответствие условиям. Таким образом ваш напарник не останется в неведении и не будет просто тупо вводить текст.
Если вы диктуете код, это ничем не лучше ситуации, когда вы пишете его самостоятельно, потому что при таком раскладе ваш напарник не может активно участвовать в создании кода (ведь он же не знает, к чему вы ведете).
Повторюсь, этой проблемы очень сложно избежать. Порой диктовка это даже и неплохо, например, когда один из партнеров не знаком с синтаксисом. Но это не должно быть вашим дефолтным методом коммуникации.
В качестве упражнения я стараюсь проговаривать псевдокод, не вдаваясь в лишние детали, поскольку это уже лучше, чем диктант.
7. Находите обучающие моменты
Работая с напарником, ищите возможность поделиться с ним знаниями и научить его каким-нибудь приемам. Если замечаете, что человек не использует ваши любимые сочетания клавиш в редакторе, это отличный шанс спросить, не хотел бы он познакомиться с ними.
Но будьте осторожны: некоторые люди могут вовсе не хотеть знакомиться с каждым вашим любимым приемом. Лучше, чтобы подобные обучающие моменты были не слишком частыми, дабы вы не начали раздражать коллегу.
Надеюсь, что эти советы вам пригодятся. Я извлек много пользы из парного программирования как с сеньорами, так и с джуниорами. Но также мне случалось видеть и много примеров неудачного применения этого подхода к работе.
Конечно, все, сказанное здесь, это лишь мое мнение. Все люди уникальны, как и отношения между ними. Но, исходя из своего опыта, могу судить, что этот список может послужить вам хорошим ориентиром, пока вы не выработаете собственные правила.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]