Интернет-сбой в среду вызвал целую волну твитов, сообщений и даже однострочных комментариев как услуги, посвященных текущему состоянию сообщества JavaScript и его культовому стремлению. микропакетов.
Это особенно вызвало дискуссию о том, что упаковка одной строки функционирует как пакеты, и сколько пакетов в итоге получится, в зависимости от них. « Неужели мы разучились программировать? » Лучше ли создавать микропакеты, такие как isarray, которые можно переписать за 5 минут? Неужели нам действительно нужно 28000 файлов для пустого шаблона проекта JSPM?
Давайте попробуем ответить на эти вопросы, начав с обратного первого: Мы действительно умеем программировать?
Сообщество как платформа
Современная разработка программного обеспечения - молодая дисциплина. За последние 20–30 лет шаблоны и передовые практики начали развиваться и развиваться, и я уверен, что мы только начинаем царапать поверхность, когда дело касается производительности.
Одна из самых больших проблем - это боязнь изобретать велосипед при написании наших программ. Я работаю студентом-разработчиком JavaScript, которому почасовая оплата за исправление конкретных проблем в моей команде. Причина, по которой мы даже можем разрабатывать рентабельные решения для наших клиентов, заключается в том, что мы можем полагаться на сообщество открытого исходного кода в отношении существующих решений, которые соответствуют нашим потребностям.
Это означает, что я могу полностью сосредоточить свое время и усилия на разработке на проблемах, за решение которых мне платят, и не возиться с решением проблем, которые уже решили тысячи других разработчиков. Я могу повторно использовать общие решения, чтобы включить их в свое решение моей проблемы.
Платформа, на которую я здесь полагаюсь, не является ни JavaScript, ни Node, ни React, ни даже npm. Платформа, на которую я полагаюсь, - это само сообщество и его развитые идеи. Я переосмысливаю идеи для решения моих проблем, и когда я обнаруживаю проблему, которая еще не решена, я могу предоставить решение, которое затем можно использовать для решения следующей проблемы, с которой может столкнуться кто-то другой.
Не думаю, что мы забыли программировать. Я думаю, что все наоборот. Мы начинаем учиться программировать или, в частности, учимся программировать вместе.
Написать код легко, но написание никогда не было проблемой
Иногда нам нужно знать, смотрим ли мы на массив. Решение из пакета isarray решает эту проблему аналогично следующей строке:
Array.isArray || function (arr) { return {}.toString.call(arr) == ‘[object Array]’;}
Глупо использовать другую зависимость для этой простой строчки кода, верно? Мы можем просто создать нашу собственную функцию и вставить ее в наш код, что займет менее 2 минут, включая поиск в Google.
Но в тот момент, когда мы вставили это в наш код, мы создали для себя много работы, которая может преследовать нас позже:
- Работает ли этот фрагмент кода на нас прямо сейчас?
- Будет ли он работать в будущем?
- Кто отвечает за то, чтобы он работал в будущем?
- Кто пишет тесты для этого кода?
- Где мы поместим этот код в наше решение?
- Что, если кто-то предложит лучший способ решения проблемы?
Я хочу сосредоточиться на последнем вопросе, потому что я думаю, что он поднимает самую большую проблему. В тот момент, когда мы вставляем код в наше решение, мы создаем его изолированную вилку. Всякий раз, когда кто-то предлагает лучшую идею или JavaScript развивается и наше решение устаревает, у нас есть сломанный код, и кто-то должен его исправить.
Решение? Сам пакет. Передав код в пакет isarray на аутсорсинг, мы передали решение проблемы в пакет, который можно поддерживать изолированно. Если бы я придумал лучшее решение, я бы не имитировал существующее, а вместо этого сделал бы запрос на перенос, и в следующий раз, когда я построю свой код, я буду иметь это решение как часть моего приложения. И самое большое преимущество: И все остальные тоже.
28000 файлов для пустого шаблона - индикатор возможных улучшений нашего рабочего процесса
Этот замечательный пост также поднял вопрос о том, что слишком много файлов требуется в качестве отправной точки для пустого проекта. Я определенно согласен с этой предпосылкой, но я думаю, что мы должны сделать шаг назад и посмотреть на основную проблему и найти решение для ее решения.
Видите ли, причина, по которой мы выполняем npm install в первую очередь, заключается только в том, чтобы собрать и протестировать наш код. Но действительно ли нам нужен этот шаг? Код - это текст, он не изменится, установлены ли у меня его зависимости или нет. Причина, по которой мы должны установить все эти зависимости локально, просто потому, что на данный момент мы должны собрать наш код локально.
Но что, если бы мы изменили этот рабочий процесс? Видео, аудио, изображения и даже текст успешно транслируются через Интернет, позволяя все большему количеству пользователей получать свой контент по запросу, вместо того, чтобы требовать бумажную копию на своем локальном диске. Почему то же самое не должно относиться к нашим зависимостям?
Почему мне нужно писать код локально и в моей системе должны быть установлены все зависимости? В любом случае я использую редактор кода, основанный на веб-технологиях. Я не думаю, что это научная фантастика, что когда-нибудь я просто перейду к URL-адресу и начну писать код. И когда этот день наступит, я больше не буду думать о количестве файлов, с которыми идут мои зависимости, я даже не буду думать о количестве зависимостей, на которые я полагаюсь. Когда наступит этот день, я буду развивать текущие идеи прямо там, где они хранятся. Непосредственно в сети, в сообществе открытого исходного кода.
Заключение
В разбивке по этой неделе были выявлены проблемы, с которыми приходится сталкиваться сообществу JavaScript. Мы столкнулись с серьезными проблемами, связанными с законами об авторском праве и инфраструктурой наших систем пакетов.
Но я считаю, что это можно рассматривать как положительный момент. Это можно рассматривать как отправную точку для лучшего кода, лучших рабочих процессов и лучшей командной работы в сообществе в целом. Его можно рассматривать как ориентир, как улучшить нашу инфраструктуру, чтобы этого больше не повторилось.
Смехаться и шутить над этими вещами весело и легко. Но мы могли бы также использовать энергию и время, которые мы тратим на создание библиотек и служб шуток, и использовать их для улучшения нашего сообщества, шаг за шагом.
Наш опыт разработки - это то, что мы делаем из этого, микропакеты могут показаться глупыми и иногда доводятся до крайности. Но основная идея, лежащая в основе этого, представляет будущее, в котором сотрудничество и сообщество находятся в центре внимания, и даже несмотря на то, что у нас может не быть идеального представления этого в сегодняшней инфраструктуре, я думаю, что мы определенно находимся на чем-то великом, от чего не следует отказываться. момент возникают первые проблемы. Вместо этого мы должны сосредоточиться на преимуществах и посмотреть, что мы можем сделать, чтобы вывести наше сообщество на новый уровень.
