Каждый веб-разработчик сталкивался с этой головоломкой: какую зависимость выбрать? Почему мы выбираем jQuery, а не Prototype, или Prototype, а не Mootools, или отдаем предпочтение Vue вместо React, или же предпочитаем Angular вместо Ember, или же Lodash, а не Underscore, и так получается неограниченное количество комбинаций.
Сам я принимаю решение настолько быстро, что оно может казаться неосознанным. Однако это не так, и я решил, что пришло время описать некоторые из моих рабочих процессов, как минимум, чтобы со временем скорректировать их или пересмотреть.
Виды зависимостей
Когда я выбираю новые зависимости, я мечусь меж двух огней. Либо мне нужен проект уровня фреймворка, либо уже готовое решение (плагин, библиотека или нечто подобное). Также на процесс выбора влияют конкретные факторы.
Ниже приведен список вопросов, согласно которому я расставляю приоритеты, когда рассматриваю какие-либо зависимости для проекта.
1. Активно ли ведется разработка проекта?
Ответ на этот вопрос особенно важен для больших проектов, поскольку в них над кодом работает обычно больше одного человека. Посещение простаивающего репозитория это далеко не повод отказаться от технологии, но мне нужно понимать технический потенциал новой зависимости.
Вот два аспекта, которым я уделяю много внимания:
- Активность коммитов за последнее время тут обычно помогает беглый взгляд на главную страницу проекта на github.
- Возраст любых открытых pull requstов долго висящие pull requestы могут говорить о том, что проектом долго никто не занимается (я и сам так делал с Nodemon)
2. Используется ли проект?
Популярность не является для меня решающим факторов, но чем больше используется программное обеспечение, тем больше багов в нем будет найдено.
В данном вопросе я обращаю внимание на:
- Общее количество issue большое количество открытых issue это не всегда плохо;
- Количество закрытых issue;
- Скорость, с которой закрываются issue.
Скорость, с которой закрываются issue, для меня является не особо важным фактором, особенно в проекте, где их много. Для меня важнее наличие их обсуждения.
3. Глубина зависимостей
В сообществе Node и npm ходит шутка, что самый тяжелый объект во вселенной это ни Солнце, ни нейтронная звезда и ни черная дыра это
node_modules.Мы, как веб-разработчики, берем на себя огромный риск, и слава богу, что не так давно появился Deno, который пытается решить эту проблему с помощью
stdlib, который предотвращает
разрастание графа зависимостей.Поэтому важно не количество зависимостей (которые вы можете увидеть на таких сайтах как npmjs), а их глубина. Странно, что я видел это только у Snyk.io, то есть зависимости nodemon.
4. Наличие примеров
Что касается библиотек на стороне клиента, то мне нужны интерактивные примеры работающего кода и достаточное количество кода в целом, чтобы иметь возможность воссоздать демо самому.
Так сразу можно получить ответ на вопрос: Будет ли этот проект делать то, чего я от него хочу.
5. Документация и сложность
Второй по важности, кроме рабочего кода, для меня является документация. У маленьких проектов я ожидаю увидеть примеры кода в README. В более крупных проектах я надеюсь на несколько страниц документации.
Когда я смотрю на документацию, то ищу примеры, с которых можно начать и задаюсь вопросом: требует ли сборка этого проекта дополнительных инструментов?
Множество проектов, с которыми я сталкивался в документации содержат еще и предположения о наличии каких-либо знаний, и количество таких предположений повышает градус сложности, особенно, если я не знаком с системами, о которых в проекте идет речь.
Например, по опыту, почти каждый проект на Python предполагает знание того, как установить зависимость, и я под эту категорию не попадаю.
6. Номера версий
Если проект не использует semver, это как правило уже красный флаг, так как очень большое количество информации можно узнать из номера версии.
Напомним, что в semver мажорные версии это индикаторы критических изменений, минорные версии это изменения в функциях, а патч-версии это исправления багов.
Вокруг документации и рефакторинга существует некая туманность (когда внешне API работает точно также, а внутренняя реализация отличается, и вы делаете релиз, но никаким изменениям в semver это не соответствует).
Тем не менее, большой номер мажорной версии предполагает высокую частоту критических изменений, что может означать возможные проблемы с поддержкой уже моего проекта.
Большое минорное число (например, у инструмента командной строки Snyk, сейчас версия 1.323.0) предполагает множество функций, и возможно, новый релиз для каждой функции.
Большой номер у патч-версии, как мне кажется, предполагает стабильность и постоянную поддержку проекта.
7. Возраст
В реальной жизни это был бы эйджизм, но в мире программистов возраст проекта может говорить о многом.
Старость проекта говорит о его зрелости или же может служить своеобразным признаком заброшенности. Но что такое старость? Если Node в 2020 году исполнилось 11 лет, то, наверное, все проекты, чей возраст перевалил за 10 лет могут считаться старыми.
Обычно я избегаю очень молодых проектов (возрастом в несколько месяцев).
Многие из этих советов действительно имею значение: должны ли зависимости создаваться и находиться в проекте, над которым я работаю?
Этот вопрос я всегда задаю себе, и, если конкретная проблема, которую я пытаюсь решить, достаточно четкая, я могу даже вытащить код, скопировать лицензию и процитировать источник, чтобы иметь при себе полностью замороженную зависимость.
WebAssembly. Что и Как
