Реальная стоимость зависимостей Javascript (и состояние качества пакета JS)

Многие качественные инструменты пытаются анализировать проекты с помощью количественных показателей, таких как количество участников, количество звезд на Github, количество загрузок и т. Д. Отчет QualityOfJSPackages предлагает другой подход с гораздо большим количеством метрик, основанных на качестве.

Качество не имеет ничего общего с количеством!

Все цифры в этом отчете основаны на анализе 100 самых популярных пакетов (результат наиболее зависимых пакетов).

1. Средний вес JS пакетов.

Каждый пакет имеет вес, который в основном соответствует размеру этого проекта на вашем диске при его установке. Этот вес можно разделить на 2 части:

1. размер всех файлов проекта

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

Есть 2 разных показателя: размер (в реестре) и размер без упаковки. Первый соответствует размеру модуля, опубликованного в реестре NPM, поэтому он уменьшен и сжат с помощью gzip, чтобы сократить время загрузки. Второй показатель - это фактический размер на диске после установки. Оба показателя интересно анализировать, но наиболее важным моментом является разница между двумя показателями. Как мы видим, после установки размер модуля может быть значительно больше, чем размер, указанный NPM. И эти 2 показателя могут стать действительно важными, если мы посмотрим на 90-й процентиль (или выше). Больше всего беспокоит то, что он не принимает во внимание размер зависимостей ...

2. размер всех зависимостей модуля

Вот и мы, черная дыра экосистемы Node.js; thenode_modulesfolder, который содержит зависимости и все подчиненные зависимости проекта.

Если мы посмотрим, например, на третий квартиль, мы увидим, что только 6 зависимостей приведут в среднем к 28 подчиненным зависимостям и среднему размеру 2,18 МБ. Поэтому каждую зависимость следует выбирать тщательно и анализировать с точки зрения производительности.

Если вам интересно, как среднее значение (синий столбец) может быть таким высоким, то это потому, что 99-й процентиль (что хуже всего) действительно высок. Я не буду бросать никого в тупик, называя здесь имена, но для этого проекта это значение составляет около 300 МБ.

2. Скрытая стоимость зависимостей JS.

Зависимости можно рассматривать как способ облегчить ваш код. Отчасти это верно, но в то же время все зависимости (и их подзависимости) будут сильно загружать ваши страницы и проекты.

За внешними зависимостями нет никакого волшебства, каждая из них увеличит размер вашего проекта.

Некоторые показатели, которые следует учитывать, когда мы хотим держать зависимости под контролем:

количество прямых зависимостей и количество общих зависимостей
глубина дерева зависимостей
общий вес зависимостей (в основном размер папки node_modules)

3. Среднее время загрузки модуля javascript.

Каждая зависимость устанавливается для того, чтобы ваша программа рано или поздно импортировала ее. У каждого модуля разное время загрузки, и иногда один проект должен загрузить более 10 зависимостей, чтобы иметь возможность запуститься. Время загрузки вашего проекта может быть замедлено из-за накопления слишком большого количества зависимостей, загрузка которых может занять много времени.

На этом графике мы видим среднее время загрузки каждого модуля. 90-й процентиль очень интересен, поскольку показывает огромное отличие от медианного значения. Это означает, что время запуска вашего сервера (или приложения) в огромной степени зависит не только от количества используемых вами зависимостей, но также коррелирует с их «качеством». У большинства из них время загрузки составляет около 3 мс, что почти мгновенно, но использование худших из них может быстро привести к общему времени загрузки более 1 секунды. Разница между временем мгновенной загрузки и несколькими секундами может полностью изменить поведение ваших развертываний, систему масштабирования и т. Д.

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

Дополнительные 0,5 секунды при каждом создании страницы поиска снизят трафик на 20% —Google

4. Уязвимости в модулях javascript.

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

Состояние безопасности не так уж и плохо (количество уязвимостей безопасности на проект)…. но это не относится к зависимостям разработчиков. Конечно, вы не должны устанавливать / использовать их в производственной среде, но ошибки могут возникать очень быстро.

5. Обновлены ли пакеты Javascript?

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

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

6. Среднее дублирование кода в экосистеме javascript.

Одним из основных направлений качества программного обеспечения является дублирование кода. Дублированный код может привести к множеству проблем:

Снижение ремонтопригодности
Снижение читабельности кода
Повышение рисков безопасности
Увеличение размера кодовой базы

Среднее дублирование кода пакета - хороший показатель при оценке качества кода.

Как мы видим, во многих пакетах по-прежнему много дублированного кода. Многие проблемы с качеством можно решить, если ваша кодовая база будет как можно более простой и чистой. Похоже, что самые популярные пакеты опять же не равны по дублированию кода. Некоторые из них имеют действительно здоровую кодовую базу, но некоторые другие, похоже, имеют значительный технический долг.

7. Точная версия зависимостей

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

У вас есть 2 варианта, как с этим справиться:

закрепите свою версию зависимости
используйте файл блокировки для зависимостей (например, package-lock.json или yarn.lock)

8. Глобальная оценка качества модулей JS.

Теперь, когда мы собрали несколько показателей, мы можем рассчитать глобальную оценку качества для каждого проанализированного модуля. Каждую метрику можно считать хорошей или плохой в зависимости от порогового значения. Например, дублирование кода считается хорошим, только если у вас 0% дублированного кода. Конечно, все пороги можно считать субъективными, но все же интересно проанализировать результат.

И не много модулей имеют больше 80%. На самом деле среднее значение и медиана действительно близки, около 55%. Что это обозначает?

Есть много возможных улучшений даже для хорошо известных фреймворков и модулей.

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

Если вы хотите увидеть все пороги, использованные для создания этого отчета, вы можете обратиться к этому проекту: https://github.com/wallet77/qualscan или просто запустить команду qualscan -h для вывода значений по умолчанию.

9. Воздействие на окружающую среду

А как насчет нашего воздействия на окружающую среду? Все, что мы делаем в нашей отрасли, является виртуальным, поэтому распространенной ошибкой является мнение, что разработка программного обеспечения меньше загрязняет окружающую среду. Технически это неверно, поскольку мы используем все больше и больше возможностей для выполнения простых команд, например, npm install. Только представьте, что происходит, когда вы загружаете, затем распаковываете и устанавливаете все зависимости. Просто взгляните на результат и имейте в виду, что среднее потребление на этой машине на холостом ходу составляет около 0,3 Вт.

В среднем мы перешли от 0 до 10 Вт на протяжении всего процесса установки, который может занять время в зависимости от количества зависимостей. Как видите, одна эта команда представляет 75% потребления хоста.

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

Нет никакого волшебства, все, что мы делаем, влияет на окружающую среду

Так что любая оптимизация может принести пользу планете, давайте не будем недооценивать этот момент;)

Набор полезных инструментов для анализа ваших проектов

Qualscan: находим проблемы с качеством
АОЗП: найти дублирование кода
График NPM: отобразите ваше дерево зависимостей
Bundle phobia: проанализируйте размер модуля
Снык советник: проанализируйте качество и безопасность модуля
Npms.io: анализировать качество модуля

Заключение

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

Тем не менее, есть несколько приятных сюрпризов, особенно в отношении безопасности и регулярных обновлений.

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