Разработчику в 2021 году сложно создать что-то полезное, не используя чужой код. Зачем изобретать колесо? В конце концов, даже стандартные библиотеки, поставляемые с разными языками программирования, написаны кем-то другим. Точно так же стандартные библиотеки также используют код ОС нижнего уровня (написанный кем-то другим) и так далее. Это нормальный процесс, программное обеспечение создается поверх другого программного обеспечения. Тем не менее, это должен быть осознанный процесс, предусматривающий перспективное / долгосрочное обдумывание последствий и возможных технических долгов.

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

  • Могу ли я легко реализовать это самостоятельно? (помните leftPad)
  • Жив и в хорошем ли состоянии?
  • Насколько он большой? (это особенно важно для интерфейса)
  • Является ли API хорошим и легким в использовании?

Внедрить или принять - это немного сложно. Мне нравится поговорка «Лучший код - это код, который не написан», потому что чем меньше кода вы напишете, тем меньше возможностей для появления ошибок, но если это что-то настолько тривиальное, до пару часов работы, стоит подумать о реализации самостоятельно (если демка не завтра :)).

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

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

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

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

Сценарий, с которым я столкнулся с заброшенными библиотеками, - это блокировка транзитивных зависимостей (транзитивная зависимость - это зависимость одной из зависимостей вашего проекта). Рассмотрим следующий пример: ваш проект зависит от активно развивающейся foo-1.0 - заброшенной библиотеки через некоторое время, использующей bar-1.0. Скажем, ваш проект также напрямую использует bar-1.0 - активный.

Через некоторое время выпускается bar-2.0 с множеством улучшений, функций и улучшений производительности, но не полностью обратно совместимый. Поскольку foo-1.0 использует bar-1.0, вы заблокированы и не можете перейти на bar-2.0, пока не избавитесь от foo-1.0 или выполните обновление и выпустите новую версию foo, совместимую с bar-2.0.

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

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

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

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