четверг, 12 декабря 2013 г.

[prog] Подход к выбору сторонних библиотек внушаить

Найдено вот здесь:

У нас в компании принята политика выбора библиотек.
1. Обязательно open source под либеральной лицензией (GPL идет лесом сразу, проприетарщина допустима только при наличии саппорт контракта не менее чем на срок жизни проекта с прибитым гвоздями SLA или при наличии исходников)
2. Библиотека в обязательном порядке проходит acceptance review при котором проверяется качество кода, вменяемость разработчика, политику патчей, активность комьюнити, покрытие тестами, систему сборки и т.п. По результатам AR может быть три вердикта: "в топку", "берем" и "берем под свою ответственность". Последнее означает что мы посылаем разработчика в пень и форкаем проект в свою инфрастркутуру, налаживаем систему сборки, тестирование и т.п. В некоторых проектах наши люди становятся основными контрибуторами и эти проекты фактически переходят под наш контроль.
3. Если библиотека признана годной, то она проходит compatibility review на котором проверяется насколько архитектура библиотеки совместима с нашими проектами. Часто при этом пишутся тесты на типичные сценарии из наших проектов. Обычно этим занимаются интерны/джуниоры под наблюдением старших. Если уж они способны справится с библиотекой, то и нормальные разработчики смогут.
4. Если оба ревью пройдены библиотека считается разрешенной к использованию. Библиотеке назначается внутренний мейнтейнер который собирает ее в пакет, следит за обновлениями, отправляет патчи, общается в списках рассылки, рекомендует или наоборот запрещает переход на новые версии. Как правило этим занимается тот же человек что проводил AR, но иногда на эту роль мы берем на контракт разработчика библиотеки.

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

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

Для статистики: протокол прошли >100 библиотек из них разрешены к использованию 32 из них активно используются 12. Включены в инфраструктуру компании и опубликованы — 5.

Внушаить! Правда, очень хочется узнать, что за язык разработки, что за прикладная область, ну и что за компания. А то как-то сомнения гложут... :)

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

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

При этом под "библиотекой" я понимаю нечто большее, чем собственную реализацию CRC32, оформленную в виде повторно используемого внутреннего компонента.

Отправить комментарий