Мы все знаем мем: к тому моменту, когда вы изучили одну технологию front-end, еще три были выпущены. А что насчет той, которую вы только что изучили? Она устарела.

И часто мы не можем выяснить почему.

Типичное объяснение (a la r/programming) похоже на то, что webdevs естественно нетерпеливы, чудаковаты и некомпетентны, и оно может представлять собой более общую ошибку: предполагая, что поведение, которое вы не можете понять, вызвано тем, что вся группа была глупой, злой или жадной (тогда как ваше собственное неразумное поведение обусловлено исключительно факторами, не зависящими от вас).

Тем не менее, ошибка или нет, у нас есть проблема - не так ли?

Количественная оценка проблемы

Прежде чем мы увлечемся, стоит проверить, действительно ли у мема есть реальная основа? Действительно ли frontend-технологии переднего плана меняются так быстро?

В плане основных технологий представления, вероятно, нет. Рассмотрим этот список наивысших «звездных» интерфейсных технологий JavaScript на Github:

2,5 года для самого молодой технологии не так уж и много в схеме вещей - например, это меньше половины срока службы вашей типичной настольной ОС, но это все еще отходит от нашей карикатуры. Итак, что вызывает это восприятие быстрых, даже неустойчивых изменений?

React и друзья

Это может быть React. Как мощный инструмент, он требует, чтобы армия вспомогательных модулей и библиотек поддержки использовалась серьезно, и именно здесь возникает проблема. Сообщество React очень велико в том, что я бы назвал «архитектурой микробиблиотеки», где приложения состоят из множества дискретных, одноцелевых библиотек JavaScript, в знак уважения к философии Unix.

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

И в этом суть моего аргумента: проблема с JavaScript не в языке [1], Интернете или какой-либо технологии в частности, а в плохой «архитектуре выбора», которая заставляет разработчиков подчиняться причудам и тенденциям.

Проблема NPM

Самый большой актив и ответственность самого JavaScript - это NPM. Он предоставляет огромное количество модулей, удовлетворяющих практически любой конкретной цели, которую можно себе представить, но очень сложно фильтровать и курировать. Какие из них действительно поддерживаются? Какие из них фактически функционально правильны? Какие из них на самом деле не просто векторы злой вредоносной программы? Единственная эвристика, которую может использовать JavaScript-разработчик, состоит в популярности - количестве загрузок и звезд Github - что усугубляет фанатизм.

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

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

Представьте, что вы - младший разработчик

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

Все начинается невинно. У вас есть совершенно чистый лист и вы хотите, чтобы все было просто. Вы благочестивый Агилист, а YAGNI - ваш лозунг. Итак, вы начинаете с «простой структуры». Это звучит хорошо, не так ли? (Даже если это не так, это часто единственный выбор, который у вас есть).

Будучи “голым железом”, оно мало что делает, поэтому задача ложится на ваши плечи, чтобы выбрать некоторые вспомогательные библиотеки. Если вы выполняете внешнюю работу, это могут быть помощники для Redux для форм и запросов API. Если бэкэнд, это может быть промежуточное ПО для Express [2].

Таким образом, вы выполняете поиск в Google, который показывает пост Medium, который от души рекомендует X.js. Позже это сообщение было написано автором X, хотя он никогда не объявляет об этом конкретном конфликте интересов (однако он предоставляет банку GitTip). Не то чтобы вы могли сказать - все статьи Medium выглядят одинаково, поэтому вы никогда не сможете опираться на «бренд», чтобы идентифицировать авторитетный материал.

Вы пропускаете ответы, указывая на некоторые критические недостатки в X.js, потому что Medium намеренно подавляет их и переходите к поиску Y

На этот раз вы найдете ссылку на Twitter - с более чем сотней лайков! Вы догадываетесь, что это очень хороший сигнал, что это было написано «куратором» сообщества, более осведомленным, чем вы. Вы добавляете свой лайк в благодарность (например, к сотне предыдущим) и следуете ссылке на Github.

Но не так быстро. Эта ссылка была старой - теперь библиотека устарела. Вы можете сказать, потому что слово “НЕ РЕКОМЕНДУЕТСЯ”  размещено повсюду, как знаки “ПОД АРЕСТОМ” в тематическом парке Scooby Do.

Видите ли, Y.js был «объектно ориентированным». Вы думали, что это хорошо, смутно вспоминая что-то с первого года ComSci о Smalltalk и передаче сообщений. Но, видимо, это очень плохо.

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

Становится хуже. Пост утверждает, что даже упоминание ООП в интервью с JavaScript сделает вас совершенно безработным! Теперь вы серьезно дезориентированы. К счастью, помощь под рукой - в виде курса на веб-сайт JavaScript на 50 долларов США. Вы обратите внимание на ссылку, думая, как повезло, что вы ее нашли, и подарите еще один хлопок в благодарность. (19001-й).

Таким образом, вы переходите на Z.js, который, кажется, имеет намного больше звезд Github, хотя документация кажется менее полезной. Множество методов перечислены, “но как я его практически использую?” Вы, во всяком случае, вы рады видеть, что он использует что-то под названием «Стандарт JS», что, как вы полагаете, имеет отношение к Комитету по стандартам ECMA. Это не так.

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

Так. Вы берете путь наименьшего сопротивления: вы выбираете проект Github с большинством голосов, большинство звезд. Вот почему JavaScript dev управляется причудами и шумихой.

Что надо сделать?

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

Будьте осторожны с Medium

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

Будьте осторожны с саморекламой

За последние несколько лет я видел гораздо более агрессивный самомаркетинг в мире JavaScript, возможно, из-за роста платных онлайновых учебных материалов и преимуществ работы / консалтинга тех, кто является в Github “знаменитостью”. У меня нет проблем с тем, чтобы люди рекламировались для хорошего контента, но все чаще чувствую, что вижу нечестную тактику: самопричисление; (так что поиск возвращает вас к материалам автора) и заимствование имени (например, «Standard.js»)

Рассмотрите архитектуры без микролиба

Попытайтесь начать свои проекты со структурой, которая обеспечивает большую контактную зону и не требует много плагинов для получения производительности - это немедленно уменьшит количество движущихся частей и подверженность неожиданным изменениям. Это одна из причин, по которой меня очень интересует Vue.js. Вы также можете использовать React как часть стартового набора или более крупного фреймворка, например Next.

Не перегружайте предмет занятости

Единственные люди, которые должны знать весь стек компании внутри и снаружи в нулевой день, являются внештатными подрядчиками, которым платят приличную заработную плату, чтобы они десантировали и получили внешний проект. В противном случае большинство работодателей абсолютно уверены в том, что вы не знаете, как входить в состав последней справочной библиотеки React. Поэтому избегайте призыва узнать абсолютно все: большая часть из этого и так слышна.

Заметки

[1] Хотя у него много, много недостатков.

[2] Можете ли вы полагать, что Express требует промежуточного программного обеспечения для разбора тел JSON POST? Извините, но это абсолютный бред.

No Comments