Программеры, есть вопрос.

[Chyslyvchyk]

Скажем, вы программер и есть у вашей конторы три проекта. В каждом проекте есть кусок кода, который одинаковый для всех проектов. Если в нем произойдут какие-то изменения, они должны быть сквозными для всех проектов. Как вы это организуете?

[evilgene]

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

[Chyslyvchyk]

Один из наших девелоперов считает, что нужно оставить этот кусок кода отдельным модулем (юнитом и т.д.) в каждом проекте и слать друг другу мыло (6 девелоперов) каждый раз, когда кто-то что-то меняет. И потом вручную добавлять изменения.

[evilgene]

Один из наших девелоперов считает, что нужно оставить этот кусок кода отдельным модулем (юнитом и т.д.) в каждом проекте и слать друг другу мыло (6 девелоперов) каждый раз, когда кто-то что-то меняет. И потом вручную добавлять изменения.

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

[evilgene]

Если серьезно, то это зависит от организации разработки. Подозреваю, что ни юнит тестов ни постоянной интеграции у вас нет? В таком случае если кто-то втихаря изменит функционал в общей библиотеке, может поломать другие проекты. И никто об этом до вечера перед релизом может не узнать. Тогда да, нужно всем сообщать об изменениях, чтобы люди сразу протестили. Опять же, может быть для каждого проекта этот кусок кода в будущем придется подстраивать, так что он станет со временем разным. Доводы этого программера в студию! Мы тут на гудее быстро решим кто прав, кто виноват. (если тему на арену раньше не снесут)

[sudo]

Re: Программеры, есть вопрос.

Не совсем понятно - общий код надо компилировать в разных продуктах или он отдельным модулем компилируется или его вобще не надо компилировать?

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

Кстати, поделитесь какую платформу выбрали для миграции продукта? А то народ ведь старался, советы давал...

[Созерцающий]

Можно с беплатных начать CVS, SVN, а потом что то платное, если работа станет серьезной - Clearcase ....

[Chyslyvchyk]

Re: Программеры, есть вопрос.

Не совсем понятно - общий код надо компилировать в разных продуктах или он отдельным модулем компилируется или его вобще не надо компилировать?

Компилировать в разных продуктах.

Похоже, что у вас на фирме не хватает серьезного team лидера со нормальными знаниями, необходимыми для настройки version control

Не хватает. Тим лидеры все не ИТ-шники. А version control притащили, установили и бросили. Я ковыряюсь потихоньку. Вот решили с девелопером другого продукта вынести куски кода общие для обоих продуктов, так мне третий девелопер по рукам сегодня надавала. Сказала, что у всех должно быть все свое и изменения все вносить нужно вручную...

Кстати, поделитесь какую платформу выбрали для миграции продукта? А то народ ведь старался, советы давал...

Java.

Если серьезно, то это зависит от организации разработки. Подозреваю, что ни юнит тестов ни постоянной интеграции у вас нет? В таком случае если кто-то втихаря изменит функционал в общей библиотеке, может поломать другие проекты. И никто об этом до вечера перед релизом может не узнать. Тогда да, нужно всем сообщать об изменениях, чтобы люди сразу протестили. Опять же, может быть для каждого проекта этот кусок кода в будущем придется подстраивать, так что он станет со временем разным.

Ни юнит тестов, ни постоянной интеграции нет. Был вытащен кусок кода в отдельный юнит и запихнут в отдельную папку в version control. Папка не обновляется ежедневно, только по надобности - если кто-то внес изменения и оповестил всех. Ну, или если сам пошел и проверил. Билд делается на машине каждого девелопера, так что пока проблема с выявлением изменений перед релизом отпадает (рождается куча других - но это отдельная тема); не обновил папку - нет изменений.

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

Мои вопросы могут быть глупыми. Не пинайте сильно, я только учусь.

[evilgene]

А ваша зона ответственности один из этих проектов или несколько (может все три?) Если один, то я бы не заморачивался. Хотя бы в одном весь дублирующийся код вынесите в одно место. И то без четко поставленной практики тестирования и интеграции это затея опасная. А вы сразу за три беретесь. Неудивительно, что другие программеры испугались

[svladimir]

Re: Программеры, есть вопрос.

Не совсем понятно - общий код надо компилировать в разных продуктах или он отдельным модулем компилируется или его вобще не надо компилировать?

Компилировать в разных продуктах.

Похоже, что у вас на фирме не хватает серьезного team лидера со нормальными знаниями, необходимыми для настройки version control

Не хватает. Тим лидеры все не ИТ-шники. А version control притащили, установили и бросили. Я ковыряюсь потихоньку. Вот решили с девелопером другого продукта вынести куски кода общие для обоих продуктов, так мне третий девелопер по рукам сегодня надавала. Сказала, что у всех должно быть все свое и изменения все вносить нужно вручную...

Кстати, поделитесь какую платформу выбрали для миграции продукта? А то народ ведь старался, советы давал...

Java.

Если серьезно, то это зависит от организации разработки. Подозреваю, что ни юнит тестов ни постоянной интеграции у вас нет? В таком случае если кто-то втихаря изменит функционал в общей библиотеке, может поломать другие проекты. И никто об этом до вечера перед релизом может не узнать. Тогда да, нужно всем сообщать об изменениях, чтобы люди сразу протестили. Опять же, может быть для каждого проекта этот кусок кода в будущем придется подстраивать, так что он станет со временем разным.

Ни юнит тестов, ни постоянной интеграции нет. Был вытащен кусок кода в отдельный юнит и запихнут в отдельную папку в version control. Папка не обновляется ежедневно, только по надобности - если кто-то внес изменения и оповестил всех. Ну, или если сам пошел и проверил. Билд делается на машине каждого девелопера, так что пока проблема с выявлением изменений перед релизом отпадает (рождается куча других - но это отдельная тема); не обновил папку - нет изменений.

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

Мои вопросы могут быть глупыми. Не пинайте сильно, я только учусь.

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

Еще было бы здорово установить automatic build system. Например cruise control, который раз в день будет собирать все три проекта и, если что не так, будет слать гневные письма. В таком случае есть гарантия что в любой момент времени у вас есть чтонибудь хотя бы компилирующееся. А не компилирующееся на машине девелопера Васи.

Еще чем хороши всякие SVN и т.п. - можно подписаться на изменения в коде. И тогда тебе приходить письма, ежели кто поменял код в котором ты кровно заинтересован.

Еще можно разбить куски общего кода на что нибудь элементарное, чтобы интерфейс точно со временем не менялся. Например десяток классов с набором статических методов. Или простейшие объекты с минимумом логики. Тогда каждый проект сможет собирать нужную ему функц-ть из common кусочков. А если ему нужно что-то свое - то вместо изменения уже сущ-й тяжеловесной функц-ти можно будет просто добавить новый метод/класс.


Это все мой личный опыт, не претендующий на универсальность и правильность

[Chyslyvchyk]

А ваша зона ответственности один из этих проектов или несколько (может все три?) Если один, то я бы не заморачивался. Хотя бы в одном весь дублирующийся код вынесите в одно место. И то без четко поставленной практики тестирования и интеграции это затея опасная. А вы сразу за три беретесь. Неудивительно, что другие программеры испугались

В том то и дело, что я разрываюсь между всеми ( проектов четыре: два громоздких и два маленьких, но я два маленьких за один считаю ). Официально я несу ответственность за два маленьких и половину одного из громоздких. Девелопер второго громоздкого - новенький, и за всеми ответами на все вопросы ходит ко мне ( который по счету...). Мне надоело, что во всех проектах громадное количество нестыковок и упущений. И новенькие вечно от этого страдают. Да и мы тоже. Не согласна девелопер половины моего проекта. Но так как она работает в компании дольше меня и новенького, математика проста...

[Chyslyvchyk]

Re: Программеры, есть вопрос.

Еще было бы здорово установить automatic build system. Например cruise control, который раз в день будет собирать все три проекта и, если что не так, будет слать гневные письма. В таком случае есть гарантия что в любой момент времени у вас есть чтонибудь хотя бы компилирующееся. А не компилирующееся на машине девелопера Васи.

А вот эта идея моему тим лидеру не понравилась. Он попросил benefits такого подхода указать. А мне в голову кроме как удобство и облегчение работы девелоперов ничего не лезет. Я пока не разбиралась сильно с этим вопросом - надо порыскать по нету. К тому же у нас есть практика изменения third party components и тим лидер считает, что девелоперы другой тим могут внести изменения в код компонент на билд сервере и потом будут проблемы с релизом.

Еще чем хороши всякие SVN и т.п. - можно подписаться на изменения в коде. И тогда тебе приходить письма, ежели кто поменял код в котором ты кровно заинтересован.

Хм, а вот это очень хорошо.

[xelaz]

Вообще SVN хорош тем, что там бранчи можно делать а потом делать merge на полуавтоматической основе.
Кроме того, с помощью SVN можно отслеживать изменения на уровне кода, чего не так просто с файлами, отсылаемыми по почте,
да и откатить на SVN можно обратно.

Можно сделать индивидуальный бранч для каждого девелопера и работать над проектами в этих бранчах.
Основа для всех - некий tagged release, через некоторое время вносятся изменения из бранчей в release и каждый должен сделать
merge из общей ветки к своей. Естественно, что кто-то должен отвечать за обратную интеграцию всех бранчей в единую ветку.

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

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

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

Но все описанное - это уже процесс. И он требует отдельного и серьезного обсуждения, с принятием решений и согласием каждого действовать в принятых рамках.
Нужно просто собрать митинг, может не один раз, и очень подробно обсудить процессы разработки и способы внесения изменений в код.
Может быть выработать формальный документ, от которого и отталкиваться.
У меня сейчас такая же проблема нависла - на полностью контролируемый мною код надсадили индусов-"экспертов", которые мне шлют изменения по почте.
Своими действиями они мне все ломают, не советуются, не знают что в коде и для чего, а пытаются еще что-то изменить.
Я их заворачиваю обратно, и собираюсь вынести вопрос внесения изменений на повестку дня ибо это стало уже серьезным препятствием для разработки, и вообще-то доставать.
Кроме того, доходит до абсурда: они мне присылают незавершенный код, который не то что работать правильно, но даже компилироваться не будет.
А у меня полностью работающая система, используемая в производстве. И что мне с их кодом делать? Так что бранчи и еще раз бранчи.

[evilgene]

А ваша зона ответственности один из этих проектов или несколько (может все три?) Если один, то я бы не заморачивался. Хотя бы в одном весь дублирующийся код вынесите в одно место. И то без четко поставленной практики тестирования и интеграции это затея опасная. А вы сразу за три беретесь. Неудивительно, что другие программеры испугались

В том то и дело, что я разрываюсь между всеми ( проектов четыре: два громоздких и два маленьких, но я два маленьких за один считаю ). Официально я несу ответственность за два маленьких и половину одного из громоздких. Девелопер второго громоздкого - новенький, и за всеми ответами на все вопросы ходит ко мне ( который по счету...). Мне надоело, что во всех проектах громадное количество нестыковок и упущений. И новенькие вечно от этого страдают. Да и мы тоже. Не согласна девелопер половины моего проекта. Но так как она работает в компании дольше меня и новенького, математика проста...

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

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

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

[Strannik]

у нас так, 3 проекта работают на одном code base
у каждого своя бранч в SVN, trunk используется для того чтоб сводить код вместе
есть расписание по которому каждый проект берет код из транка и мерджит его в свой бранч
потом прогоняет regression tests и если все работает отдает билд двум другим проектам, чтоб те прогнали свои тесты
если два других проекта дают добро - код заливается в транк и наступает очередь следующего проекта

в принципе система хорошая если merge делается часто, и если на всех трех проектах работают не идиоты
у нас на одном проекте работают идиоты (индусы и китайцы), в результате их последний мердж они за 2 или 3 недели так и не смогли закончить, а предидущий мне пришлось за них делать

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