Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, <Аноним>, Вы писали:

А>>А сейчас я буду злиться по поводу всего прочитанного о "параллельной разработке"
WH>Ну чтоже давайте поговорим об этом.
А>>Во первых не соглашусь с meridian. Необходимость в параллельной разработке возникает не по причине большого количества разработчиков. На мой взгляд причины могут быть следующие:
А>>1. Несколько разработчиков знакомо с одним участком кода, и способны работать с ним. Этот принцип широко используется в концепции Экстремального Программирования.
WH>То что они способны работать с одним участком кода вовсе не значит что они должны работать с одним участком кода.
Почему же нет? Очень даже может быть. Все зависит от культуры отдела, от принципов работы. Почему Вы пытаетесь задать строго определенные догмы, которым должны следовать все разработчики? Это может не быть обычным явлением в компании. Но в некоторых ситуациях необходимость в этом может возникнуть.
Привожу пример: два разработчика знакомы с некоторым участком кода, так как разработали его вместе. К примеру в процессе парного программирования кстати интересно узнать, вы отвергаете данную практику?. Проходит некоторое время, и эти два программиста занимаются различными задачами. При этом эти задачи затрагивают именно этот участок кода. И не надо говорить что это плохая архитектура! Возможно это именно та ситуация, когда один разработчик ведет работу по основной деятельности, а другой — исследовательскую работу, которая в последующем вполне может быть проинтегрирована в ствол проекта. И что вы предлагаете делать? ждать одному из них, когда второй закончит работу с данным исходником?

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

WH>То что нормальные VCS могут это разруливать это вопрос отдельный.
Какой смысле реализовывать фукнцию, если она однозначно (по вашему мнению приводит к катастрофе)? И в чем же отдельность вопроса наличия функции параллельной разработки от непосредственно использования данной возможности?

А>>2. Разработчику необходимо проделать некоторую исследовательскую работу, которая не зависит от изменений, которые будут параллельно происходит в основном потоке проекта. Это скорее даже будет мешать (постоянно мерджить текущие наработки, хотя они никак не влияют на суть собственной работы).
WH>Иследовательская работа это вопрос совершенно отдельный. В этом случае делается бранч и там уже идут изменения. Но это уже не копание в одном файле, а в другой версии проекта. А мерж того что наиследовал этот программист с остальным проектом процесс в любом случае не тривиальный и может привести к серьезным конфликтам (в зависимости от глубины результатов исследования).
Не понял. Как же это так? Иследовательская работа может затрагивать тот же файл, что и основная! Да хоть один и тот же программист может работать сразу над двумя задачами, которые затрагивают один и тот же файл.(если уж вы так отвергаете возможность двух разработчиков иметь понятие об одном исходнике). Параллельно. Одновременно! Первые 4 часа рабочего времени — основная работа. Вторые 4 часа — исследовательская. И причем здесь бедный архитектор?

А>>3. Время между стабильными версиями проекта существенное. Возможность отбренчится от некоторого бейзлайна — очень удобна.
WH>Вот это я что-то не понял
Я имел ввиду, что необходимость в параллельной разработке может возникнуть по причине отсутствия стабильной версии в момент времени, программист хочет выполнить свою работу. А эта работа затрагивает файл, который является причиной нестабильности. Тогда программист использует для своей работы последнюю СТАБИЛЬНУЮ версию файла. А параллельно с этим последняя НЕСТАБИЛЬНАЯ версия данного файла доводится до ума. После того, как обе работы выполнены, поизводится мердж.
По сути это еще один пример

А>>Во вторых я в принципе не согласен с человеком, утверждающем, что параллельная разработки — это зло и бить нужно архитекторов.
WH>Тут нужно определиться с тем что является паралельной разработкой, а что нет.
А>>Просто бред. Причины смотрите выше. Архитектура и параллельная разработки. В упор не вижу связи. Без условно, архитектура вполне может быть НЕГАТИВНОЙ ПРИЧИНОЙ необходимости одновременной работы нескольких РАЗРАБОТЧИКОВ с одним ФАЙЛОМ исходного текста. Но это не есть параллельная разработки!
WH>Именно это я и говорил. Нечего двум программерам делать в одном файле. А связь с архитектурой тут такая что при плохой декомпозиции зоны ответственности разных программеров начинают пересекаться что приводит к необходимости писать в один фаил. А декомпозиция проекта на высоком уровне это как ни крути работа архитектора. И если он это сделал плохо то именно его и надо бить.
Мой ответ содержится в том, что я написал выше.

WH>ЗЫ SVN умеет и мержить и делать бренчи.
Замечательно я только рад