Эта статья изначально была опубликована в моем личном блоге: https://bogdan.sh/having-fun-with-dependencies/

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

Добро

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

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

Учитывая, сколько веб-приложений разрабатывается каждую минуту, существование таких фреймворков, как React и Angular, или даже бэкенд-фреймворков, таких как Express.js или Django, полностью оправдано. Принимая во внимание, как много мы используем базы данных, разработка ORM также понятна. Следующими шагами были, конечно же, построение систем, IaC (инфраструктура как код), оркестровка развертывания и так далее.

Это создало гигантское сообщество, состоящее из миллионов разработчиков, которые вместе работают над созданием экосистем для различных языков и инструментов программирования. Это представляет собой огромный аспект при анализе различных альтернатив, поскольку окружающее сообщество, количество обновлений и дополнительных плагинов являются убедительными факторами. Честно говоря, это одна из самых удивительных вещей в ИТ-индустрии: объем работы, проделанной для сообщества, код, который можно использовать повторно, или проекты, которые можно интегрировать в свои. Если вы также добавите количество вопросов на Stack Overflow, форумах и других платформах, ИТ-индустрия совершенно уникальна.

Плохо

Не может же все быть красиво и без недостатков, не так ли? Ну и минусов хватает.

Сложность

Во-первых, влияние, которое это оказывает на продукт: мы находимся в точке, где сторонние зависимости стали довольно сложными, поэтому они добавят много накладных расходов в окончательный проект. Почему это? Потому что эти библиотеки должны удовлетворять потребности десятков тысяч проектов. Более того, во многих случаях основные разработчики библиотек перегружены, и тогда некоторые другие участники заполнят код для любой функции, которая им нужна. Это магия открытого исходного кода. Однако вполне понятно, как это приведет к ошибкам, проблемам с производительностью, огромным размерам сборки и так далее.

Это легко заметить, особенно в проектах Javascript. Я не хочу оскорблять Javascript (каламбур), но есть причина, по которой существует так много мемов о node_modules.

Возьмем кейс, может быть, Webpack? Проще говоря, Webpack — очень популярный сборщик Javascript. С годами он становился все более и более популярным, поэтому он должен включать в себя бесчисленное количество функций. Это очень сложный проект, архив их последней версии (исходный код) занимает около 6 МБ, а не заархивированный около 20. Это довольно много, учитывая, что вам понадобится эта библиотека на всех ваших машинах разработки, всех ваших конвейерах и так далее. . И это часто не единственная библиотека, связанная с Webpack, поскольку она имеет большую экосистему других зависимостей, которые вам потребуются. Более того, у вас, скорее всего, будет одна копия для каждого проекта Javascript, поскольку вы даже можете использовать разные версии для каждого репозитория. Это много используемого хранилища, сетевого трафика, времени и сложности, добавленные к вашим системам.

Кроме того, к счастью, в вашей окончательной сборке не будет Webpack, но как насчет React, исходный код последнего релиза которого заархивирован почти на 8 МБ? Хорошо, эти размеры не окончательные, но они могут нарисовать довольно хорошую картину.

Сегодня ведется много дискуссий о производительности программного обеспечения по сравнению с тем, что было 20 лет назад или даже больше. И да, этому во многом способствует количество и сложность сторонних разработчиков. Чем больше у вас кода, чем больше ресурсов вы будете использовать, тем больше вы будете подвержены ошибкам и уязвимостям. Говоря о…

Баги и уязвимости

Вернемся к примеру с Webpack. Во-первых, немного статистики:

  • он имеет около 95 зависимостей
  • 730 участников
  • используется в 12 миллионах репозиториев
  • 15 тыс. коммитов

Это действительно впечатляющие цифры. Я действительно не хочу критиковать Webpack, его использование в 12 миллионах других проектов — это замечательно, и это показывает, насколько влиятельным является Webpack. Спасибо им за создание чего-то такого масштаба. Но если легко понять, почему наличие 700 участников может привести к неоптимальному коду и повлиять на производительность, просто представьте, как сложно избежать ошибок или уязвимостей безопасности в такой среде. И благодаря этим впечатляющим цифрам это очень привлекательный вектор атаки. Давайте быстро проверим некоторые цифры:

Если это не их код, они не обязаны его поддерживать.

Конечно, эти цифры, вероятно, очень далеки от реальности, но они дают нам общее представление. А теперь представьте, какие номера могут быть у некоторых других популярных библиотек. И это выходит далеко за рамки экосистемы Javascript. Реальная проблема здесь состоит в сочетании двух очень неправильных идей, которые есть у людей. Во-первых, многие разработчики думают, что если это не их код, им не нужно его поддерживать. Это очень неправильно. Вы несете ответственность за весь код, работающий в вашей инфраструктуре, и даже если это не ваша инфраструктура, а облачная, вы все равно отвечаете за нее. Вы обязаны по отношению к своим пользователям и клиентам убедиться, что код, который вы используете, безопасен. Конечно, это не будет на 100% безопасно, но вы не можете просто сказать, что это не ваш код и наплевать на него.

Код, написанный сообществом, проверенный и протестированный столькими разработчиками и пользователями, намного лучше того, что они могли бы написать.

Второй способ мышления, который приводит к этим проблемам и тесно связан с первым, заключается в том, что разработчики думают, код, написанный сообществом, проверенный и протестированный таким большим количеством разработчиков и пользователей, намного лучше, чем они могли бы. пишите. Это тоже, как вы уже догадались, неправильно. Очевидно, что наличие большого количества пользователей, запускающих и тестирующих ваш код, поможет быстрее находить ошибки, но проблема, опять же, в сложности. Поскольку эти библиотеки должны поддерживать так много вариантов использования, код вскоре станет очень сложным. У вас может быть один фрагмент кода, охватывающий 500 различных функций, и 480 из них будут наиболее распространенными. Эта библиотека понадобится вам, скажем, для 10. Если эти 10 вариантов использования относятся к менее популярным, очень вероятно, что другие не поймают ошибки раньше, чем ваши клиенты. Кроме того, поскольку эта библиотека настолько сложна и охватывает так много функций, вы могли бы написать ее самостоятельно, чтобы охватить только 10 необходимых вам, и тогда вероятность появления ошибок была бы меньше, что упростило бы вашу жизнь.

Уродливый

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

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

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

Заключение

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

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

Если вам понравилась эта статья, не стесняйтесь проверять мой блог для получения дополнительной информации: https://bogdan.sh/