Перейти к основному содержимому

4.04. Библиотека

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ

Разработчику Аналитику Тестировщику
Архитектору Инженеру

Библиотека​

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

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

Но, чтобы такой набор заработал, библиотеки всегда нужно подключать к коду. Для этого нужно установить компоненты, встроить в проект, и в каждом файле с кодом, в самом начале говорить «import» или «using» в зависимости от языка. У каждого языка бывают встроенные возможности и инструменты – стандартные библиотеки. К примеру, это математические операции, ввод/вывод - их отдельно устанавливать не нужно.

Таким образом, мы получаем файлы с кодом, ресурсы, и библиотеки, которые собираются в проект (решение). Проект после сборки становится готовой программой.

И писать код с нуля – это словно изобретение бумаги, чернил, печатного станка для написания книги - гораздо эффективнее использовать готовые решения, то есть - библиотеки.

Стандартные библиотеки включены в язык, к примеру, math, os в Python, или Array, Date в JavaScript. Это базовые инструменты в мастерской по подготовке кода. Открывая IDE, мы сможем работать с ними без дополнительных загрузок.

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

Добавление в проект​

Установка пакетов (менеджеры зависимостей)​

Вместо ручного скачивания файлов, разработчики используют менеджеры пакетов, к примеру, NuGet в C#, npm в JavaScript. Эти инструменты автоматически скачивают библиотеку и все её зависимости (другие библиотеки, которые нужны для работы).

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

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

Проект может использовать десятки или сотни внешних библиотек. Менеджер пакетов читает файл описания зависимостей (например, package.json в npm, requirements.txt в Python, Cargo.toml в Rust) и автоматически загружает нужные версии компонентов.

Если две зависимости требуют разные версии одной и той же библиотеки, менеджер пакетов пытается найти совместимую комбинацию или уведомляет о невозможности разрешить конфликт.

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

Разработчики могут публиковать свои библиотеки в реестрах (например, npm Registry, PyPI, crates.io), откуда их легко подключить другим.

Примеры менеджеров пакетов​

  • npm / Yarn / pnpm — для JavaScript и TypeScript
  • pip / Poetry — для Python
  • NuGet — для .NET (C#, F#)
  • Cargo — для Rust
  • Maven / Gradle — для Java и Kotlin
  • Composer — для PHP

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

CDN​

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

Особенно популярно в веб-разработке - вместо того, чтобы хранить библиотеку у себя (ведь, скачивая, мы храним у себя?), можно подключить её по ссылке:

<script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>

При таком решении, файлы кэшируются браузером, однако требуют соединения и работоспособности ссылки.

Таким образом,

  • разработчик создаёт каталог (папку) решения или проекта;
  • разработчик пишет код, подключает необходимые библиотеки;
  • сборщик (компилятор/интерпретатор) берёт все файлы и зависимости, проверяет их и создаёт исполняемый файл (или интерпретирует, как в JavaScript);
  • готово - программа работает.

Когда пользователь запрашивает веб-страницу, статические файлы (скрипты, стили, шрифты, изображения) загружаются не с основного сервера приложения, а с ближайшего узла CDN. Это снижает задержку и ускоряет отображение страницы.

Поскольку большая часть трафика обслуживается CDN, основной сервер тратит меньше ресурсов на отдачу повторяющихся файлов.

CDN хранит копии файлов на своих узлах. При повторных запросах файл отдаётся из кэша, без обращения к источнику. Если один узел CDN выходит из строя, запрос автоматически перенаправляется на другой.

Многие популярные библиотеки (например, React, jQuery, Bootstrap, Lodash) доступны через публичные CDN, такие как:

  • jsDelivr
  • unpkg
  • cdnjs
  • Google Hosted Libraries

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

Типы библиотек​

Библиотеки различаются по назначению и уровню абстракции:

  • Утилитарные библиотеки решают повседневные задачи: форматирование строк, манипуляции с датами, работа с коллекциями. Примеры: Lodash (JavaScript), Apache Commons Lang (Java).
  • Доменные библиотеки ориентированы на конкретную предметную область: обработка изображений (Pillow в Python), машинное обучение (TensorFlow), криптография (bcrypt, libsodium).
  • Интерфейсные библиотеки помогают строить пользовательские интерфейсы: React и Vue для веба, UIKit и SwiftUI для iOS, WinForms и WPF для Windows.
  • Системные библиотеки обеспечивают взаимодействие с операционной системой или оборудованием: сетевые вызовы (fetch, HttpClient), работа с файловой системой, управление памятью, драйверы устройств.

Выбор библиотеки зависит от слоя системы, на котором работает разработчик: от пользовательского интерфейса до аппаратного взаимодействия.

Жизненный цикл библиотеки в проекте​

Подключение — только начало. Библиотека требует сопровождения на протяжении всего жизненного цикла проекта.

  • Обновление — авторы выпускают новые версии с исправлениями, улучшениями и новыми возможностями. Разработчик принимает решение: обновлять сейчас, отложить или остаться на текущей версии.

  • Заморозка версий — чтобы сборка проекта оставалась воспроизводимой, версии всех зависимостей фиксируются в специальных файлах:

    • package-lock.json (npm)
    • packages.lock.json (NuGet)
    • requirements.txt или poetry.lock (Python)

    Эти файлы гарантируют, что любой разработчик, клонировавший репозиторий, получит точно такой же набор библиотек.

  • Удаление — если библиотека больше не используется, её следует удалить. Лишние зависимости увеличивают размер приложения, замедляют сборку и создают потенциальные уязвимости.

Безопасность и надёжность библиотек​

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

  • Проверка источника — предпочтение отдается официальным репозиториям (npmjs.com, nuget.org, PyPI). Полезные индикаторы: количество звёзд на GitHub, частота коммитов, активность issue-трекера, наличие документации.
  • Лицензирование — каждая библиотека распространяется под определённой лицензией. Некоторые (например, GPL) накладывают ограничения на использование в проприетарных продуктах. Перед подключением важно проверить совместимость лицензии с политикой проекта.
  • Уязвимости — даже популярные библиотеки могут содержать ошибки, открывающие доступ злоумышленникам. Существуют инструменты для автоматического сканирования:
    • npm audit
    • dotnet list package --vulnerable
    • safety check (Python)
    • Snyk, Dependabot, GitHub Security Alerts

Регулярный аудит зависимостей — обязательная практика в профессиональной разработке.

От библиотеки к программе​

Процесс создания программы выглядит так:

  1. Разработчик создаёт каталог (папку) проекта.
  2. Пишет собственный код и подключает необходимые библиотеки.
  3. Сборщик (компилятор, bundler или интерпретатор) объединяет:
    • Исходные файлы проекта
    • Сторонние библиотеки
    • Стандартную библиотеку языка
    • Статические ресурсы (изображения, конфигурации)
  4. На выходе получается готовый артефакт: исполняемый файл, веб-пакет или скрипт, который можно запустить.

1. Создание каталога проекта​

Каталог проекта — это изолированное рабочее пространство, где хранятся все файлы, необходимые для разработки, сборки и запуска программы. Хорошо организованная структура папок упрощает навигацию, совместную работу и автоматизацию.

Типичные подкаталоги:

  • src/ — исходный код приложения
  • lib/ или vendor/ — локально размещённые сторонние библиотеки (редко используется при наличии менеджера пакетов)
  • assets/ или public/ — статические ресурсы: изображения, шрифты, звуки
  • config/ — файлы конфигурации для разных сред (разработка, тестирование, продакшн)
  • dist/ или build/ — выходные артефакты после сборки
  • tests/ — автоматизированные тесты

Файлы верхнего уровня часто включают:

  • Манифест зависимостей (package.json, Cargo.toml, requirements.txt)
  • Файл сборки (Makefile, webpack.config.js, CMakeLists.txt)
  • Файл игнорирования (.gitignore) — исключает временные и системные файлы из контроля версий

2. Написание кода и подключение библиотек​

Разработчик пишет логику приложения в файлах исходного кода. При этом он не реализует всё с нуля — вместо этого он использует:

  • Стандартную библиотеку языка — набор базовых функций, предоставляемых самим языком (работа с файлами, строками, сетью и т.д.)
  • Сторонние библиотеки — компоненты, созданные сообществом или компаниями (например, React для интерфейсов, Express для веб-серверов, NumPy для вычислений)

Подключение библиотек происходит двумя основными способами:

  • Через менеджер пакетов, который загружает зависимости в локальный кэш или в папку проекта (node_modules, .venv, target/)
  • Через CDN, если речь идёт о клиентском веб-коде, подключаемом напрямую в HTML (чаще в прототипах или простых сайтах)

Важно фиксировать точные версии зависимостей, чтобы гарантировать воспроизводимость сборки на разных машинах.

3. Сборка: объединение всех компонентов​

Сборщик — это инструмент, который превращает разрозненные файлы в единый работоспособный артефакт. Его роль зависит от типа проекта:

  • Для компилируемых языков (C, C++, Rust)
    Компилятор преобразует исходный код в машинные инструкции, а линковщик объединяет объектные файлы и библиотеки в исполняемый файл.

  • Для веб-приложений (JavaScript, TypeScript)
    Bundler (например, Webpack, Vite, Rollup) объединяет модули, минифицирует код, встраивает статические ресурсы и генерирует HTML/CSS/JS-файлы, оптимизированные для браузера.

  • Для интерпретируемых языков (Python, Ruby)
    Сборка может быть минимальной — достаточно упаковать код и зависимости в архив или контейнер. Однако часто используются инструменты вроде PyInstaller или Docker для создания самодостаточных артефактов.

На этом этапе также могут выполняться:

  • Проверка типов
  • Линтинг (анализ стиля кода)
  • Тестирование
  • Генерация документации

4. Готовый артефакт​

Результат сборки — это то, что можно передать пользователю или развернуть на сервере:

  • Исполняемый файл (.exe, .bin, ELF-файл) — запускается напрямую операционной системой
  • Веб-пакет — набор HTML, CSS, JS и медиафайлов, размещаемых на веб-сервере или CDN
  • Скрипт с зависимостями — например, Python-приложение в виртуальном окружении или Docker-образ
  • Библиотека — если проект сам предназначен для повторного использования, результатом может быть пакет для публикации в реестре (npm, PyPI и др.)

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