Кажется, это вопрос…

Что такое парное программирование?

Парное программирование (или одноранговое программирование) — это когда два человека (предпочтительно программисты!) работают вместе над одной и той же задачей программирования.

"Скажите "программирование" еще раз..."

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

Что работает?

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

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

Есть еще «автобусный фактор». Что произойдет с проектом, если кто-то из команды попадет под автобус (или, что более вероятно, ему придется уйти из-за чрезвычайной ситуации)? Есть ли ценные технические знания, которые вы сейчас потеряли? При парном программировании вы гарантируете, что несколько членов вашей команды знают, как работает код и что он делает. Это то, что подразумевается под «гибким» кодированием. Возьмите это от человека, который на самом деле попал под машину — жизнь может произойти где угодно и когда угодно, и чем больше у вас людей, знающих ваш код, тем больше вы защищены. идут вперед.

Что не работает?

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

К сожалению, парное программирование не очень устойчиво после 3-4 часов. Если уровни опыта совершенно разные, индивидуальная уверенность может начать ослабевать, поскольку люди думают про себя: «Я не хочу показаться глупым даже из-за того, что предложил это, они знают намного больше меня!». Кроме того, внимание людей начинает отвлекаться от проекта, или один человек начинает делать большую часть работы, а другой наблюдает. Бывают случаи, когда парное программирование может усложнить задачу и даже вбить клин между двумя людьми, поэтому следует знать, сколько времени вы ожидаете работать над данной задачей или насколько близка данная пара с точки зрения уровня навыков. ваше решение о том, является ли это хорошим путем. Правда в том, что каждый работает в своем собственном темпе, и давление, когда кто-то еще наблюдает за тем, как вы кодируете, для некоторых может быть слишком большим.

Что можно и чего нельзя делать

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

-НЕОБХОДИМО использовать правило 5 секунд. Если ваш партнер сделал ошибку, подождите 5 секунд, прежде чем что-то сказать, он может уже заметить ошибку, поэтому немедленное указание на нее может расстроить некоторых людей.

-DO переключайтесь на регулярной основе. Это означает, что один человек «управляет», а другой «навигирует» (один пишет код, а другой просматривает написанный код и дает идеи о том, как реализовать новый код).

-ОБЯЗАТЕЛЬНО внимательно относитесь к потребностям в доступности. Вашему партнеру может потребоваться немного дополнительного времени, чтобы подумать или обработать вещи из-за соображений доступности, поэтому будьте сознательны и принимайте потребности своих партнеров.

-ЗАПРЕЩАЕТСЯ микроуправлению! Говорить своему партнеру: «Сделай X здесь, напиши Y там» — это не цель парного программирования, а обмен идеями и выработка наилучшего и наиболее эффективного решения для кодирования в команде.

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

В заключении

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

Если вы хотите узнать больше об этой очень обширной теме, ниже я привожу несколько полезных ссылок! Спасибо, что нашли время прочитать!

Ссылки:

https://stackify.com/pair-programming-advantages/

https://www.verypossible.com/insights/the-pros-and-cons-of-pair-programming

https://martinfowler.com/articles/on-pair-programming.html

https://www.developer.com/design/pair-programming-dos-and-donts/