Наиболее недопонятый среди разработчиков подход к разработке
Зачем великие умы придумали парное программирование? Почему его используют и, ещё важнее, почему его не используют повсеместно и всегда? Зачем руководителей проектов и команд разработки обучают основам этого подхода на сертификации Disciplined Agile?
— Любопытный читатель
Парное программирование — это методология разработки программного обеспечения, при которой два программиста работают "за одним компьютером", обмениваясь мнениями, идеями и знаниями для достижения наилучшего результата разработки. Вместе они решают задачи, подбирают алгоритмы, анализируют код и ищут ошибки.
В парном программировании каждый из программистов может играть свою роль, например, один пишет код, а другой следит за качеством кода, обнаруживая ошибки и совершенствуя алгоритмы.
Этот подход может использоваться в большинстве языков программирования и может применяться на всех этапах жизненного цикла программного обеспечения. Однако, как и всегда, есть свои ограничения. На первом и самом важном из которых остановимся сразу: необходимость наличия двух программистов.
Для выполнения парного программирования нужно иметь двух программистов, которые могут слаженно работать вместе.
Во-первых, это может быть существенным ограничением для компаний, которые не имеют достаточного числа программистов для того, чтобы посвящать сразу двух сотрудников в одну и ту же задачу. И плевать на то, что они закрывают риски того, что один заболеет или умрёт. Это случается не так часто, а задачи в основном не такие срочные чтобы нельзя было попросить погрузиться и доделать кого-то другого.
Во-вторых, разработчики должны “слаженно работать вместе”. Когда работает один человек, никто не видит его внутренних конфликтов, да и каждый умеет в конечном счёте с собой договариваться. Когда работают два человека — конфликтов не избежать. Очень много фольклора, обобщающего разработчиков всех языков, как будто они все одинаковые, про то какие они антисоциальные и “противные”. Веря в этот фольклор (может быть совсем безосновательно) руководители организаций не стремятся объединять двух “противных социопатов” в одну эффективную рабочую ячейку.
В-третьих, даже без конфликтов и прочих перипетий человеческих отношений многие люди любят работать в одиночку. Не обязательно потому, что они ненавидят людей. Просто так комфортнее. Возможно, даже профессия была выбрана в том числе по этой причине.
Несколько слов о самых распространённых недопониманиях в парном программировании
Первое это то, что оно занимает больше времени, поскольку два человека работают над одним и тем же кодом
Хотя парное программирование может занять больше времени на начальных этапах производства, в долгосрочной перспективе оно, если применено правильно, ускоряет разработку в том числе за счёт уменьшения количества переделываний, уменьшает количество ошибок в коде, сокращает время исправление ошибок, улучшает структуру кода. Во многом за это его и любят.
Отметив это, имеем новое ограничение: парное программирование наиболее эффективно для средних и больших задач, в средних или больших проектах или, ещё лучше, при работе в потоках создания стоимости (Value Stream), когда есть фиксированная команда, работающая над продуктом, а не проектом, часто на протяжении нескольких проектов или множества задач подряд.
Ещё одно распространённое недопонимание — это то, что парное программирование подразумевает, что один программист пишет код, а другой просто смотрит
На самом деле изначальная задумка как раз в том, чтобы оба программиста активно участвовали в процессе: обсуждали различные подходы и алгоритмы; принимали решения совместно; уравновешивали лень и перфекционизм друг друга; вдвоём отслеживали очевидные и не очень ошибки, которые один разработчик может легко пропустить из-за “зашоренности”; следили за структурой и “архитектурой” кода; не позволяли друг другу идти на костыльные компромиссы и “халтурить”, а если халтурили, то с хорошим обоснованием риска и эффективности таких решений.
В далёкие времена парное программирование требовало, чтобы один разработчик практически буквально сидел на ручках у другого и вместе они пристально смотрели в 14 дюймовый ЭЛТ монитор. Сейчас такое неудобство легко решается техническими средствами, например, второй монитор или вторая пара мониторов для второго разработчика и включённая функция дублирования экрана, при этом это не замена собственного ПК, на котором второй разработчик гуглит, проверяет тезис, прототипирует, рыщет stackoverflow и так далее пока первый дописывает свежеобсужденный алгоритм. При работе в виртуальной геораспределённой команде стандартным решением является демонстрация экрана и видео-конференц-связь.
Отсюда вытекают новые ограничения. При работе в офисе требуется совместное размещение — рядом или напротив, больше мониторов, а они стоят денег, и ,возможно, специфическое устройство переключения видеосигнала. В виртуальной команде — приложения для общения и демонстрации экрана своего ПК.
Третье распространённое недопонимание — инструменты непрерывной интеграции и системы управления версиями (в современном мире в первую очередь, конечно, распределённые) решают ту же проблему, для которой применяют парное программирование
Но на практике это совершенно разные инструменты, созданные для решения совершенно разных задач, а сравнение с ними парного программирования возникает из-за неверного понимания выполняемых этими инструментами функций.
Суть непрерывной интеграции в регулярном объединении рабочих копий информации (документов или кода ПО) в основную, главную (мастер) версию.
Представьте группу юристов, работающих над двухсот пятидесяти страничным договором: разные главы у разных юристов. Если итоговое объединение состоится в самом конце, когда все юристы закончили свои главы, не избежать нестыковок или дублирования информации. Исправление такого ёмкого документа, рождённого большой командой, может занять огромное количество времени. Если же юристы будут собирать мастер-документ с самого начала и отслеживать стройность, слаженность и непротиворечивость информации в документе, предоставлять замечания с самой первой версии по “дефектам” документа ответственным за главы юристам, то к моменту компиляции всего документа большая часть озвученных выше проблем будет решена в рабочем порядке в ходе его составления.
Важно заметить, что практики и инструменты непрерывной интеграции подразумевают использование систем контроля версионности👇🏻
Системы контроля версионности используются для хранения версий изменяющейся информации (документов, кода ПО, снимков лёгких пациента и так далее). Важными свойствами таких систем является логирование действий, как минимум: кто, когда и что именно изменил.
Продолжая пример выше, каждый из юристов имеет свою копию мастер-документа и рабочую версию главы, над которой трудится. Каждый юрист может получить последние принятые изменения в мастер-документе и убедится, что разрабатываемая глава всё ещё выровнена по смыслу и согласуется с другими главами и структурой всего документа. У всех юристов есть необходимость править общие главы, например, “термины и определения” или “общие положения”, на которые они могут ссылаться. Таким образом, согласованно с друг другом юристы могут “разрешать конфликты” общих блоков текста и “принимать” варианты, удовлетворяющие всех участников разработки договора.
Стоит отметить важный момент: одна из самых распространённых систем управления версиями git, по словам её автора, была создана в первую очередь для себя с целью минимизации всякого общения с соучастниками разработки, так как автор считает себя интровертной личностью. Согласованность работы над общим проектом при этом реализуется набором инструментов и строгим разделением прав.
Как видно ни практики и инструменты непрерывной интеграции, ни системы контроля версионности не имеют ничего общего с парным программированием, но полезно дополняют друг друга. Основное отличие в том, что парное программирование направлено на повышение живого общения (которого нет при самостоятельной разработке одним разработчиком), сравнение двух точек зрения, обсуждения вариантов решения поставленной задачи и принятия решений для порождения качественного инкремента кода, в то время как непрерывная интеграция и системы контроля версий работают с уже рождёнными инкрементами и зачастую, наоборот, совсем не требуют никакого общения.
В итоге
Какие плюсы подхода
- Улучшение качества кода — два человека работают вместе над кодом, его структурой и алгоритмами, обнаруживают и устраняют ошибки на ранних этапах разработки;
- Значительное ускорение процесса разработки в долгосрочной перспективе;
- Интенсивный обмен знаниями как в предметной области индустрии, так и в самом искусстве программирования.
Когда применяется парное программирование:
- когда важно распространять и сохранять критически важную информацию и опыт. Парное программирование позволяет (или заставляет) программистам обмениваться знаниями и опытом по ходу написания кода;
- при работе над ПО, имеющим экзистенциальную значимость или высокие риски: медицинское ПО; авионика; встраиваемое ПО в тяжёлые машины и механизмы, которые, если работают неправильно, могут травмировать или убить; финансовые приложения, которые, если работают неправильно, могут принести финансовый ущерб организации или её клиентам, а также репутационный ущерб, который порой страшнее финансового и так далее;
- в гибком производстве, когда скорость реакции на изменения рынка имеет критическое влияние на жизнеспособность организации и её продукта;
- когда есть время и желание попробовать новое с товарищем, квалификацию которого уважаешь и хочешь чему-то у него научиться или передать свои знания и навыки менее опытному коллеге.
Какие ограничения мешают применять парное программирование:
- Необходимость наличия двух программистов, работающих буквально над одной задачей;
- Дополнительные затраты на оборудование или программное обеспечение;
- Замедление производства ПО в первое время при внедрении парного программирования с нуля. Два программиста должны сработаться, скоординировать свои действия, что может занять больше времени, чем если бы они работали над проектом по отдельности;
- Парное программирование требует хорошей культуры и коммуникации между двумя программистами. Если они не могут эффективно общаться, то это может привести к конфликтам и проблемам в работе;
- Неподходящее сочетание личностей — некоторые программисты не могут совместно работать из-за различных личностных характеристик;
- Нежелание опытных взрослых членов команды экспериментировать с подходами к разработке, в том числе из-за непонимания и нежелания понять, как они работают. Отсутствие любознательности. Желание “работать как работалось”;
При написании статьи использовался ChatGPT 2, а также материалы и публикации Disciplined Agile: https://www.pmi.org/disciplined-agile/