Роздум про сучасні менеджери пакетів
Нещодавно я розмовляв із другом про всі наявні сьогодні на ринку інструменти (деякі безкоштовні, інші з відкритим вихідним кодом), які допомагають нам у розробці.
До них належать такі речі, як:
- бурчання
- ковток
- Пряжа
- CodeKit
- Композитор
- і так далі.
Звичайно, кожне з перерахованих вище не обов’язково порівнюється, тому що одні є зовнішніми інструментами, інші — бекендовими, а є й такі, що пропонують свого роду гібриди.
Крім того, деякі є преміальними, деякі з відкритим вихідним кодом, деякі, здається, залишені, а деякі навіть призвели до несправних процесів збірки.
Це призводить до серії питань, деякі з яких я хотів би охопити. Отже, якщо не що інше, як роздуми про сучасні менеджери пакунків, це те, про що я думав.
Сучасні менеджери пакетів
Питання, які спали мені на думку (і які я обговорював із згаданим другом), такі:
- як ми маємо знати, що використовувати,
- коли їх використовувати,
- і чи варто їх дотримуватися?
І тому я вирішив поділитися своїми поточними думками щодо цих інструментів та їх застосування тут.
Які з них ми використовуємо?
Легко ухилитися від цієї відповіді та сказати «який завгодно», але я думаю, що відповідь дещо більш нюансована.
Наприклад, є криві навчання, пакети, технічне обслуговування тощо, які постачаються з кожним із них. Це не добре чи погано – це природно, якими вони є.
Мене більше цікавить питання: «Який із них найкраще служить моїй команді, моєму проекту та моїм клієнтам?» І ось чому:
- Якщо команда може легко засвоїти цю утиліту, тоді практично не буде труднощів почати роботу з нею.
- Якщо він добре працює з проектом із самого початку, то це має спростити технічне обслуговування, коли проект росте та розвивається. Це важливо, тому що інакше ми ризикуємо втратити дорогоцінний час і зусилля, щоб пришвидшити роботу, коли утиліта змінюється (якщо вона змінюється), і це може завдати шкоди графіку проекту.
- Я вважаю, що найкраще для клієнтів — це одна з тих ситуацій, коли «диявол криється в деталях». Це так, що якщо перші два задоволені, клієнт не буде розумнішим. По-друге, це коштувало б менше часу, забезпечувало б більшу цінність і змусило їх використовувати вас як постачальника своїх послуг.
Тим не менш, я не вірю, що існує єдиний випадок «Це утиліта, яку ви повинні використовувати», тому що, знову ж таки, я не знаю деталей певного проекту. Таким чином, я не хочу призначати одне рішення, коли інше може відповідати випадку.
І ось приклад:
Я використовував Gulp, CodeKit і Yarn у різних проектах. Було б добре мати єдиний інструмент для використання? звичайно! І кожен може робити відносно ті самі речі, що й інші.
Але швидкість, з якою потрібно щось розпочати, портативність і доступні пакети дещо відрізняються, і те, чи працюю я над чимось для себе, для клієнта, з командою чи самостійно, – це всі фактори, які впливають на рівняння .
Згодом я вважаю, що ми розвиваємо інтуїцію щодо того, який з них може бути найкращим, враховуючи вимоги проекту та досвід роботи з кожним із наведених вище інструментів.
Отже, звісно, є певні інвестиції, які потрібні, щоб ознайомитись із багатьма, які ви вважаєте за потрібне, щоб бути корисними для вашої команди та зусиль, але це може служити вам добре, коли ви продовжуєте рухатися вперед як розробник.
Коли ми їх використовуємо?
Я не думаю, що на це запитання так важко відповісти, якщо ви приклали належну увагу, випробувавши їх. Знову з інтуїцією, чи не так?
Але ось мій загальний підхід:
- Якщо я працюю сам або мені потрібно швидко на чомусь зосередитися, CodeKit — гарне рішення.
- Якщо я працюю з командою і мені потрібно мати щось швидке, масштабоване та чітко визначене, Yarn — хороший вибір.
Я все ще вважаю, що Gulp варто використати, але розробка та пакети для нього сповільнилися. Схоже, що Grunt на даний момент не розробляється, але якщо він працює для вас і пакетів, які вам потрібні, можливо, його не варто змінювати прямо зараз.
Насправді я б сказав, якщо ви не можете надати вагому причину для зміни, тоді навіщо турбуватися? Практичність має значення.
Чи варто залишатися з ними?
Не знаю. Я маю на увазі, що технології розвиваються дуже швидко, з’являються нові інструменти (які, на мою думку, не обов’язково слід застосовувати), а потім вони залишаються на деякий час.
Можливо, вони стагнують. Можливо, вони не досягають широкого поширення. Можливо, вони на пенсії.
Можливо, найоптимальнішою відповіддю на це запитання є з’ясувати, що допоможе вам вирішити проблему найефективнішим способом, який також підтримується активною спільнотою розробників і який ви та ваша команда можете найпростіше прийняти?
Суть?
У будь-якому разі ця публікація — не що інше, як особисті роздуми про те, як підійти до постійно мінливого ландшафту інструментів збірки та менеджерів пакетів. І це те, як міркувати, коли кому з них дано певний тип проблеми.
Я не обов’язково хочу єдине рішення, тому що я вважаю, що наші варіанти сприяють більшій кількості інновацій. У той же час це може викликати певну втому, коли вам потрібно не відставати.
Тож, якщо нічого іншого, перегляньте підмножину найпопулярніших інструментів (можливо, відмічених на GitHub як корисну метрику), а потім перейдіть звідти.