12 советов, как сделать ваши отношения на расстоянии (программист) работоспособными
Преодолейте трудности, связанные с программированием в паре с удаленными коллегами
Мне всегда нравилось заниматься программированием в паре с моими коллегами. Мне очень приятно иногда проводить час или два со своими товарищами по команде и одновременно работать над одним и тем же кодом. Это дает нам ощущение коллективной собственности. Мы оба обсуждаем, что мы планируем сделать в следующих нескольких строках кода, прежде чем писать его, тем самым подтверждая его необходимость и правильность, прежде чем тратить усилия на его написание. Это было легко в первые дни, когда все работали в одном офисе, сидя рядом.
Что было тогда. Это - сейчас. Это 2017 год. Географически распределено больше команд, чем когда-либо прежде. Работа с удаленными коллегами сопряжена со своими проблемами. Парное программирование пришлось приспосабливаться. При удаленном парном программировании мы должны использовать разные техники.
Как говорит Стивен Колберт, если вы какое-то время живете под камнем, парное программирование обычно приводит к более быстрому написанию лучшего кода при одновременном уменьшении семантических ошибок. Это также снижает потребность в передаче знаний, поскольку знания создаются и сохраняются несколькими людьми, в результате чего код или конфигурация становятся более понятными, чем если бы их создавал один человек. Обычно для этого два программиста сидят бок о бок, один в качестве навигатора, а другой в качестве водителя (используя автомобильную метафору), использующих один и тот же компьютер. Они по очереди - один кодирует, а другой внимательно наблюдает и дает предложения по поддержанию общего качества. Несколько хороших методик были разработаны и научно подтверждены на протяжении многих лет. Но все они предполагают, что оба программиста сидят рядом. Эти методы также предполагают, что конечной целью является программное приложение.
Недавно я выполнял серию упражнений по парному программированию с моим коллегой из Лос-Анджелеса. Мы не создавали программное обеспечение как таковое. Мы были больше озабочены установкой программного обеспечения, настройками, CI, CD и т. Д. - все было ориентировано на успешную реализацию DevOps и культуру. Я обнаружил и применил несколько хороших техник, которые помогли нам добиться большего успеха. Вот несколько полезных советов и техник, которые мы придумали и использовали.
1. Используйте общий документ, чтобы делать заметки.
В традиционном парном программировании два программиста сидят за одним столом. Они могут использовать доску в комнате или бумагу, чтобы рисовать блок-схемы и идеи. Очевидно, что это не так просто по сравнению с видеоконференцией - что мы и использовали. Поэтому мы использовали документ Google для одновременного редактирования в реальном времени. Мы перечислили наши цели как маркеры. Мы оба могли провести мозговой штурм перед мероприятием, каков был наш план, и написать мини-цели прямо здесь, в документе Google. Мы ничего не рисовали, но при желании могли бы использовать слайды Google (например, презентацию в PowerPoint).
2. Иметь два или более экрана.
Это вызывает установку, которая была у нас обоих. У меня был ноутбук и два 24-дюймовых монитора. Я использовал все три экрана. Обычно, когда я программирую сам, я использую только два больших монитора и оставляю экран ноутбука выключенным. Но когда я делюсь своим экраном с удаленным коллегой, я всегда делюсь с экрана ноутбука. Я также ожидаю, что мой партнер поделится с экраном своего ноутбука. Причина в том, что я не могу легко читать мелкие шрифты. Если они используют свой большой экран монитора, текст на моем мониторе выглядит довольно грубым, особенно если они используют более мелкие шрифты. Но если они используют экран своего ноутбука, обычно 15 дюймов, я могу легко увеличить его на одном из моих мониторов. Все будет разборчиво, когда я посмотрю на дисплей их ноутбука на своем 24-дюймовом мониторе.
В этой настройке, где я действовал как навигатор и наблюдал, я использовал один из мониторов для просмотра его общего экрана, я использовал экран моего ноутбука, чтобы получить полноэкранное видео с ним в реальном времени, а второй монитор - для заметок в документах Google. записывай блокнот, копайся глубже в сообщениях об ошибках, болтай с ним о слабости и т. д. Когда его живое видео на экране ноутбука вроде как дает мне вид, что он находится рядом со мной - один из принципов парного программирования.
3. Используйте программное обеспечение для видеоконференцсвязи.
Это подводит меня к программному обеспечению, которое мы используем для видеоконференцсвязи. Неважно, какое программное обеспечение вы используете. На рынке есть несколько хороших. Вы можете использовать любое программное обеспечение, такое как зум, голубые джинсы, скайп, teamviewer, jabber или Hangouts. Все они имеют возможность одновременно отображать и видеопоток, и совместное использование экрана на разных экранах. Для тех из вас, у кого нет трех экранов, но хотелось бы иметь такую настройку, вы можете легко использовать свой телефон или планшет в качестве третьего экрана для видеопотока. Или вы можете просто поместить видеопоток в угол монитора.
4. Используйте чат-клиент, чтобы общаться в хронологическом порядке.
Обязательно используйте чат-клиент. Опять же, не имеет значения, какой клиент чата вы используете. Все они хороши. Используйте тот, который предоставляет ваш офис. Клиент чата позволяет легко обмениваться сообщениями об ошибках, ссылками на решения, фрагментами кода и т. Д. Вы не можете использовать для этого документ Google, потому что он не хронологический.
5. Поделитесь окном терминала, если у вас общий доступ к серверу.
Поскольку мы занимаемся DevOps, есть еще одно место, которое мы разделяем во время парного программирования - окно терминала. Это могут использовать даже программисты, а может и нет. Инженеры DevOps обычно работают с серверами. Важно, чтобы мы оба могли проверять и устранять проблемы за пределами одного общего экрана. Бывают случаи, когда навигатору нужно попробовать что-то на сервере, например, под другим пользователем. Итак, мы оба авторизуемся на одном сервере через ssh в наших собственных окнах терминала.
6. По очереди быть водителем и штурманом.
Конечно, мы также следовали проверенным методам традиционного парного программирования. Мы по очереди были водителями. Обычно очевидно, кто должен быть водителем. Иногда наступает усталость, и нам, возможно, придется переключиться. Навигатору важно набраться терпения и не спешить указывать на глупые ошибки, которые компилятор или линтер все равно поймают. С помощью этой техники люди учатся быстрее. Бывают случаи, когда очевидно, что вам нужно указать на непреднамеренную ошибку. Когда это произойдет, обязательно укажите на это.
7. Не стесняйтесь прерывать своего партнера в любое время.
При работе на расстоянии главное - четкое общение. Если вы заметили, что водитель использует какую-то технику, с которой вы не знакомы, немедленно спросите его и изучите ее. Не беспокойтесь о том, что он потеряет поток мыслей. В парном программировании это не так важно, так как есть общая цель и есть взаимно согласованные задачи. Один или оба из нас вспомнят, куда мы шли, когда быстрое обучение будет завершено. Если вы не помните, просто проверьте свою документацию в Google.
8. Делайте перерывы. И не парься слишком долго
Одним из важных шагов в парном программировании являются перерывы. Ни при каких обстоятельствах я не мог работать вместе более 2 часов в день. После этого становится утомительно. Поскольку вы постоянно говорите и общаетесь, это скоро может утомиться. Кроме того, длительные периоды парного программирования для инженеров DevOps будут мешать вашей другой работе. Так что делайте перерывы по мере необходимости. Но постарайтесь сосредоточиться в течение 2 часов. Фактически, включите вибрацию телефона и сообщите супругу, что вы собираетесь в течение двух часов заниматься парным программированием. Отвечайте только в том случае, если это может быть срочно - или предупредите своего собеседника до начала встречи, что вы ожидаете телефонного звонка или другого отвлекающего фактора.
9. Работа над интересной темой.
Для успешного парного программирования выберите тему, интересующую вас обоих. Кто станет водителем, а кто будет руководить, обычно легко достичь в зависимости от ваших целей. Иногда лучше, чтобы человек изучает что-то новое, чтобы печатать, в других случаях лучше, чтобы человек, обучающий, сам печатал. Когда оба опытны и это не имеет большого значения, просто будьте вежливы.
10. Не позволяйте этому затягиваться
Четко сформулируйте цели и ограничьте время. Разбейте цель на три или четыре меньшие цели и установите для них 30-минутные спринты. Не беспокойтесь о рефакторинге (если вы этим не занимаетесь). Просто запрограммируйте вещи, чтобы счастливый путь заработал. Но как только удачный путь заработает, проведите его рефакторинг, чтобы удалить жестко запрограммированные значения с переменными и т. Д.
11. Работа с другими партнерами.
При парном программировании по очереди с другими людьми в команде. Не всегда работайте с одним и тем же человеком, если только вы не два человека в команде. В таком случае ничего страшного.
12. Не злоупотребляйте им.
И, наконец, имейте в виду, что парное программирование - не всегда правильный инструмент. Даже если это правильный инструмент, довольно скоро срабатывает закон убывающей предельной полезности. Но когда вам нужно объединить программу с удаленным коллегой, вы определенно можете использовать описанные выше методы с максимальной пользой.
Есть ли другие методы, которые мы можем использовать, чтобы сделать дистанционное парное программирование более эффективным? Сообщите мне об этом в комментариях.
Об авторе:
Джон Варгезе (John Varghese) - евангелист DevOps в Intuit, поощряющий использование новых технологий и надежных методов DevOps. Он поддерживает группу Advanced Technology в их переходе на AWS.
Отдельно Джон руководит группой Bay Area AWS Meetup group, посвященной полуострову и Южному заливу. Если вы хотите поговорить с Джоном о его работе в Intuit или о присоединении к сообществу AWS Bay Area, вы можете поговорить с ним прямо на канале AWS-Users-Slack или написать ему в Твиттере на @jvusa.
