В мире программирования часто существует распространённое заблуждение, что использование сторонних библиотек и зависимостей — это бесплатный и простой способ получить необходимую функциональность без лишних усилий. Это впечатление обманчиво, ведь зависимости всегда несут с собой определённые издержки. Принимая решение добавлять ту или иную зависимость в проект, важно внимательно оценить не только очевидные плюсы, но и множество потенциальных минусов, которые могут сильно сказаться на результате и процессе разработки. Затраты на изучение новой библиотеки могут быть значительны. Иногда библиотеки настолько громоздки и сложны, что разработка собственного узкоспециализированного решения оказывается быстрее и проще, чем освоение нового инструментария.
К тому же, установка и интеграция зависимости в проект порой требует сложнейших настроек, контейнеризации и сборки, что только усложняет выпуск и сопровождение продукта. Порой человек, пытаясь не «перевиначивать велосипед», создаёт совершенно другой велосипед — запускает процесс, далекий от основной функциональности приложения и затратный с точки зрения ресурсов команды. Яркий пример такого подхода — финансовая база данных TigerBeetle, написанная целиком на языке Zig без сторонних зависимостей, за исключением самой цепочки инструментов Zig. Такой подход минимизирует риски связанные с цепочками поставок, повышает безопасность и стабильность работы, а также сокращает время установки и развертывания инфраструктуры. И хотя Zig может не быть универсальным решением для всех задач, это универсальный и достаточно производительный инструмент, который позволяет локальным командам избегать накопления ленивой сложности и выбирать наиболее прямой и понятный путь решения.
Когда речь заходит о выборе зависимостей, полезно иметь чёткий каркас, позволяющий взвесить все ключевые критерии. Такие критерии, как распространённость — насколько широко доступна и используется библиотека, будет ли она присутствовать в средах выполнения по умолчанию и не усложнит ли это деплоймент и сборку продукта. Стабильность — как часто происходят несовместимые изменения, удаляются ли функции и как часто меняется «мета» библиотеки, что способно привести к большим затратам на рефакторинг. Глубина функциональности — насколько библиотека покрывает потребности, и насколько сложно будет реализовать всё это самому без неё. Эргономика — насколько приятен и понятен для разработчика интерфейс.
И не менее важна «водонепроницаемость» — то есть вероятность того, что абстракция не «протечёт», и программист не будет вынужден постоянно помнить о внутренностях зависимости при решении своих задач. Чаще всего продавцы сторонних либ любят говорить о том, насколько у них удобный и современный API, игнорируя при этом остальные параметры, что часто приводит к разочарованию через какое-то время эксплуатации. Ярким примером «хороших» зависимостей являются POSIX-системные вызовы, которые можно встретить на большинстве UNIX-подобных систем. Это невероятно глубоко проработанный и стабильный слой, который лежит в основе систем, и их API хоть и выглядит устаревшим из-за множества флагов и конвенций Си, но остается неизменным и универсальным. Другим примером является стандарт ECMA-48 для управления терминалами.
Он практически не изменялся с 1991 года, является практически вездесущим и обеспечивает надежную абстракцию, которая редко заставляет задумываться о тонкостях аппаратного обеспечения. Веб-платформа — браузер вместе с веб-API, HTML, CSS и JavaScript — это самая распространённая среда для запуска приложений на сегодняшний день. Их глубокая функциональность и забота о обратной совместимости делают невозможным создание собственноручной реализации такого уровня за разумное время. При правильном использовании эти «зависимости» становятся неоценимыми инструментами, позволяя разработчикам сосредоточиться на логике своих приложений, а не на фундаментальных технологиях. В свою очередь, неправильный выбор зависимостей может привести к накоплению технического долга, ухудшению производительности, появлению сложных и неустойчивых сборок с множеством инструментов.
Это в конечном итоге ведёт к увеличению сроков разработки, снижению качества продукта и росту затрат на сопровождение. Важно критически подходить к выбору зависимостей, внимательно анализировать их стоимость помимо кажущейся полезности и привлекательного API. Часто гораздо выгоднее и эффективнее потратить время на разработку и поддержку небольшого, специализированного собственного решения, чем грешить на громоздкие, непредсказуемые и потенциально опасные внешние библиотеки. В современном мире разработчикам стоит стремиться к простоте, устойчивости и контролю — и именно эти качества помогают минимизировать случайную сложность и обеспечивают стабильный рост продукта и команды. Помните, что каждая зависимость — это не бесплатный подарок, а инвестиция, которая требует взвешенного подхода и планирования.
Самая дешевая и безопасная зависимость — та, которую вы контролируете сами или которые хорошо знают и умеют использовать все участники команды. Эти принципы лежат в основе качественной архитектуры и устойчивого развития программных продуктов в долгосрочной перспективе.
