Парное программирование
1. Парное программирование для начинающих (и скептиков)
Моя контора намерена более активно применять парное программирование в процессе разработки. Сегодня же я решил вам поведать о своем опыте парного программирования. Я не могу сказать, что в парном программировании меня устраивает абсолютно все, или я всегда получаю от этого удовольствие. Тем не менее, очевидных преимуществ достаточно для того, чтобы убедить меня. Я как раз тот тип человека (интроверт, привык работать в одиночку), который должен был бы столкнуться с трудностями при парном программировании, но я все равно продолжаю этим заниматься, хотя, уверен, вам будет проще.
1 То, как мы это делаем
Я люблю проводить параллель между разработкой программного обеспечения и ящиком с рыбацкими снастями. Мне нужно место для всего и все в одном месте. Когда мне требуется приманка, я точно знаю, где ее искать. Точно так же я должен заранее определить, где у меня будет храниться код доступа к данным, бизнес-логика проекта, и как все это будет собираться вместе. Когда я приступаю к написанию нового кода, я стараюсь организовать его в предсказуемую структуру, которая была бы легко узнаваема для каждого, кто работает над проектом. В то же время, я хочу, чтобы и другие программисты, делая изменения в коде, следовали принципам базовой организации так, чтобы я мог впоследствии найти и понять их код. Каждое приложение со своей "изюминкой", оттого и дизайн всегда различен. В любом развивающемся проекте вы должны найти переломный момент, который я называю "то, как мы это делаем". Детали становятся прозрачными. Меньше сюрпризов. История изменений приобретает более последовательный и точный вид. Т.к. любая группа представляет себе общий шаблон системной структуры, они способны реализовать изменения без излишней суеты. Если вы действительно хотите достичь этого уровня как можно скорее, спешу обратить ваше внимание на два нюанса, которые стоит учитывать для того, чтобы приблизиться к этому переломного моменту.
1. Определение шаблона и архитектуры системы, находящейся в разработке.
2. Распространение этого дизайна на всю команду разработчиков.
Во-первых, спарка позволяет держать у себя под рукой знания и опыт каждого в команде. Любому разработчику просто невозможно иметь представление о всех технологиях и шаблонах проектирования в мире. А т.к. каждый разработчик принимает участие в дизайне, вы часто можете выработать рабочий подход быстрее, чем это сможет сделать один единственный архитектор. В одном нашем проекте с теоретически 100% спаркой у нас было пару программистов с богатым опытом разработки клиентских приложений. Сам же я был больше ориентирован на web разработку. Объединившись вместе, с нашими неравными знаниями мы смогли в кратчайшие сроки разработать стратегию общего рабочего дизайна для системы в целом путем сосредоточения всех наших навыков на каждом элементарном модуле системы.
В качестве примера из моего непродолжительного пребывания в команде архитекторов могу привести своего коллегу, который разработал тщательно продуманное решение с инфраструктурой ETL (Extract, Transform, Load — извлечь, преобразовать, загрузить) между несколькими системами с абсурдно сложной подсистемой обработки ошибок. У нас была командная лицензия на SQL Server, и все те задачи, которые этот разработчик пытался решить самостоятельно, могли быть реализованы "прямо из коробки" с помощью Data Transformation Services. Если бы он слушал других разработчиков или работал с ними, они смогли бы быстро расправиться с ETL и потратить больше времени на управление инфраструктурой проекта, чтобы создать такой дизайн, который программисты могли действительно реализовать.
Если вы являетесь старшим разработчиком, одна из ваших задач — научить других разработчиков чувствовать курс дела. Как ведущий разработчик (дизайн, документация, презентация и т.д.), работающий плечом к плечу со своими сотрудниками, я не делал ничего, кроме создания механизма общего понимания стратегии проекта. Привлечение внимания каждого разработчика к дизайну дает им больше контекстуальной информации о проекте. Из раза в раз я сталкивался с тем, что чем более подробные комментарии я давал разработчику, тем хуже код получался на выходе. Я просто не могу думать за кого-либо еще. Если разработчик может ответить на вопрос "почему", он делает работу лучше и зачастую производит улучшения по ходу дела.
Например, моя жена периодически приводит в порядок нашу большую коллекцию CD. Ее бесит, если я кладу CD не туда. Я делаю это только из-за того, что не понимаю ее правил организации. Я не могу понять, почему CD должен лежать именно на этой полке, потому что я не принимал участия в наведении порядка. И спустя 9 лет, я до сих пор не понимаю свою жену, но это уже отдельный разговор.
2 Улучшать НАШ код или защищать СВОЙ?
Парное программирование дает и психологические преимущества. Формальный пересмотр кода, даже если это делают ваши коллеги, может быть ужасной процедурой, которая зачастую перерастает в разделение на преследователей и обвиняемых. В течение моего небольшого опыта многие ударялись в бессмысленную проверку соответствия кода со стандартами оформления. Еще хуже то, что такие проверки, обычно являясь лишь первой каплей, оказываются бесполезными, т.к. делать значительные изменения уже слишком поздно. [Джон Роббинс в своей книге "Отладка приложений для Microsoft .NET и Microsoft Windows" описывает эту проблему как СКПД — сначала кодируй, потом думай — прим. переводчика]
Коллективное владение всеми аспектами проекта — что достигается при парном программировании — может кардинально изменить ситуацию. Я вместе со своими коллегами сейчас могу говорить о том, как улучшить "наш" код, вместо того, чтобы защищать "свой". Т.к. каждый из нас видит большую часть кода, у нас могут быть информативные беседы, касающиеся общего технического направления. Подробный пересмотр кода случается в реальном времени, поэтому проблемы решаются быстрее. Включите сюда пересмотр кода различными разработчиками, и вы получите множество глаз над каждым критическим участком программы. Способность быть самокритичным к существующему коду помогает все улучшать и улучшать дизайн системы и ее код. Я думаю, это основной путь, с помощью которого развивающееся программирование может привести к лучшей, более приятной рабочей обстановке.
2. Ротации в парном программировании
На вопрос, как часто следует менять напарников, должна ответить сама команда разработчиков. Слышал, что некоторые команды меняют разработчиков каждые 90 минут, а другие и того реже. Сам я склоняюсь к варианту, при котором напарники остаются неизменными, пока не расправятся с поставленной перед ними задачей. Конечно, я также предполагаю, что задачи по кодированию должны жестко распределяться на день или два, что по любому ведет к ежедневной ротации напарников. Я думаю, назначать пары удобно сразу после планерки или ланча. Непозволительно, если ваше расписание заставляет простаивать разработчиков. Я "жаворонок", поэтому работаю с большей отдачей рано утром на свежую голову. Держите накопившуюся нераспределяемую работу (в оригинале — non-pairing work — прим. переводчика) у себя на виду, чтобы никто не простаивал в ожидании, пока его напарник сделает что-нибудь полезное.
Я уверен, что единственным постоянным в ротации напарников является то, что разработчики должны самостоятельно выработать правила организации и действовать в соответствии с этими правилами. Если напарников будет назначать, подобно диктатору, старший разработчик либо управляющий проектом, эффективность работы не будет такой же высокой, как при более эгалитаристском подходе. Что я действительно стараюсь делать, так это не назначать автоматом на самую ответственную работу самых опытных ребят, потому что это никогда не позволит остальным учиться, что, в свою очередь, может повлечь за собой чувство обиды.
Прошлым летом мы назначали одного разработчика ответственным за историю проекта на протяжении одной итерации. Мне показалось, что это отличный способ балансировать между продолжительностью и ротацией напарников.
Несколько раз я слышал про практику, когда специальный звонок или зуммер сигнализирует о необходимости смены напарника. Считаю это просто отвратительным.
3. Парное программирование как идеальный путь учиться и учить
Давайте будем честными с самими собой. Вы применяете спарку только для того, чтобы повысить "пропускную способность", но не как средство тренировки. Я говорю это к тому, что спарка может весьма эффективно применяться для обмена знаниями и обучения молодых специалистов.
При парном программировании нужно оценивать проект в общем. Иногда спарка с менее опытным программистом может отнять больше времени на выполнение поставленной задачи, чем если бы вы кодировали в одиночку, но это не самое главное. Во-первых, вы должны быть терпеливым. Если вы сможете применить опыт работы в паре для того, чтобы увеличить производительность ваших коллег, скорость работы вашей команды в конце концов впишется в темпы командной разработки. Тут напрашивается аналогия с баскетболом, где самые лучшие игроки считаются именно теми, кто действительно может сделать свою команду лучше.
В своей карьере я очень рано оказался на ведущих позициях, когда я еще боролся за увеличение своей собственной скорости, поэтому я никогда по настоящему не осознавал значимости повышения скорости работы команды. Лишь много позже я осознал это. Одно из преимуществ развивающейся разработки — концепция коллективного владения ситуацией и смещение фокуса на завершение работы над софтом командой, а не на выявления своих собственных качеств. Эта неочевидная разница действительно изменила мои взгляды на командную разработку софта.
Одно из преимуществ от работы с напарником лично для меня — это возможность перенять некоторые трюки работы с IDE и новыми инструментами у своих коллег. Не недооценивайте то, насколько могут поднять вашу производительность короткие сочетания клавиш. Прошлым летом мы были одними из первых пользователей ReSharper beta (на этот раз я подожду еще несколько билдов, перед тем, как попробую ReSharper 2.0 beta). У нас работало несколько парней с небольшим опытом работы с IntelliJ IDE для Java. Эти ребята вдруг стали намного быстрее меня и всех остальных, кто не имел опыта работы с IntelliJ. Тогда мы ввели новое правило на некоторое время: ведущий напарник должен был выкрикивать сочетания клавиш, которые он использовал при работе с ReSharper. Спустя пару месяцев, программируя в одиночку, я заметил, насколько быстро я стал управляться с IDE.
Мне запомнились и другие яркие примеры: мой первый опыт работы с WinForms, введение TestDriven.Net для быстрого переключения между кодированием и блочным тестированием с помощью NUnit и др.
4. Подробнее о парном программировании
1 Беремся за дело
Некоторые могут просто сесть за клавиатуру и начать сочинять блочные тесты. Для мне это тяжело. Лично я гораздо более продуктивен, если провожу хотя бы немного времени, делая черновые наброски в UML, либо просто записываю список изменений, которые необходимо произвести в коде (тут новые методы, там новые классы и т.д.). Мне импонирует одна очень эффективная метода, при которой оба напарника, перед тем, как взяться за дело, обсуждают способы решения поставленной задачи у доски. Это простой и быстрый способ получить общее представление о проблеме. Несомненно, половину вы выбросите из списка и пойдете другим путем, но важен сам факт составления списка вместе, а не его составление как таковое.
2 Ведомый должен принимать участие
Ведомый напарник все равно должен принимать участие при кодировании. Он должен думать наперед и искать потенциальные проблемы в текущем подходе. Опираясь на опыт бывалых, таких как Стив МакКоннелл (автор бессмертной книги "Code Complete", пережившей два издания — прим. переводчика) и Роберт Гласс, пересмотр кода — один из самых действенных инструментов для удаления ошибок в коде.
Я считаю нормальным, если ведомый напарник иногда занимается исследовательской работой по поводу следующего участка работы, в ином случае он должен быть сосредоточен на текущем процессе кодирования.
Если вы как раз "наблюдатель", не будьте сволочью. Не спешите с комментариями типа "ты забыл точку с запятой", по меньшей мере до тех пор, пока ведущий не нажмет Enter. Быть назойливым — самый верный путь стать плохим "наблюдателем".
Меняйтесь часто, чтобы оба человека были вовлечены в запись истории изменений. Ни один нормальный разработчик не любит смотреть, как кто-то другой кодирует. В прошлом году на планерке произошел неприятный инцидент, когда мой напарник выдал свои изменения за мои. Он был плохим напарником.
3 Подавляйте паразитные склонности каждого разработчика
При программировании любого участка кода принимают участие двое человек, а значит, у вас есть возможность избежать проявления паразитных склонностей любого разработчика. Я, к примеру, страсть люблю теорию паттернов проектирования, что ведет к моему стремлению стать "архитектурным астронавтом".
Кодирование в паре с кем-нибудь, кто не разделяет этого моего стремления, помогает удержать меня на земле и писать код, который будет полезен всей команде.
С другой стороны, если ваш напарник предлагает реализовать задачу в виде хранимой процедуры на 1400 строк, вы можете напомнить ему, что T-SQL не очень удачное решение, ввиду того, что его тяжело тестировать, отлаживать и читать в данном контексте, по сравнению с теми же C#/VB .NET/Java (и Джереми угрожает телесными повреждениями любому, кто запихнет бизнес-логику в хранимую процедуру).
5. Эргономика парного программирования
Для парного программирования очень важно создать благоприятную рабочую обстановку. Не знаю, как вы, но я работаю не очень продуктивно при растяжении шеи или если у меня нету возможности подсмотреть, что печатает мой напарник. Знаю, что первоначально ребята, занимающиеся экстремальным программированием (в оригинале — XP guys — прим. переводчика), пользовались единственной клавиатурой и мышкой, однако, мой опыт был много лучше: к одной рабочей станции были подключены второй монитор, клавиатура и мышка. Каждый напарник следит за процессом и может быстро взять ситуацию под контроль. Соблюдайте правила этикета, чтобы не драться, выясняя, кто сейчас должен печатать и двигать мышкой.
На самом деле вам понадобится такое место, где вы сможете сидеть плечом к плечу без стеснения. В нашем нынешнем офисе в Аустине у меня замечательный письменный стол с выдвижными ящиками по обе стороны, но он ужасно неудобен для парного программирования (приходится меняться местами, чтобы сесть за клавиатуру, и это напрягает). Когда мы переедем в более просторное помещение, я буду настаивать на покупке обычных столов вместо письменных.
Пользуйтесь преимуществами нового мира ноутбуков и беспроводных сетей, чтобы просто встать и найти себе другое подходящее место. Всегда давайте знать вашей команде, куда вы уходите, и оставляйте включенным мессенджер, если вы зашли в кафетерий.
Хочется добавить, что неплохо было бы иметь доску или блокнот где-нибудь поблизости, чтобы совместно делать кое-какие наброски. Известный методологист Элистер Кокберн (Alistair Cockburn) высказал мнение о том, что два человека способны наиболее продуктивно обмениваться своими мыслями, стоя у доски. В прошлогоднем проекте у нас было 3 или 4 доски на колесиках, которые можно было передвигать куда угодно. Я клянусь, что эффект от затраченных пары сотен долларов на покупку этих досок был гораздо больше, чем типичная команда сможет получить от нескольких лицензий на Rational Rose.
Jeremy D. Miller
Перевод Алексея Нестерова
Моя контора намерена более активно применять парное программирование в процессе разработки. Сегодня же я решил вам поведать о своем опыте парного программирования. Я не могу сказать, что в парном программировании меня устраивает абсолютно все, или я всегда получаю от этого удовольствие. Тем не менее, очевидных преимуществ достаточно для того, чтобы убедить меня. Я как раз тот тип человека (интроверт, привык работать в одиночку), который должен был бы столкнуться с трудностями при парном программировании, но я все равно продолжаю этим заниматься, хотя, уверен, вам будет проще.
1 То, как мы это делаем
Я люблю проводить параллель между разработкой программного обеспечения и ящиком с рыбацкими снастями. Мне нужно место для всего и все в одном месте. Когда мне требуется приманка, я точно знаю, где ее искать. Точно так же я должен заранее определить, где у меня будет храниться код доступа к данным, бизнес-логика проекта, и как все это будет собираться вместе. Когда я приступаю к написанию нового кода, я стараюсь организовать его в предсказуемую структуру, которая была бы легко узнаваема для каждого, кто работает над проектом. В то же время, я хочу, чтобы и другие программисты, делая изменения в коде, следовали принципам базовой организации так, чтобы я мог впоследствии найти и понять их код. Каждое приложение со своей "изюминкой", оттого и дизайн всегда различен. В любом развивающемся проекте вы должны найти переломный момент, который я называю "то, как мы это делаем". Детали становятся прозрачными. Меньше сюрпризов. История изменений приобретает более последовательный и точный вид. Т.к. любая группа представляет себе общий шаблон системной структуры, они способны реализовать изменения без излишней суеты. Если вы действительно хотите достичь этого уровня как можно скорее, спешу обратить ваше внимание на два нюанса, которые стоит учитывать для того, чтобы приблизиться к этому переломного моменту.
1. Определение шаблона и архитектуры системы, находящейся в разработке.
2. Распространение этого дизайна на всю команду разработчиков.
Во-первых, спарка позволяет держать у себя под рукой знания и опыт каждого в команде. Любому разработчику просто невозможно иметь представление о всех технологиях и шаблонах проектирования в мире. А т.к. каждый разработчик принимает участие в дизайне, вы часто можете выработать рабочий подход быстрее, чем это сможет сделать один единственный архитектор. В одном нашем проекте с теоретически 100% спаркой у нас было пару программистов с богатым опытом разработки клиентских приложений. Сам же я был больше ориентирован на web разработку. Объединившись вместе, с нашими неравными знаниями мы смогли в кратчайшие сроки разработать стратегию общего рабочего дизайна для системы в целом путем сосредоточения всех наших навыков на каждом элементарном модуле системы.
В качестве примера из моего непродолжительного пребывания в команде архитекторов могу привести своего коллегу, который разработал тщательно продуманное решение с инфраструктурой ETL (Extract, Transform, Load — извлечь, преобразовать, загрузить) между несколькими системами с абсурдно сложной подсистемой обработки ошибок. У нас была командная лицензия на SQL Server, и все те задачи, которые этот разработчик пытался решить самостоятельно, могли быть реализованы "прямо из коробки" с помощью Data Transformation Services. Если бы он слушал других разработчиков или работал с ними, они смогли бы быстро расправиться с ETL и потратить больше времени на управление инфраструктурой проекта, чтобы создать такой дизайн, который программисты могли действительно реализовать.
Если вы являетесь старшим разработчиком, одна из ваших задач — научить других разработчиков чувствовать курс дела. Как ведущий разработчик (дизайн, документация, презентация и т.д.), работающий плечом к плечу со своими сотрудниками, я не делал ничего, кроме создания механизма общего понимания стратегии проекта. Привлечение внимания каждого разработчика к дизайну дает им больше контекстуальной информации о проекте. Из раза в раз я сталкивался с тем, что чем более подробные комментарии я давал разработчику, тем хуже код получался на выходе. Я просто не могу думать за кого-либо еще. Если разработчик может ответить на вопрос "почему", он делает работу лучше и зачастую производит улучшения по ходу дела.
Например, моя жена периодически приводит в порядок нашу большую коллекцию CD. Ее бесит, если я кладу CD не туда. Я делаю это только из-за того, что не понимаю ее правил организации. Я не могу понять, почему CD должен лежать именно на этой полке, потому что я не принимал участия в наведении порядка. И спустя 9 лет, я до сих пор не понимаю свою жену, но это уже отдельный разговор.
2 Улучшать НАШ код или защищать СВОЙ?
Парное программирование дает и психологические преимущества. Формальный пересмотр кода, даже если это делают ваши коллеги, может быть ужасной процедурой, которая зачастую перерастает в разделение на преследователей и обвиняемых. В течение моего небольшого опыта многие ударялись в бессмысленную проверку соответствия кода со стандартами оформления. Еще хуже то, что такие проверки, обычно являясь лишь первой каплей, оказываются бесполезными, т.к. делать значительные изменения уже слишком поздно. [Джон Роббинс в своей книге "Отладка приложений для Microsoft .NET и Microsoft Windows" описывает эту проблему как СКПД — сначала кодируй, потом думай — прим. переводчика]
Коллективное владение всеми аспектами проекта — что достигается при парном программировании — может кардинально изменить ситуацию. Я вместе со своими коллегами сейчас могу говорить о том, как улучшить "наш" код, вместо того, чтобы защищать "свой". Т.к. каждый из нас видит большую часть кода, у нас могут быть информативные беседы, касающиеся общего технического направления. Подробный пересмотр кода случается в реальном времени, поэтому проблемы решаются быстрее. Включите сюда пересмотр кода различными разработчиками, и вы получите множество глаз над каждым критическим участком программы. Способность быть самокритичным к существующему коду помогает все улучшать и улучшать дизайн системы и ее код. Я думаю, это основной путь, с помощью которого развивающееся программирование может привести к лучшей, более приятной рабочей обстановке.
2. Ротации в парном программировании
На вопрос, как часто следует менять напарников, должна ответить сама команда разработчиков. Слышал, что некоторые команды меняют разработчиков каждые 90 минут, а другие и того реже. Сам я склоняюсь к варианту, при котором напарники остаются неизменными, пока не расправятся с поставленной перед ними задачей. Конечно, я также предполагаю, что задачи по кодированию должны жестко распределяться на день или два, что по любому ведет к ежедневной ротации напарников. Я думаю, назначать пары удобно сразу после планерки или ланча. Непозволительно, если ваше расписание заставляет простаивать разработчиков. Я "жаворонок", поэтому работаю с большей отдачей рано утром на свежую голову. Держите накопившуюся нераспределяемую работу (в оригинале — non-pairing work — прим. переводчика) у себя на виду, чтобы никто не простаивал в ожидании, пока его напарник сделает что-нибудь полезное.
Я уверен, что единственным постоянным в ротации напарников является то, что разработчики должны самостоятельно выработать правила организации и действовать в соответствии с этими правилами. Если напарников будет назначать, подобно диктатору, старший разработчик либо управляющий проектом, эффективность работы не будет такой же высокой, как при более эгалитаристском подходе. Что я действительно стараюсь делать, так это не назначать автоматом на самую ответственную работу самых опытных ребят, потому что это никогда не позволит остальным учиться, что, в свою очередь, может повлечь за собой чувство обиды.
Прошлым летом мы назначали одного разработчика ответственным за историю проекта на протяжении одной итерации. Мне показалось, что это отличный способ балансировать между продолжительностью и ротацией напарников.
Несколько раз я слышал про практику, когда специальный звонок или зуммер сигнализирует о необходимости смены напарника. Считаю это просто отвратительным.
3. Парное программирование как идеальный путь учиться и учить
Давайте будем честными с самими собой. Вы применяете спарку только для того, чтобы повысить "пропускную способность", но не как средство тренировки. Я говорю это к тому, что спарка может весьма эффективно применяться для обмена знаниями и обучения молодых специалистов.
При парном программировании нужно оценивать проект в общем. Иногда спарка с менее опытным программистом может отнять больше времени на выполнение поставленной задачи, чем если бы вы кодировали в одиночку, но это не самое главное. Во-первых, вы должны быть терпеливым. Если вы сможете применить опыт работы в паре для того, чтобы увеличить производительность ваших коллег, скорость работы вашей команды в конце концов впишется в темпы командной разработки. Тут напрашивается аналогия с баскетболом, где самые лучшие игроки считаются именно теми, кто действительно может сделать свою команду лучше.
В своей карьере я очень рано оказался на ведущих позициях, когда я еще боролся за увеличение своей собственной скорости, поэтому я никогда по настоящему не осознавал значимости повышения скорости работы команды. Лишь много позже я осознал это. Одно из преимуществ развивающейся разработки — концепция коллективного владения ситуацией и смещение фокуса на завершение работы над софтом командой, а не на выявления своих собственных качеств. Эта неочевидная разница действительно изменила мои взгляды на командную разработку софта.
Одно из преимуществ от работы с напарником лично для меня — это возможность перенять некоторые трюки работы с IDE и новыми инструментами у своих коллег. Не недооценивайте то, насколько могут поднять вашу производительность короткие сочетания клавиш. Прошлым летом мы были одними из первых пользователей ReSharper beta (на этот раз я подожду еще несколько билдов, перед тем, как попробую ReSharper 2.0 beta). У нас работало несколько парней с небольшим опытом работы с IntelliJ IDE для Java. Эти ребята вдруг стали намного быстрее меня и всех остальных, кто не имел опыта работы с IntelliJ. Тогда мы ввели новое правило на некоторое время: ведущий напарник должен был выкрикивать сочетания клавиш, которые он использовал при работе с ReSharper. Спустя пару месяцев, программируя в одиночку, я заметил, насколько быстро я стал управляться с IDE.
Мне запомнились и другие яркие примеры: мой первый опыт работы с WinForms, введение TestDriven.Net для быстрого переключения между кодированием и блочным тестированием с помощью NUnit и др.
4. Подробнее о парном программировании
1 Беремся за дело
Некоторые могут просто сесть за клавиатуру и начать сочинять блочные тесты. Для мне это тяжело. Лично я гораздо более продуктивен, если провожу хотя бы немного времени, делая черновые наброски в UML, либо просто записываю список изменений, которые необходимо произвести в коде (тут новые методы, там новые классы и т.д.). Мне импонирует одна очень эффективная метода, при которой оба напарника, перед тем, как взяться за дело, обсуждают способы решения поставленной задачи у доски. Это простой и быстрый способ получить общее представление о проблеме. Несомненно, половину вы выбросите из списка и пойдете другим путем, но важен сам факт составления списка вместе, а не его составление как таковое.
2 Ведомый должен принимать участие
Ведомый напарник все равно должен принимать участие при кодировании. Он должен думать наперед и искать потенциальные проблемы в текущем подходе. Опираясь на опыт бывалых, таких как Стив МакКоннелл (автор бессмертной книги "Code Complete", пережившей два издания — прим. переводчика) и Роберт Гласс, пересмотр кода — один из самых действенных инструментов для удаления ошибок в коде.
Я считаю нормальным, если ведомый напарник иногда занимается исследовательской работой по поводу следующего участка работы, в ином случае он должен быть сосредоточен на текущем процессе кодирования.
Если вы как раз "наблюдатель", не будьте сволочью. Не спешите с комментариями типа "ты забыл точку с запятой", по меньшей мере до тех пор, пока ведущий не нажмет Enter. Быть назойливым — самый верный путь стать плохим "наблюдателем".
Меняйтесь часто, чтобы оба человека были вовлечены в запись истории изменений. Ни один нормальный разработчик не любит смотреть, как кто-то другой кодирует. В прошлом году на планерке произошел неприятный инцидент, когда мой напарник выдал свои изменения за мои. Он был плохим напарником.
3 Подавляйте паразитные склонности каждого разработчика
При программировании любого участка кода принимают участие двое человек, а значит, у вас есть возможность избежать проявления паразитных склонностей любого разработчика. Я, к примеру, страсть люблю теорию паттернов проектирования, что ведет к моему стремлению стать "архитектурным астронавтом".
Кодирование в паре с кем-нибудь, кто не разделяет этого моего стремления, помогает удержать меня на земле и писать код, который будет полезен всей команде.
С другой стороны, если ваш напарник предлагает реализовать задачу в виде хранимой процедуры на 1400 строк, вы можете напомнить ему, что T-SQL не очень удачное решение, ввиду того, что его тяжело тестировать, отлаживать и читать в данном контексте, по сравнению с теми же C#/VB .NET/Java (и Джереми угрожает телесными повреждениями любому, кто запихнет бизнес-логику в хранимую процедуру).
5. Эргономика парного программирования
Для парного программирования очень важно создать благоприятную рабочую обстановку. Не знаю, как вы, но я работаю не очень продуктивно при растяжении шеи или если у меня нету возможности подсмотреть, что печатает мой напарник. Знаю, что первоначально ребята, занимающиеся экстремальным программированием (в оригинале — XP guys — прим. переводчика), пользовались единственной клавиатурой и мышкой, однако, мой опыт был много лучше: к одной рабочей станции были подключены второй монитор, клавиатура и мышка. Каждый напарник следит за процессом и может быстро взять ситуацию под контроль. Соблюдайте правила этикета, чтобы не драться, выясняя, кто сейчас должен печатать и двигать мышкой.
На самом деле вам понадобится такое место, где вы сможете сидеть плечом к плечу без стеснения. В нашем нынешнем офисе в Аустине у меня замечательный письменный стол с выдвижными ящиками по обе стороны, но он ужасно неудобен для парного программирования (приходится меняться местами, чтобы сесть за клавиатуру, и это напрягает). Когда мы переедем в более просторное помещение, я буду настаивать на покупке обычных столов вместо письменных.
Пользуйтесь преимуществами нового мира ноутбуков и беспроводных сетей, чтобы просто встать и найти себе другое подходящее место. Всегда давайте знать вашей команде, куда вы уходите, и оставляйте включенным мессенджер, если вы зашли в кафетерий.
Хочется добавить, что неплохо было бы иметь доску или блокнот где-нибудь поблизости, чтобы совместно делать кое-какие наброски. Известный методологист Элистер Кокберн (Alistair Cockburn) высказал мнение о том, что два человека способны наиболее продуктивно обмениваться своими мыслями, стоя у доски. В прошлогоднем проекте у нас было 3 или 4 доски на колесиках, которые можно было передвигать куда угодно. Я клянусь, что эффект от затраченных пары сотен долларов на покупку этих досок был гораздо больше, чем типичная команда сможет получить от нескольких лицензий на Rational Rose.
Jeremy D. Miller
Перевод Алексея Нестерова
Компьютерная газета. Статья была опубликована в номере 34 за 2005 год в рубрике программирование :: разное
