Парное программирование означает, что вам не нужна проектная документация?
В парном программировании опыт каждого члена команды может быть распространен на нового участника. Этот опыт всегда синхронизирован с кодом, потому что "старший" пары знает, как работает код и каков дизайн.
Так что же полезного в проектной документации в этом случае?
ОБНОВИТЬ
Я не имею в виду никакого дизайна, я не имею в виду никакой документации. С командой, которая занимается парным программированием, я думаю, что все одноразовые, потому что все знают код. Если старший разработчик уходит, я думаю, что всегда есть хотя бы один человек, который знает код, потому что опыт был передан ранее.
16 ответов
Что делать, если ваша команда превышает 2 человека?
Только то, что два человека знают часть системы, не означает, что она не должна документироваться.
И я был бы рад узнать, что мне не нужно помнить каждую крошечную деталь системы только потому, что она хранится нигде, кроме как в моей голове.
Для небольшой системы это может сработать, но с ростом системы вы ограничиваете себя и своих коллег. Я предпочел бы использовать объем памяти для новой системы, чем помнить все о старой системе.
Набор результатов должен решаться независимо от того, используете ли вы парное программирование или нет.
Через шесть месяцев или два года все вовлеченные люди могут быть в другом проекте (или другой компании). Хотите иметь возможность вернуться и использовать проектную документацию? Затем произведите это. Если вы не хотите возвращаться, или дизайн достаточно прост, чтобы с помощью спецификаций и кода вы могли понять его без помощи явного проектного документа, тогда вы можете пропустить его.
Но не надейтесь, что два человека объяснят вам дизайн через год.
Вы когда-нибудь играли в "телефон"? Я не думаю, что вы должны играть в нее со своей кодовой базой.
Техническое обслуживание. Вы не можете ожидать, что команда останется статичной, потому что там не будет новых участников или потеря старых членов. Проектная документация гарантирует, что те, кто является новичком в проекте, которые должны поддерживать его долгие годы, имеют информацию о принятых решениях, почему был выбран подход и как он должен быть реализован. Для долгосрочного успеха проекта очень важно иметь эту документацию, которая может быть предоставлена посредством комбинации традиционных документов, комментариев источника, модульных тестов и различных других методов.
Я не вижу, что парное программирование делает проектную документацию устаревшей. Я сразу должен думать о факторе грузовика. Конечно, старший может знать, что такое дизайн. Но что происходит, когда он болен? Что происходит, когда его сбивает грузовик? Что если его уволят?
Парное программирование распространяет знания, но никогда не повредит документированию этих знаний.
Кто знает о первом написанном коде? Ответ никто не знает, потому что он не был написан. Причина, по которой он не был написан, состоит в том, что никто не знает, что делать, отсюда необходимость в проектном документе.
Как вы говорите, опыт людей может быть синхронизирован с кодом. Но проектные решения не все отражены в коде - есть только выбор.
По моему опыту, чтобы по-настоящему понять, почему код спроектирован таким, какой он есть, вам нужно знать о тех вариантах дизайна, которые не были выбраны, о подходах, которые были опробованы и потерпели неудачу и т. Д. Вы можете надеяться, что цепочка "китайского шепота" передает это правильно, учитывая, что в коде нет записи об этом для обновления памяти или исправления ошибок...
... или вы можете написать некоторую документацию по дизайну и как он был достигнут. Таким образом, в будущем программисты по техническому обслуживанию не допустят, чтобы они оказались в тупике.
Парное программирование - это всего лишь два человека, использующих один компьютер. Само по себе это ничего не говорит о том, какую методологию проектирования использует пара (ы).
Парное программирование в рамках " Экстремального программирования" означает следование рекомендациям по экстремальному программированию для проектирования. Обычно это включает сбор и кодирование "пользовательских историй". Эти истории затем будут стоять на месте другой проектной документации.
Зависит от того, что вы подразумеваете под "конструкторской документацией".
Если у вас есть функциональные тесты - особенно тесты на основе поведенческой разработки (BDD) или тесты Fitnesse или FIT, то они, безусловно, являются формой "активной документации"... и, безусловно, имеют ценность, а также являются регрессионными тестами.
Если вы пишете истории пользователей и разбиваете их на задачи и записываете эти задачи на карточках для пар, то вы делаете документацию...
Это две основные формы документации, которые я использовал в командах XP, которые объединяются для всего производственного кода.
Единственный другой документ, который я нахожу довольно удобным, - это набор из примерно половины страницы, показывающий людям, как настроить среду сборки для машины разработки. Вы должны поддерживать список по мере его использования.
Хорошо, если вам нужна программа для работы с электронными таблицами вместо текстового редактора, используйте документацию по дизайну:-)
ХР, парное программирование, гибкость и т. Д. Не означают, что у вас нет плана, это просто гораздо менее подробный план (на микроуровне) того, что происходит. Варианты использования, которые выбирает пользователь, - это больше дизайн, и это больше живой документ, чем с другими стилями дизайна / программирования.
Не попадайтесь в ловушку, потому что вы делаете что-то "крутое", что вам больше не нужны хорошие практики - действительно, этот стиль программирования требует большей дисциплины, а не меньше, чтобы быть успешным.
Парное программирование включает только ваше кодирование и логический аспект.
Но документация это хорошая практика. Всегда делаю документацию...
Парное программирование - это возможность для группы избежать необходимости тратить большую часть времени проекта на документирование всего. Но потребность в документации зависит от того, насколько хорошо вы помните важные вещи и насколько хорош ваш код. Вы все еще можете захотеть много документации, если с кодом сложно работать.
Вы можете попробовать несколько экспериментов:
- Документируйте пару небольших частей дизайна и отметьте, как часто вы должны ссылаться на него.
- Документируйте вещи, с которыми всегда тяжело работать.
Я сторонник и фанат документации. Парное программирование не требует "одного старшего разработчика". По моему опыту в парном программировании, разработчики всех уровней объединены в пару с целью быстрого развития. Я много раз работал с младшими разработчиками и менял на клавиатуре. Я много раз работал со старшими архитекторами и менял на клавиатуре. Документация по-прежнему необходима, особенно с вашими основными компонентами и базой данных.
Кодовая база может быть настолько большой, что вы не сможете вспомнить каждую деталь того, что вы намеревались реализовать. Ссылка полезна в этом случае.
Кроме того, вам нужен дизайн, если вы взаимодействуете с другими компонентами и т. Д.
Нет И отсутствие парного программирования не означает, что вам нужна документация. Документация необходима! Как это выглядит, может удивить вас!
Гибкая команда решит, когда и какая документация необходима. Хорошее эмпирическое правило, если никто не собирается читать это, не пишите это. Не увлекайтесь размышлениями об артефактах водопада, предоставляя артефакты, потому что так говорит руководитель проекта.
Большинство думает о документации как о чем-то, что вы делаете с Word. Если гибкая команда работает должным образом, сам код с TDD (разработкой, управляемой тестами) будет иметь набор автоматизированных тестов, которые документируют и обеспечивают выполнение требований. Изображение, документация, которая синхронизируется с кодом... и остается такой.
Сказав это, спаривание помогает области знаний, приложений, практики и навыков распространяться через команду очень быстро. Сопряжение также помогает команде следовать инженерным практикам, включая TDD и другие автоматизированные тесты. В результате приложение остается работоспособным, и будущие изменения легко осуществить.
Итак, в итоге, парное программирование дает лучшую документацию. Это не устраняет документацию (хотя вы не сможете найти документ Word).