Размышление о современных менеджерах пакетов
Недавно я разговаривал с другом обо всех доступных сегодня на рынке инструментах (некоторые бесплатные, некоторые с открытым исходным кодом), которые помогают нам в наших потребностях в разработке.
К ним относятся такие вещи, как:
- ворчание
- Глоток
- Пряжа
- КодКит
- Композитор
- и так далее.
Конечно, каждое из вышеперечисленных средств не обязательно сопоставимо, потому что некоторые из них являются внешними инструментами, другие — внутренними инструментами, а некоторые предлагают своего рода гибрид.
Кроме того, некоторые из них премиум-класса, некоторые с открытым исходным кодом, некоторые кажутся заброшенными, а некоторые даже привели к нарушению процессов сборки.
Это приводит к ряду вопросов, некоторые из которых я хотел бы осветить. Так вот, если не что иное, как размышления о современных пакетных менеджерах, то, о чем я думал.
Современные менеджеры пакетов
Вопросы, которые пришли мне на ум (и которые я обсуждал с упомянутым другом), следующие:
- как мы должны знать, что использовать,
- когда их использовать,
- и стоит ли с ними связываться?
И поэтому я решил поделиться своими текущими мыслями об этих инструментах и их применимости здесь.
Какие из них мы используем?
Легко уклониться от этого ответа и сказать «какой бы вы ни выбрали», но я думаю, что ответ немного более нюансирован, чем этот.
Например, есть кривые обучения, пакеты, обслуживание и т. д., которые идут с каждым из них. Это не хорошо и не плохо — это естественно для них самих.
Меня больше интересует вопрос: «Какой из них лучше всего подходит для моей команды, моего проекта и моих клиентов?» И вот почему:
- Если команда может легко внедрить утилиту, то практически не будет проблем с ее запуском и запуском в своей работе.
- Если он хорошо работает с проектом с самого начала, то он должен упростить обслуживание по мере роста и развития проекта. Это важно, потому что в противном случае мы рискуем потратить драгоценное время и усилия на то, чтобы ускорить работу при изменении утилиты (если она изменится), и это может нанести ущерб расписанию проекта.
- Я считаю, что лучше всего для клиента служит одна из тех ситуаций, когда «дьявол кроется в деталях». Это так, что если первые два будут удовлетворены, клиент будет ни о чем не догадываться. Во-вторых, это будет стоить меньше времени, принесет больше пользы и заставит их инвестировать в использование вас в качестве поставщика своих услуг.
Тем не менее, я не верю, что существует какой-то один случай «это утилита, которую вы должны использовать», потому что, опять же, я не знаю деталей данного проекта. Таким образом, я не хочу предписывать одно решение, когда в данном случае может подойти другое.
И вот пример:
Я использовал Gulp, CodeKit и Yarn в разных проектах. Было бы неплохо иметь один инструмент для использования? Конечно! И каждый из них может делать относительно то же самое, что и другие.
Но скорость, с которой что-то нужно, чтобы что-то заработало, мобильность и доступные пакеты немного различаются, и если я работаю над чем-то для себя, для клиента, с командой или в одиночку, — все это факторы, которые сами по себе входят в уравнение. .
Я считаю, что со временем мы развиваем интуицию о том, какой из них лучше всего подходит для требований проекта и опыта работы с каждым из вышеперечисленных инструментов.
Так что, конечно, есть некоторые инвестиции, необходимые для ознакомления со многими из них, которые вы считаете нужными, чтобы быть полезными для вашей команды и усилий, но они могут сослужить вам хорошую службу, когда вы продолжаете двигаться вперед как разработчик.
Когда мы их используем?
Я не думаю, что на этот вопрос так сложно ответить, если вы проявили должную осмотрительность, опробовав их. Опять же с интуицией, да?
Но вот мой общий подход:
- Если я работаю один или мне нужно быстро сосредоточиться на чем-то, CodeKit — хорошее решение.
- Если я работаю в команде и мне нужно что-то быстрое, масштабируемое и четко определенное, Yarn — хороший выбор.
Я все еще думаю, что Gulp стоит взглянуть на использование, но разработка и пакеты для него, похоже, замедлились. Похоже, что Grunt в данный момент не находится в разработке, но если он работает для вас и нужных вам пакетов, возможно, не стоит менять его прямо сейчас.
На самом деле, я бы сказал, если вы не можете предоставить вескую причину для изменения, то зачем беспокоиться? Практичность имеет значение.
Стоит ли с ними связываться?
Я не знаю. Я имею в виду, что технологии развиваются так быстро, появляются новые инструменты (я не думаю, что мы всегда должны их использовать), а затем они остаются на какое-то время.
Возможно, они стагнируют. Возможно, они не получат широкого распространения. Возможно, они на пенсии.
Может быть, самый оптимальный ответ на этот вопрос — выяснить, что поможет вам решить проблему наиболее эффективным способом, что также поддерживается активным сообществом разработчиков и что вам и вашей команде легче всего принять?
Нижняя линия?
Во всяком случае, этот пост — не более чем личные размышления о том, как подойти к постоянно меняющемуся ландшафту инструментов сборки и менеджеров пакетов. И как рассуждать о том, когда кому дан определенный тип проблемы.
Я не обязательно хочу единого решения, потому что я думаю, что варианты, которые у нас есть, способствуют большему количеству инноваций. В то же время это может привести к усталости, когда вам нужно не отставать.
Итак, по крайней мере, изучите подмножество самых популярных инструментов (возможно, отмеченных звездочкой на GitHub в качестве полезной метрики), а затем двигайтесь дальше.