Почему стоит использовать подход "Vendor by Default" в разработке программного обеспечения

Биткойн Юридические новости

В мире разработки программного обеспечения выбор подхода к управлению зависимостями всегда стоял одной из важных задач. В последние годы практики, связанные с использованием внешних библиотек и модулей, вызывают всё больше обсуждений. Одной из необычных, но весьма интересных стратегий является подход "Vendor by Default", когда разработчик сознательно копирует исходный код зависимостей в свой проект вместо того, чтобы ссылаться на них через стандартные менеджеры пакетов. Этот метод кажется старомодным и не всегда популярным среди JavaScript-сообщества, однако заслуживает пристального внимания и понимания причин его использования. Сам термин "vendoring" в программировании означает прямое включение исходного кода чужих библиотек в свой проект, что противоположно типичному управлению зависимостями, при котором указываются лишь ссылки на нужные пакеты в конфигурационных файлах, таких как package.

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

Подход "Vendor by Default" также способствует тому, чтобы максимально сконцентрироваться на реальных потребностях проекта и отказаться от избыточности. Зависимости часто содержат огромные API с множеством функций, которые в конкретном приложении никто не использует. Несмотря на возможности современных инструментов для удаления мёртвого кода, они редко могут избавить от целых неиспользуемых методов классов, а зачастую и вовсе работают только на уровне переменных. Копируя только необходимое и тестируя именно используемый API, разработчик может значительно улучшить качество и производительность проекта. Особенно это становится актуально для старых или давно не обновляемых библиотек.

 

В них часто остаются архаичные паттерны и проверки, нужные только для поддержания совместимости с устаревшими браузерами и средами, например для Internet Explorer 10 или даже более ранних версий. В современных реалиях многие из этих полифиллов и проверок являются просто лишним балластом, который можно безопасно убрать. Благодаря vendoring-стратегии это становится возможным без риска неожиданно сломать совместимость. С точки зрения безопасности и ответственности за конечное приложение данный подход также имеет свои плюсы. Автоматическое обновление зависимостей не гарантирует своевременного исправления критических ошибок и уязвимостей, особенно если проект зависит от многих библиотек со сложными цепочками.

 

Копируя код напрямую, разработчик берёт ответственность в свои руки, тщательно проверяет и модифицирует каждой строку, что позволяет избежать многих скрытых проблем, связанных с версионностью и несовместимостью. Однако стоит отметить и очевидные минусы подхода. Увеличивается размер исходного кода, который нужно поддерживать и тестировать. Это требует дополнительных усилий и может повлиять на скорость разработки, особенно если проект растёт. Кроме того, такой подход для многих программистов кажется непривычным и даже диковинным, так как развивается далеко от современных стандартов и привычек управления зависимостями.

 

Важным аспектом "Vendor by Default" является влияние на взаимодействие с сообществом и открытым исходным кодом. Фактически, копирование и модификация кода могут удалять пользу для оригинального проекта, особенно если внесённые изменения слишком специфичные и не универсальные. Однако, с другой стороны, наличие кода в проекте напрямую облегчает быструю фиксацию багов и их интеграцию в разработку. Легче адаптировать и подстраивать зависимости в тех случаях, когда не нужно через месяц ожидать официального обновления. Не стоит путать vendoring с копированием больших и сложных фреймворков, таких как React или Webpack.

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

Сегодня же пакеты и модули выглядят как единицы с чёткими границами и чаще всего подключаются через менеджеры пакетов. Тем не менее определённые ситуации продолжают оправдывать vendoring как практичное и удобное решение. Подводя итог, можно сказать, что "Vendor by Default" - это не рекомендация или универсальный рецепт для всех проектов, а скорее осознанный и продуманный подход, который работает в определённых условиях. Он помогает глубоко интегрироваться в используемый код, повысить качество, стабильность и безопасность приложений, снизить зависимость от внешних изменений и обновлений, которые могут прийти в неудачный момент. Особенно тогда, когда проект требует контроля над каждым элементом, этот подход заслуживает внимания разработчиков, готовых инвестировать больше времени в понимание и поддержку собственного кода.

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