Есть два типа разработчиков — одни любят парное программирование, а другие — нет. Конечно же, это — инструмент со своими сильными и слабыми сторонами. Его используют как крупные корпорации, так и небольшие стартапы.
В блоге T1 Cloud мы рассказываем о том, что происходит в сфере облачных технологий, облачной разработки и за её пределами. Сегодня мы решили обсудить различные точки зрения на эффективность парного программирования, а также поговорить о методиках, призванных перекрыть недостатки подхода.
Кто и почему пишет код в парах
Такой подход используют уже не первый десяток лет, хотя его происхождение достаточно туманно. Одни убеждены, что первопроходцем в этой области был американский инженер Ларри Константин. В 1970-х он сформулировал концепцию Dynamic Duo, которая гласит, что пара программистов решит проблему быстрее, чем три разработчика по отдельности. С другой стороны, говорят, что ученый в области теории вычислительных систем и автор книги «Мифический человеко-месяц» Фредерик Брукс практиковал совместное программирование еще в 50-х.
Сегодня «разработку в четыре руки» применяют в компаниях из разных сфер — например, банки, автопроизводители, а также крупные соц.сети. Кроме корпораций, концепция находит место в стартап-сообществе. Ярые апологеты убеждены, что парное программирование это must have для молодых компаний и используют методику для проверки знаний соискателей на собеседованиях.
Но она находит применение и других, самых разнообразных, сценариях и в некоторых случаях даже позволяет командам пропускать этап code review. В то время как один разработчик находится у руля и концентрируется на решении задачи, второй — отсматривает код на ходу, проводит рефакторинг практически в прямом эфире и формирует альтернативную точку зрения на проблему.
Парное программирование также служит инструментом для обучения и менторства. «Разработка в четыре руки» помогает быстрее стажировать молодые кадры, так как старший специалист получает возможность в боевом режиме познакомить новичка с фреймворками и другими корпоративными нюансами. Именно по этой причине pair programming практикуют в банковском холдинге Wells Fargo. Методика помогает улучшить взаимопонимание в команде, особенно если все её участники попробуют поработать в парах друг с другом.
Дополнительно коллаборация еще и сокращает риски, связанные с «фактором автобуса». Этот параметр определяет число разработчиков, после ухода которых проект не смогут довести до конца оставшиеся участники команды. Когда сразу несколько коллег понимают, на каком этапе находится тот или иной продукт, они при необходимости могут подхватить разработку.
Метод парного программирования у всех на слуху — разработчики пишут о нем в своих блогах, обмениваются опытом в социальных сетях и на тематических площадках. Но в ИТ-сообществе все же есть специалисты, которые считают методологию неудобной, а интерес к ней — чрезмерным.
Что здесь может быть не так
Pair programming упрощает реализацию небольших функций, но плохо подходит для запуска систем с сотнями интерфейсов и комплексной архитектурой. В первую очередь потому, что парная разработка в таких масштабах увеличивает издержки, так как над каждым вопросом трудятся два инженера.
Также существует мнение, что парное программирование мешает опытным разработчикам, которые держат идею и структуру решения в уме, а сама концепция «четырех рук» все же не способна заменить ревью кода. Нередки ситуации, когда коллега делает акцент не на качестве решаемой задачи, а на особенностях синтаксиса, и привносит в оценку собственные привычки. Это одна из причин, почему к оценке кода привлекают людей, которые не имеют отношения к его написанию. Очевидно, что свежим взглядом проще искать недостатки.
Свой отпечаток на качество кода накладывает и тот факт, что разработчикам может быть психологически сложно работать с кем-то в паре. У каждого свой темп работы — кто-то предпочитает обдумать код за чашкой кофе, а кому-то нужно походить кругами по кабинету — и некоторым некомфортно, когда за ними постоянно наблюдают. На этот счет даже проводили исследования. Еще в 2013 году профессор из Гарварда Итан Бернштейн отмечал, что постоянное наблюдение за работой коллег снижает их продуктивность. К аналогичным выводам пришла команда нейробиологов из Медицинской школы Брайтона и Сассекса тремя годами позднее. Ситуация усугубляется, если разработчики в паре не сошлись характерами.
Также можно встретить мнение, что подход pair programming наиболее эффективен, когда программисты сидят за одним компьютером — так им проще взаимодействовать. Однако сейчас, когда удаленная работа становится новой нормой, а распределенные команды еще более распределенными, может быть сложно посадить двух разработчиков рядом. Да, можно организовать весь процесс онлайн, но на рынке не так много инструментов, позволяющих без всяких затруднений взаимодействовать с кодовой базой в дистанционном формате.
Хотя некоторые ключевые фигуры в ИТ-индустрии убеждены, что парное программирование в полной мере раскрывается именно на удаленке. Например, технический директор GitHub Джейсон Уорнер в одном из выпусков подкаста Deep Collaboration заметил, что в дистанционном формате инженеры не отвлекаются на офисную суету, а работают в комфортной для них обстановке.
О том, что этот вопрос актуален, говорит большое количество выпускаемой литературы, которая помогает освоить практики парного программирования на удаленке. Примером может быть книга «Practical Remote Pair Programming», затрагивающая тонкости взаимодействия в распределенных командах. Но если вы хотите еще глубже погрузиться в особенности «парной разработки», можете обратить внимание на книгу «Practical Pair Programming» от издательства O’Reilly или справочник «Pair Programming Illuminated».
Что с перспективами
ИТ-сообщество разделилось во мнениях касательно парного программирования. Но сегодня прорабатывают новые подходы к методологии, которые должны сгладить острые углы и усилить преимущества. Примером такой концепции может быть collaborative-adversarial pair programming (CAP). В отличие от традиционного подхода, в случае CAP девелоперы работают плечом к плечу только на этапах проектирования и тестирования. В остальное время один разработчик пишет код, а второй — тесты. В некоторых случаях CAP может сократить время и стоимость разработки на 50%, по сравнению с традиционным подходом.
Возможно, в будущем роль второго разработчика будет играть виртуальный помощник. Некоторые системы такого рода уже умеют анализировать текущий код и предлагать новые строки в зависимости от контекста. Однако им предстоит пройти еще долгий путь — даже сами авторы одного из сервисов говорят, что его нельзя назвать надежным компаньоном для парного программирования. Система не проверяет сгенерированный код на правильность, поэтому он вообще может не компилироваться.
Больше материалов про разработку, системное администрирование и open source в облаке — в нашем блоге на Хабре. Подписывайтесь, чтобы не пропустить свежие публикации: