PairProgramminOnceAgain

Материал из b4wiki
Перейти к: навигация, поиск

Работа в паре (или ещё раз о парном программировании)

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

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

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

Сразу хочу оговориться, что я не считаю, что парное программирование - это панацея. Я не буду утверждать, что это единственный правильный подход к разработке и не буду приводить примеры, когда задача длиной в две недели решалась при парном программировании за два часа. Хотя это и так. На самом деле ;)! Просто, кажется, это уже было сделано до меня тысячу раз.

Содержание

Что это такое?

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

Другими словами - см. Википедия

Ситуации, в которых оно полезно

Ситуация первая. Когда кто-то из программистов понимает, что зашёл в тупик. То есть на протяжении последних нескольких часов задачу (или проблему какую-то) решить так и не удалось. В этом случае на помощь приходит другой разработчик и начинает задавать вопросы, которые неизбежны, т.к. перед этим код разрабатывался одиночку. Чаще всего наводящих вопросов бывает достаточно ;). Стоит только начать вслух проговаривать ответы на вопросы, как решение само приходит на ум. Реже вопросы переходят в анализ того или иного решения, применённого до подключения второго разработчика.

При применении такого подхода нет необходимости удваивать количество разработчиков, поскольку в основном разработка программы ведётся в одиночку и только 10-15 % времени требуется парная. В итоге все разработчики в курсе того, что происходит в других кусках кода, и достигается достаточное коллективное владение кодом.

Недостатком такого подхода я вижу то, что потребность во взгляде со стороны (втором разработчике) возникает в произвольный момент. В этот момент тот, кого просят о помощи, может быть сконцентрирован на своей задаче, и отрывать его не стоит. Поэтому особое внимание нужно уделять культуре "запроса помощи". Если кому-то требуется помощь, то в первую очередь он должен задать себе вопросы: "Как я самостоятельно могу разобраться?", "Где я могу прочитать?". Если самостоятельно разобраться не получается, то лучше обратиться к другому разработчику либо на утреннем собрании, либо по почте. Тогда он сможет переключиться со своей задачи в удобное для него время. А это уже из оперы тайм-менеджмента ;)

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

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

Тут важно уделять внимание следующим моментам.

Обязательно на кнопки нажимать должны оба разработчика попеременно. Часто опытные программисты стремятся быстренько вывалить все свои знания и скорее приступить к своим задачам. Они не всегда осознают всю ответственность, которая ложится на их плечи в этой ситуации. Если в ходе парного программирования только один разработчик всё время находится за клавиатурой, то они оба теряют время зря (не забываем, что второй - менее опытный)! Менее опытный ничему в такой ситуации не учится. Представьте себе, что на вас за несколько дней вывалили полугодичный багаж знаний. А теперь - приступайте к работе. Поэтому в данной ситуации опытный разработчик должен сконцентрировать свои усилия на том, чтобы почувствовать тот момент, когда напарник понимает, о чём речь. Лучший способ для этого - обмен клавиатурой каждый час.

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

Ситуация третья. Когда ведущему программисту/менеджеру нужно убедиться, что поставленная им задача правильно понимается программистом. Чаще всего такая ситуация актуальна на этапе испытательного срока, когда чёткого представления о способностях разработчика ещё нет.

Также парное программирование в этом случае помогает:

  * быстро ввести в курс дела
  * сориентировать в среде разработки
  * наладить личностный контакт
  * принять решение о продолжении сотрудничества

В этой ситуации важно обратить внимание на следующие аспекты.

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

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

Проблемы, с которыми приходится сталкиваться

Программисты - народ своеобразный. Очень не просто работать с ними в паре. Поэтому нередко возникают проблемы.

Многие программисты обижаются, когда в сторону их решения высказываются негативные соображения. Что алгоритм не оптимальный, плохой и т.п. Простой выход в такой ситуации - опираться на объективные показатели. То есть в ходе обсуждения максимально деликатно указать на то, что алгоритм (или какая-то функция) не выполняют какой-то роли или не решают поставленную задачу. Принципиально, что в этом случае подобное "замечание" должно быть направлено на улучшение результирующего продукта, то есть звучать как предложение о модернизации, доработке, оптимизации. Например, это может звучать так: "а давай добавим такую штуку, а то сейчас приходится делать так-то и так-то вместо этого".

Бывает, начинаются обвинения, что "у меня всё в порядке, а в твоём коде ошибка". В ответ часто приходят аналогичные заявления. Я стараюсь в этом случае напоминать программистам, что нет понятий "твой", "мой". Есть "наш". Мы вдвоём работаем над одним проектом, и если в нём ошибка, то не важно - "твоя" или "моя". Если избегать таких прямых обвинений, то тот, кто сделал ошибку, всё равно увидит её на этапе исправления и самостоятельно сделает выводы. В итоге "наш" проект будет исправлен без конфликтов.

Когда пара состоит из программиста и схемотехника

В пределах нашей организации разрабатываются и схемы, и печатные платы, и программы для этих плат.

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

Далее плата попадает в руки к программистам. Для разработки аппаратных тестов. Цель этих тестов - понять, работоспособна ли плата.

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

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

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

Также особо остро возникают проблемы, описанные выше. Особенно те, которые касаются разделения зон ответственности. "У нас всё в порядке, а проблема в железе" или "Вы ещё разок настройки регистров проверьте, потому что у нас в схеме всё в порядке". Снова вспоминаем тот принцип: проект общий.

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

Выводы

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

Ну! За взаимопонимание! :)

Другие статьи на эту тему

http://www.maxkir.com/sd/pairprog_RUS.htm

http://b4open.ru/bin/view/B4/WeepingOnXp

Личные инструменты
Пространства имён

Варианты
Действия
разработки
технологии
разное
Инструменты