Содержание
Ну и тут модель работы должна быть совсем не такая (что не хорошо и не плохо)… Да, с точки зрения обучения – это будет полезно, но на качество результирующего продукта (а именно в этом заключалась цель) это не повлияет. Слабать совместный кусок, который связывает куски, над которыми два человека работали изолировано – просто идеальное для парной работы. Кен считает, что вполне нормальным проработать в паре 5-6 часов в день. Как по мне, то это практически невозможно. Поработав полтора-два часа уже чувствуешь приличную усталость и я просто не представляю, как в таком режиме можно проработать 6 часов.
Как “Штурман”, избегайте тактического мышления, разбора деталей кода – того, что делает “Ведущий”. Ваша работа – отойти на пару шагов и дополнить вашу пару в части тактики и среднесрочным планированием. Вопросы – самый мощный инструмент для понимания того, что вы делаете, и выбора наилучшего решения.
В парном программировании не обязательно должно участвовать два разработчика. Часто бывает эффективнее брать в напарники людей, у которых знаний значительно больше в других сферах. К примеру, это может быть человек, который обладает более обширным пониманием бизнес-процессов. Мы не могли обсудить детали проекта оффлайн, но в тоже время онлайн позволял нам в любой момент «провалиться» в код, поделившись в онлайне экраном. Для нас было в порядке вещей просто созвониться и обсудить какую-то проблему или даже что-то не связанное с проектами. Очень часто, начав, решение находилось само собой, стоило озвучить свою проблему.
Что Такое Парное Программирование?
Вообще, наверное, самое первое, с чем сталкиваются люди, которые хотят внедрить парное программирование в команду — убеждение менеджмента и команды в эффективности данного метода. И для решения этой проблемы не существует простого рецепта. Здесь нужно пробовать, аргументировать и искать возможности. Очень важно помнить, что в каждый момент времени они ОБА заняты решением задачи, например пока один пишет тест, другой думает о коде, который реализует этот тест. Код становится примером, а вопросы раскрывают суть действий.
Во втором случае, когда появился хотя бы один тест, который не проходит код, клавиатура обязательно передаётся от того, кто писал тест, другому участнику. По завершении рефакторинга, код всегда должен оказаться в исходном состоянии — должен проходить все тесты. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 16 января 2018 года; проверки требуют 5 правок.
Зачем Мы Применяем Парное Программирование?
Senior следует ответственно отнестись к парному программированию с Junior. Первым шагом будет признание самого факта, что сейчас вы в паре с джуном, а ему потребуется больше поддержки, внимания и направления действий. Учитывайте это еще при планировании, чтобы избежать давления сроков. Выбирайте подходящие (подходящие для Junior’а в данном случае) задачи, учитывая особенности и потребности, перечисленные выше. После сессии парного программирования обязательно проведите ретроспективу, пусть на пять минут, но хотя бы с одним улучшением, которое вы примените в следующую сессию. Развивайте не только код и навыки, но и сам процесс работы, именно это позволит качественнее и комфортнее разрабатывать продукт.
Кроме того, когда над одним вопросом работают двое — шансы найти оптимальное решение повышаются. Так разве нельзя просто сесть и начать работать? Можно, но лучше заранее разобраться в проверенных временем стилях парного программирования.
Выгоды От Парного Программирования
В паре коды создаются быстрее, поскольку преимущественное количество ошибок удаляется не при тестировании, а в процессе кодировки. Для устранения дефектов такой команде нужно меньше времени. Каждый из тандема может лучше противостоять стрессовой ситуации, которая https://deveducation.com/ негативно воздействует на человека при одиночном программировании. Даже в напряженной ситуации, для уменьшения сроков исполнения задачи, все возникающие попытки создать «грязный» код пресекаются партнером. Участники такой парной команды поощряют друг друга.
Если одному из вас сложно прочитать код, попробуйте сделать по-другому, чтобы стало понятнее. Но совместное ревью кода имеет также и свои минусы. Один из разработчиков начал разработку новой фичи раньше, чем к нему присоединился второй.
- Проговаривание и объяснение способствует активному размышлению над выбранным вариантом.
- Развивайте не только код и навыки, но и сам процесс работы, именно это позволит качественнее и комфортнее разрабатывать продукт.
- Не стесняйтесь присоединяться к работе над задачами, в которых вы не знаете предметной области или используемых технологий.
- Попробуйте объединить эту технику с техникой “Помодоро” и попробуйте завершать один шаг за одну “помидорку”.
- Положительные взаимоотношения членов команды помогут достичь хороших результатов.
- Вы можете отредактировать статью, добавив ссылки на авторитетные источники в виде сносок.
В руках «Водителя» клавиатура, он пишет код и его мышление сфокусировано на том, как здесь и сейчас написать некоторый код лучшим способом. Он думает о том, является ли оптимальным код «Водителя» для решения в целом, размышляет об альтернативах и способах упростить систему. Парное программирование — методика, при которой весь разрабатываемый код пишется двумя программистами на одном компьютере. Пинг-понг программирование — разновидность парного программирования, адаптированная для метода разработки через тестирование. Надо отметить, что хотя XP и требует двух человек для написания кода, но задача назначается одному. Этим избегается размазывание ответственности и переход ее в коллективную безответственность.
Стили Парного Программирования
Таким образом, команда должна выработать часы работы, приемлемые для всех и строго их придерживаться. Внедряли мы XP и парное программирование сверху. Я рассказал ребятам теорию и предложил попробовать. Потом стали потихоньку приближаться к правилу XP – “весь рабочий код должен писаться в паре”. Не нужно превращать в обычное наблюдение процесс парного программирования. Такой подход обладает всеми преимуществами совместного конструирования и мозговых атак.
Преимущества Парного Программирования
Может ли один человек сочетать в себе оба режима одновременно? Поэтому такой “удвоенный” взгляд улучшает качество кода, так как включает рассмотрение и деталей, и общей картины. Если вы заметили, что кто-то в команде предпочитает все время работать над одними и теми же темами, попросите его обобщить знания и поделиться ими.
И два таких Junior все равно не выполнят задачу. Они могут просто-напросто не знать какого-то алгоритма, библиотеки, особенности языка и не знать о том, что они пока еще этого не знают (те самые unknown unknowns). Подходит для опытных, хорошо сработавшихся команд. Все работают по кругу со всеми, пока задача не будет выполнена.
А примером неформальной служат схемы «старший — младший», «новенький в команде — тот, кто на проекте уже несколько лет». Пожалуй, те выходные были моим первым полноценным опытом парного программирования. Очень быстро Робик полюбился всей семьей, а воспоминаниям о наших играх теперь отведено особое место.
В Других Проектах
Парное программирование – одна из методик Экстремального Программирования , заключающаяся в том, что два человека ОДНОВРЕМЕННО трудятся над ОДНОЙ ЗАДАЧЕЙ и сидят при этом ЗА ОДНИМ компьютером. Чтобы создать атмосферу, в которой каждый чувствует свободу говорить открыто и задавать вопросы, необходимо доверие между вами. Поэтому правильно выстроенные отношения так важны в команде. Выделяйте время на личное общение и фидбек. Парное программирование толкает нас на обсуждение различных решений и подходов помимо монолога в своей голове. Проговаривание и объяснение способствует активному размышлению над выбранным вариантом.
Это необязательно хорошие кодеры, но как правило участники серьёзных (технических) совещаний и помогающие с реализацией фич на проектах. Менеджерить тушки, писать бумажки и тереть тёрки — вместо педаленья кода? Хорошему синьору — такое, как правило, нафиг не надо. Делитесь своим опытом парного программирования, буду рад конструктивной дискуссии в комментариях. В команде всегда есть формальные и неформальные иерархии. Примером формальной иерархии может быть взаимодействие между PM или Team Lead-ом и командой.