[comp.prog.thoughts] Так вот о парном программировании

Мой недавний спор с Сергеем Зефировым произошел во время обсуждения парного программирования. Толчком к которому послужило исследования эффективности этого подхода, о результатах которого было упомянуто здесь.

Складывается впечатление, что по отношению к парному программированию разработчики делятся на три категории:

• это классная штука,
• это полная фигняерунда,
• не знаю, не пробовал.

Поскольку в последний раз в сеансе парного программирования я принимал участие в далеком 2002-м году (т.е. уже совершенно не разбираюсь в данном вопросе), то самое время высказать свое мнение по этому поводу ;) А мнение у меня такое – штука это хорошая, но очень неоднозначная и для массового применения не приспособленная. Теперь попробую это обосновать.

Начнем с того, что учиться программировать я начинал как раз в режиме парного программирования. На первом курсе у нас машинное время выделялось, наверное, всего две пары в неделю – и этого хватало, разве что, на выполнение задаваемых лабораторных работ. Но зато наш дисплейный класс с Robotron 1715 был не шибко престижным (в отличии от классов с Искрами и IBM XT-шками). Поэтому там всегда был один или два свободный компьютер, на котором можно было работать. И вот мы вдвоем-втроем устраивались за ним и коллективно писали свои первые более-менее серьезные программы.

Было здорово. Перед тем как что-то написать ты рассказываешь коллеге что ты собираешься сделать. Он тебя спрашивает: “А почему так, а не вот так?” Оба варианта сравниваются, иногда рождается какой-то третий вариант. Потом ты объясняешь, как ты будешь это делать. Тут тебе опять могут подсказать что-нибудь. Потом ты пишешь код и тебе подсказывают, что пора бы сохраниться, пора бы добавить вот эту штуку, пора бы избавиться от промежуточной заглушки и т.д.

Потом, потихонечку, практика парного программирования сошла на нет. Все-таки доступ к компьютерам становился все более и более свободным. Очередной заметный всплеск использования этой методики случился где-то в 1998-1999 годах, когда мы в КБСП сделали первую работающую версию SCADA Objectizer. Там был визуальный редактор/конструктор агентов и мнемосхем и при реализации АСУТП-шной системы мы частенько усаживались перед компьютером вдвоем-втроем чтобы сконструировать очередного агента. Было здорово.

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

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

Какие из всего этого я для себя сделал выводы?

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

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

В-третьих, уровень ответственности при парном программировании совсем другой. Ты не можешь просто так забить на работу и зависнуть в Интернете. Рядом с тобой коллега, время которого нужно ценить.

Это все хорошие стороны парного программирования. Но они даются не просто так.

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

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

Так же я не верю, что парное программирование подойдет для широкого круга задач. Скажем, я в последнее время приступаю к написанию кода только после многих дней (а то и недель) проектирования и рисования картинок на бумаге. Это работает, поскольку стоимость ошибки для меня слишком высока. Но такой режим не подойдет для парного программирования. Невозможно думать вдвоем. А когда я уже продумал все, то мне не нужен партнер для оформления моих идей в коде.

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

Но наличие большого количества “авральных задач” должно выглядеть подозрительно. Имхо, при нормальной, размеренной разработке их должно быть минимум. Даже при очень сжатых сроках (с любимой нынче датой готовности “вчера”) все равно выгоднее много подумать перед написанием кода, чтобы потом быстро сделать. С этой точки зрения в нормальной разработке парному программированию мест найдется немного.

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

Итак, в сухом остатке: для некоторых ситуаций парное программирование – это отличная штука, но она не может применяться ежедневно для всех без исключения задач. Хотя, если у вас с кем-то сложится настолько же продуктивный дуэт, как у Кернигана и Ричи – тогда совсем другое дело.

PS. Что-то мне подсказывает, что найти такого коллегу, как это произошло у Кернигана и Ричи, будет посложнее, чем хорошую жену :)