Пользователь
0,0
рейтинг
19 января в 13:44

Разработка → Как все-таки добавить в проект библиотеку из песочницы

Прочитал статью коллеги Andrey2008 о добавлении, а точнее сопротивлении добавлению в проект библиотек и решил описать «чек-лист» который я использую в работе со сторонними компонентами. Пока соотношение решений в пользу готовых/написанных с нуля за последние лет 10 примерно укладывается в пресловутые 80/20, может это мне просто везет.

Лицензия


К сожалению, крупные компании обычно имеют явный запрет на GPL/LGPL и некоторые другие лицензии. Данный запрет обычно идет со стороны департамента по интеллектуальной собственности и патентам и преодолеть его практически невозможно. Иногда выходом может стать двойное лицензирование (GPL/LGPL и коммерческая платная лицензия) — но часто бывает проще поискать другой вариант.

Деньги


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

Альтернативы


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

Сообщество


Обязательно надо проверить насколько активно сообщество разработчиков данного компонента. Если это большая компания или популярный Open-Source проект — поищите блоги и другие публикации посвященные ему и посмотрите на даты. Это поможет вам понять, насколько библиотека или компонент интересны как пользователям так и самим разработчикам и как они развиваются.

Поддержка


Продолжая предыдущий пункт — существует ли официальная поддержка (как бесплатная так и платная). Даже при интеграции компонента часто проще заплатить 100-200 долларов кому-нибудь из авторов за пару часов поддержки вместо того чтобы ломать голову какая версия Питона нужна для запуска каких-нибудь хитрых скриптов без которых оно не компилируется.

Код


Для Open-Source — посмотрите код, проверьте его хотя бы простеньким статическим анализатором. Если код нечитабельный, имеет плохую структуру, отсутствуют комментарии или анализатор ругается на множественные проблемы — лучше от такого отказаться сразу.

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

Ответственный


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

Дизайн и документация


Для каждого компонента или библиотеки необходим хотя бы одностраничный документ, описывающий основные соглашения насчет его использования. Если это не какой-то фреймворк, полезно явно прописать запрет на использование его типов данных где-либо еще кроме «обертки» над ним. Например, HTTP-клиенты любят определять константы для возвращаемого статуса — если их использовать «как есть» в логике вашего приложения при замене библиотеки придется менять кучу классов.

Техдокументация и дедлайны


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

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

Надеюсь что данный чек-лист поможет вам принимать взвешенные решения и «изобретать велосипеды» только там, где это действительно имеет смысл.
@Paskin
карма
6,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (7)

  • +1
    По части «Денег» также надо учитывать перспективы наращивания требований к данной функциональности. Бывает что выгоднее по времени и деньгам держать в команде человека, который полностью контролирует данную функциональность и может её быстро и качественно модифицировать.

    + «Место в общей системе» — чем ближе к ключевой функциональности, тем менее оправдано использование внешних библиотек. И обратно, периферийные и сервисные задачи лучше решать сторонними библиотеками.

    + «Полезная доля» — если из внешней библиотеки будет использоваться 1% функциональности, то лучше поискать альтернативу или написать самим.
  • +4
    А, если не секрет, какие именно аргументы против LGPL?
    • +2
      Статически нельзя собирать с LGPL.
      • 0
        А зачем обычно это нужно?
        Знаю только одно весомое противопоказание — места критичные к производительности. Остальные вроде бы решаются нормальным инсталятором. Что-то упускаю?
        • +2
          Например, чтобы можно было подписать код (LGPL требует чтобы компонент был заменяемым пользователем) Your LGPL license is completely destroying iOS adoption.
          • 0
            Ясно, видимо я мало сталкивался с закрытыми экосистемами.
    • +2
      Формальное обьяснение (не только для LGPL, а для всех blacklisted) — потенциальное раскрытие интеллектуальной собственности компании и высокая трудоемкость/риски связанные с выполнением всех требований лицензии.
      Один из точно известных мне рисков — по LGPL v3 необходимо предоставить возможность замены компонента на другую сборку. Мы же не можем этого сделать из-за регуляции — никакие несанкционированные изменения не разрешаются, даже апгрейд проводится исключительно нашими инженерами.

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