Усталость от JavaScript стала распространенной фразой в мире современных интерфейсных разработчиков. Может показаться, что каждый день появляется новая разрекламированная структура, архитектура, инструмент командной строки или служба разработчика SaaS. Постоянный отток новых вещей может в конечном итоге оставить разработчиков более измученными, чем взволнованными.

Чтобы избежать этого, важно выработать твердый инстинкт для отделения технологий и продуктов, на которые стоит потратить время, от тех, которые уйдут в небытие после того, как их 15 минут славы истекут, их избранная статья на TechCrunch исчезла в архивах, или последний пассивно-агрессивный комментарий к их «Show HN» давно забыт.

Мой путь программиста начался почти 30 лет назад, когда я получил свой первый компьютер: бывший в употреблении Commodore 64, который приветствовал меня мигающим курсором при входе в «Basic V2».

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

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

В пространстве, которое так много и так часто меняется, легко принять как должное, что поток релизов действительно новый. Но технология имеет тенденцию быть удивительно цикличной; то, что на первый взгляд может показаться новым, обычно имеет глубокие исторические корни.

Когда в 2004 году вышел Ruby on Rails, он стал стремительно расти и оказал огромное влияние на отрасль. В то же время большинство идей, лежащих в основе шаблона Model View Controller (MVC), на котором он был основан, а также базовых шаблонов объектной ориентации из Ruby, восходят к среде программирования Small Talk с конца 70-х годов.

Для разработчиков, которые в то время свободно владели основными веб-платформами (PHP, Java, ASP), Ruby on Rails представил не просто совершенно новый язык с новым синтаксисом, но и новые концепции и основную новую парадигму для метапрограммирования. Однако для разработчиков, которые следили за ростом (и падением) SmallTalk и языков и платформ, вдохновленных им, Ruby on Rails был полон знакомых концепций (с небольшим новым синтаксисом и некоторой адаптацией из мира созданных приложений Small Talk в Интернет). Все, что им нужно было изучить, - это (важные, но не огромные) различия между Ruby и Small Talk, а также концептуальные различия между MVC для Интернета и MVC для приложения Small Talk.

Точно так же, когда вышел React, казалось, что он мгновенно сместил в сторону целое поколение фреймворков JavaScript. Большинство из них пытались перенести в браузер модель MVC, вдохновленную Rails. Многим разработчикам это казалось резким отходом как от фреймворков одностраничных приложений, основанных на шаблонах с двусторонней привязкой данных, так и от более простых библиотек, таких как jQuery. Но по своей сути React был вдохновлен идеями функциональных языков программирования (особенно OCAML), которые восходят к ранним дням развития вычислений.

Создатель React Джордан Уолк недавно описал, как его собственное путешествие в историю дало ему предпосылки, необходимые для создания React:

  • Долгое время я просто думал: «Ну что ж, я просто странный программист». Затем я, наконец, прошел курс по основам языка программирования (который использовал ML (SML) для большей части курсовой работы), и у меня наконец появилась базовая терминология, чтобы описать, как я хочу создавать приложения. Я также узнал, что стиль программирования, к которому я стремился, не был ни странным, ни новым, а на самом деле был ближе к некоторым из старейших философий языков программирования - философиям, которые никогда не становились мейнстримом, - философиям, которые индустрия потратила более двадцати лет. подрыв (на мой взгляд, в их ущерб).
  • https://www.reactiflux.com/transcripts/jordan-walke/

Для многих фронтенд-разработчиков путешествие в более полноценный мир полноценного управления состоянием в React с некоторой формой архитектуры «Flux», такой как Redux, возможно, в сочетании с Immutable.js, может показаться ошеломляющим. Но для разработчиков с прочной исторической основой, которые следили за возрождением функционального программирования - и концепциями вокруг него, восходящими к созданию LISP в 1958 году, - React отражает знакомые концепции и идеи.

Даже когда вы активно пытаетесь изучить новую технологию, история может быть полезным учителем. Когда Rails был впервые выпущен, было сложно найти материал о нем, кроме нескольких онлайн-документов, руководств и самого исходного кода (подробнее об исходном коде позже). Тем не менее, много было написано об эволюции MVC через Small Talk до Objective C, и много уроков, извлеченных из работы с метапрограммированием и ООП на основе передачи сообщений в мире Small Talk.

Это может быть отличным инструментом для более быстрого изучения новых технологий: вместо того, чтобы читать последние учебные пособия и появляющуюся документацию, выясните, что их вдохновляет, какие предыдущие знания они опираются и опираются. Скорее всего, материалы об этих старых технологиях, идеях и методологиях будут гораздо более зрелыми, и вы найдете много извлеченных уроков, которые, скорее всего, применимы к новому подходу к этой области.

Твердое историческое знание дает вам действительно хороший набор инструментов, чтобы задать вопрос: что изменилось на этот раз? Ответ (или его отсутствие!) На этот вопрос очень часто определяет успех или неудачу новой технологии.

Люди, культура и сообщество имеют значение
Легко подумать, что инструменты и технологии просто развиваются сами по себе. Например, объектно-ориентированное программирование превратилось в функциональное программирование, текстовые редакторы превратились в полноценные IDE, а динамические языки превратились в языки со статической типизацией. Однако новые технологии и фреймворки не просто следуют эволюционным путем сами по себе. Они изобретены, созданы и распространены людьми, организациями и сообществами.

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

Одно из моих любимых эссе о том, почему одни инструменты побеждают, а другие исчезают, - это книга Ричарда П. Габриэля Чем хуже - тем лучше »из 1989 года. В нем описывается возможная причина, по которой Unix и C обогнали технологии на основе LISP - причину это не имело ничего общего с качествами, присущими этим двум решениям.

В эссе Габриэль описывает подход «хуже - лучше», школа дизайна Нью-Джерси в отличие от школы MIT / Стэнфорд, которая ставит простоту реализации выше, чем простоту или правильность интерфейса конечного пользователя. Этот фокус позволил C и Unix превзойти LISP на рынке. Компиляторы C было проще реализовать, портировать и оптимизировать, чем компиляторы LISP, и это позволило разработчикам Unix гораздо быстрее передать программное обеспечение в руки пользователей. Это привело к более быстрому внедрению и, в конечном итоге, означало, что гораздо больше людей (и компаний) было инвестировано в развитие и улучшение экосистемы C / Unix.

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

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

Если вы сможете определить инструменты, которые живут на этом пересечении, то изучение их может дать вам следующую сверхдержаву разработчика.

Всегда Поймите «почему»
Когда я только начинал разработку, ближе всего к StackOverflow были компьютерные журналы с исходным кодом, который можно было вручную ввести в свой терминал, чтобы получить запущенные программы.

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

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

Не будь этим разработчиком. Возьмите за правило никогда не использовать решение из Stack Overflow или где-либо еще, прежде чем вы потратите время, чтобы понять, почему это решение может работать. Бросьте себе вызов, сделайте еще один шаг и выясните, что вам потребовалось бы, чтобы самому придумать это решение.

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

Так же подходите к новым технологиям. Не сосредотачивайтесь на поверхностном обучении. Изучение синтаксиса для нескольких различных фреймворков или языков не многому вас научит, но изучение процесса принятия решений, скрытого за этими технологиями, в корне сделает вас лучшим разработчиком.

Когда все сказано и сделано, самое важное - это не что вы изучаете (какой фреймворк, какой инструмент, какой язык), а что вы из него извлекаете.

Применение этих уроков на практике

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

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

Люди, культура и сообщество имеют значение
Благодаря стремительному развитию GitHub, Stack Overflow и NPM стало намного проще получить раннее представление о том, как будет масштабироваться сообщество и как разработчики реагируют на его амбиции. Хотя участники и звезды могут многое рассказать об уже успешных проектах, они не всегда являются хорошими ранними индикаторами успеха. Однако вы можете использовать ту же логику, чтобы определить, будет ли проект одобрен сообществом, как вы, возможно, уже использовали для создания своего собственного программного обеспечения, или выбрать, в какой компании вы хотите работать:

  • Есть ли четко определенное видение?
  • Есть ли явная потребность пользователя?
  • Имеются ли нужные люди, ресурсы и документация для масштабирования?
  • Это расширяемое? То есть может ли он масштабироваться или адаптироваться для обслуживания новых технологий или типов пользователей?
  • И, может быть, кто за этим стоит?

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

У Майкла Фезерса есть отличный список 10 статей, которые должен прочитать каждый разработчик. Все они посвящены фундаментальным идеям о языках, архитектуре и культуре и задают отличную основу для понимания идей, лежащих в основе многих тенденций, которые все еще вызывают волну в программировании сегодня.

Идите вперед и погрузитесь во все новое! Но делайте это в разумном темпе. Темп, который дает вам время для создания правильного фундамента. Это в конечном итоге позволяет вам быстрее внедрять новые технологии, глубже понимать их и более тщательно оценивать их жизнеспособность.