Общие библиотеки в большой команде

Question

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

Звучит просто, но на практике я обнаружил, что очень трудно поддерживать.

Как вы справляетесь со следующими сценариями:

1. Разработчик непреднамеренно вносит ошибку и ломает все в работе.

2. Каждая библиотека должна стать более зрелой. Это означает, что API должен развиваться, так как же развернуть обновленную версию в рабочей среде, если каждый разработчик должен обновить / протестировать свой код, пока он чрезвычайно занят другими проектами? Это проблема ресурса и времени?

3. Контроль версий, развертывание и использование. Вы бы хранили это в одном глобальном местоположении или заставляли бы каждый проект использовать, скажем, svn: externals , чтобы "связать" библиотеку?

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

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

2. В каждой общей библиотеке должен быть выделенный сопровождающий (может быть компенсирован действительно хорошим набором тестов в небольшой команде).

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

Спасибо за ваши мысли по этому поводу!

Answer 1

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

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

Плюс, меньше кода для записи. Кроме того, вы можете назначить одного разработчика, чтобы обеспечить соблюдение передовых методов разработки для библиотеки и ее использования (т. Е. Через контракты кода, применяемые в модульных тестах внутри потребителей библиотеки). Это улучшает качество и снижает затраты на обслуживание .

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

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