Общие библиотеки в многочисленной команде

Я не соглашаюсь с этим:

Непротестированный код дубликата лучше, чем общий непротестированный код (Вы повреждаете только один проект).

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

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

Теперь решить Вашу фактическую проблему: я подражал бы тому, что мы делаем с реальными сторонними библиотеками. Мы используем конкретную версию, пока мы не готовы, или вынужденные обновить. Я не обновляю все просто, потому что я могу - должна быть причина.

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

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

Вы могли опубликовать выпуски или привязать/перейти/отметить svn для помощи со всем этим.

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

Трещотка @Brian предоставляет некоторые превосходные инструкции для того, как выполнить Вашу библиотеку как проект в его ответе.

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

• Сделайте хорошего разработчика ответственным за разработку компонента
• Сделайте хорошего разработчика привратником для поддержания компонента
• Удостоверьтесь все обновления (были несколько), обратно совместимы
• Удостоверьтесь, что существует некоторая основная документация (или простое эталонное приложение) объяснение, как компонент должен использоваться
• Удостоверьтесь, что все разработчики знают, что компонент существует (!) и где они могут найти его (наряду с кодом, если они хотят рассмотреть его),

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

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

Мы имели дело с теми сценариями следующим образом:

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

2. У нас была малочисленная команда 10-12 разработчиков, выделенных поддержанию оперативной библиотеки и ее наборов тестов. Мы были также ответственны за выставление вызовов от других 1 100 разработчиков в компании о том, как пользоваться оперативной библиотекой, поэтому как можно предположить, мы были очень заняты.

3. Друг друга проект должен работать с версией оперативной библиотеки, с которой это, как известно, работает. Можно использовать ответвления управления версиями для тестирования новых выпусков оперативной библиотеки со старыми продуктами, чтобы удостовериться, что Вы не взламываете код, который работает. Если рабочая группа делает полное задание тестирования, это должно пойти очень гладко. Единственное время это когда-либо было действительно сложно для нас, было, когда базовый API, измененный, или когда мы утончаемся, завинтил что-то. Даже если Вы очень уверены в своем базовом тестировании, используйте ответвления для тестирования отдельных продуктов.

Рассматривайте разработку библиотек как любой другой продукт. Каждая библиотека имеет свой собственный репозиторий, свои собственные выпуски и номера версий. Скомпилированные и официально протестированные версии библиотеки также сохранены в репозитории. Функции документа и изменения от версии до версии.

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

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

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

Создайте Антикоррупционный уровень (DDD) для существующей библиотеки... это - только фасад.. и затем запишите модульный тест на этот антикоррупционный слой... Теперь, даже если бы кто-то обновляет/обновляет библиотеку, Вы знали бы, повреждается ли что-то путем выполнения модульных тестов...

Эти тесты могли также служить документацией контракта... и не каждого проекта, который должен пользоваться библиотекой, должен записать это анти-слой повреждения, если они используют ту же точную функциональность..

"Дублирование является корнем всего зла"

Звуки мне как Вы потребность:

• Репозиторий артефакта как Ivy, таким образом, можно было совместно использовать библиотеки и имеющий версию с отличием между версиями, которые являются стабильным API и, которые "назревают"
• Тесты для библиотек
• Тесты для проектов с помощью них
• Непрерывная система интеграции так, чтобы, когда несовместимость или ошибка представлены и проект и исходный разработчик библиотеки были уведомлены

Я думаю, что одна общая библиотека лучше, чем 3 дублирующихся (и 1 протестированный определенно лучше, чем 3 непротестированных). Поэтому, когда Вы находите и решаете проблему, это делает целую прикладную область более твердой (и разработка и обслуживание более эффективны).

BTW, that't одна из причин (кроме содействия назад в сообщество), почему наша компания выставляет нашу.NET, совместно использовал библиотеки общественности как открытый исходный код.

Плюс, существует меньше кода для записи. И можно определять один dev осуществлять хорошие методы разработки на библиотеке и ее использованиях (т.е. через контракты кода, осуществленные на модульных тестах в потребителях библиотеки). Это улучшает качество и и уменьшает затраты на обслуживание.

Мы храним совместно использованные библиотеки как двоичные файлы в решении. Это прибывает из логического требования, чтобы любое решение было атомарным и независимым (это исключает ссылки svn:externals).

Совместимость API не является проблемой вообще. Просто позвольте своему серверу интеграции восстановить и повторно протестировать целую стопку продукта (при обновлении всех внутренних ссылок и распространении изменений), и Вы всегда будете уверены, что весь внутренний API тверд. И кто бы ни повреждается, API должен или зафиксировать его или обновить использования.

Дублирование больших систем - таких как клиентская регистрация - было бы немым вне веры,

Вот почему те системы публикуют внешние интерфейсы.

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

Даже если Вы запустите с библиотек, то Вы закончите тем, что копировали код так или иначе. Хотите к проекту 1 текущих исправлений? Это было выпущено с библиотекой 1.34, так для хранения текущих исправлений как можно меньше, Вы вернетесь в библиотеку 1.34 и зафиксируете это. Но эй - теперь Вы сделали точно waht, библиотека, как предполагалось, избегала - Вы копировали код.

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

Библиотеки склонны быть универсальными решениями определенных проблем. Как правило, универсальное решение более сложно, чем сумма двух определенных решений. Это означает необходимость в одном хорошем программисте для решения проблемы, которая, возможно, была решена двумя идиотами. Походит на плохой компромисс мне :D

Дублирование является корнем всего зла

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

Я действительно получаю много агента по печати для того, чтобы даже предложить, чтобы дублирование было опцией. Я понимаю, почему, но позволяют мне усложнить это немного.

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

Поп-тест: Вы просто пишете что-то столь же маленькое как это в Вашем собственном проекте, или Вы стиснули зубы и используете дискуссию непротестированный набор утилит, которые повредят Ваше приложение, если кто-то повредит функцию?

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

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

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

Мой аргумент - это:

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

Необходимо будет ВСЕ ЕЩЕ использовать большие существующие системы, которые просто не могут быть дублированы.