Как стать автором
Обновить

Комментарии 9

Подождите, а сейчас точно 2024ый год, а не 2001ый?

Мне казалось, что от идеи парного программирования на постоянной основе ещё лет десять назад отказались, потому что оно только мешает.

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

В принципе, все практики ХР — это не панацея, применять их следует, отталкиваясь от задачи и команды. Также необязательно всегда кодить в парах, но это хорошие профилактика замыливания взгляда и способ, когда нужно писать что-то нестандартное, например. Один прокладывает направление, держа код в голове «целиком», а второй реализует конкретный кусочек. А как вы считаете, как следует практиковать парное программирование?

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

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

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

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

У меня другой опыт

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

И удалёнка этому никак не мешает

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

Суть парного программирования в том, что в пару ставят быстрого чувака и медленного. Быстрый помогает медленному, за счёт чего медленный становится быстрее. Естественно, что быстрый при этом становится медленнее. Поэтому медленным разработчикам это нравится, а быстрым - нет. Если же смотреть со стороны и принять за единицу продуктивность медленного программиста, а продуктивность быстрого за 2, то при парном программировании получим продуктивность в 1.5. Если же посадить их работать отдельно, то скммарная продуктивность будет 1+2=3

Расписали достоинства, принципы, но забыли упомянуть, что такое это ваше экстремальное программирование, и чем оно отличается от обычного. В одном из пунктов вместо "экстремального" оно вдруг становится "парным", что наводит на мысли, что это одно и то же. Но это настолько неявно указано, что никак нельзя быть уверенным в этом.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий