Это обзор моего выступления на DotJS в Париже в этом году.

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

Я давно занимаюсь веб-разработкой. Более 20 лет. Когда я начинал, это были буквально все поля. Взаимодействие на веб-сайтах означало, что нам нужно было отправлять формы и работать с логикой на сервере.
Когда появился JavaScript, все изменилось. Это позволило нам создавать интерфейсы с гораздо более высокой точностью воспроизведения, но этого оказалось недостаточно. Мы хотели выделиться лучше, чем «веб-разработчики» - термин, который тогда принижали «настоящие программисты».

JavaScript, DHTML, ненавязчивый JavaScript, Flash / Air / Flex, сценарии DOM, AJAX, Comet…

Мы придумали множество умных технологических терминов, таких как DHTML и AJAX, и рекламировали их как «стандарты де-факто». Мы также позвали всех непрофессионалов за то, что они их не приняли. Спустя годы мы продолжали ходить по кругу. Мы по-прежнему слишком полагались на JavaScript и проприетарные технологии. А потом мы сказали людям не делать этого.

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

Редакторы WYSIWYG не сделали веб-сайты пригодными для использования. Знание об ошибках браузера и способах их решения было преимуществом перед конкурентами. Была ли это профессиональная рабочая среда? Сомнительно, но творчески. Мы разработали множество передовых практик и назвали, например, множество приемов CSS для создания различных дизайнов в довольно неумелых браузерах.

Все началось, и мы узнали намного больше о нашей работе, когда инструменты отладки стали лучше. Он начался с Firebug и продолжился встроенными в браузер инструментами разработчика и специализированными IDE для работы в Интернете. Мы поняли не только то, что что-то пошло не так, но и почему. У нас также есть визуальные инструменты, позволяющие настроить параметры и посмотреть, что нужно для работы макета CSS.

Затем мы добавили абстракции…

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

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

В наши дни все по-другому. Мы говорим, что много развиваемся, но делаем что-то еще гораздо больше.

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

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

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

Кажется, что мы поглощены нашим собственным волнением делать что-то новое и необычное, а не принимать то, что довольно хорошо созрело с годами.

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

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

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

Чтобы убедиться в этом, давайте сделаем шаг назад от того, как используются технологии (какая платформа, какая структура, какая методология кода на сегодняшний день…), и посмотрим на потребности наших пользователей.

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

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

Еще одно «желание» наших конечных пользователей - безопасное использование платформы в полной мере. Например, разрешить биометрический вход в платежные системы на устройстве. У них есть эти устройства, они умеют ими пользоваться. Так почему мы навязываем им другой поток взаимодействия?
Мы должны создавать интерфейсы, которые позволяют людям делать ошибки, а не бросать их им обратно. Телефонный номер со скобками и пробелами несложно разобрать в нашем коде. Зачем просить людей написать это определенным образом или застрять? Используя обработку естественного языка, мы можем позволить пользователям вводить поисковые запросы людей. Давайте не будем заставлять их переходить по сложным интерфейсам, чтобы получить результат поиска.

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

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

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

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

Рассказ об исправлении опечатки…

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

Как оказалось, в проекте использовалась не разметка или HTML, а движок шаблонов. Локальная сборка проекта означала загрузку 150 МБ зависимостей. Затем это не удалось, потому что я попробовал это в своей оболочке Linux на своей машине с Windows. Некоторые зависимости совершенно очевидны для Mac без какой-либо информации об этом.

В конце концов, я исправил опечатки прямо на GitHub, используя необработанное представление. Я столкнулся с напрасной тратой времени и усилий, и меня это устраивает. Однако теперь представьте, что я человек, который просто хочет помочь проекту с открытым исходным кодом. Необеспеченный человек на низкоуровневом оборудовании с ненадежным или дорогим подключением в Интернете. Если не использовать веб-интерфейс GitHub, это будет означать, что я заблокирован, и я заплатил за это загрузкой 150 МБ.

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

У нас есть потрясающие технологии, и все же никто не счастлив.

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

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

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

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

В целом мы стали группой разработчиков full stackoverflow. Вместо того, чтобы изучать, как все работает, мы применяем их и надеемся на лучшее. Когда что-то идет не так, мы обращаемся за помощью в такие каналы, как Slack, Twitter или Stackoverflow, и просим исправить это. Скорость и характер голосования этих платформ отдают предпочтение быстрому и ориентированному на результат объяснению. Другими словами, люди, объясняющие, почему что-то не работает и что это может быть даже плохой идеей, не получают голосов. Те, кто дает вам «скопируйте и вставьте это, и все будет в порядке», прославятся как эффективные и великие разработчики. Аспект обучения - это не то, что мы хотим иметь - нам нужен только работающий ответ.

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

Итак, давайте посмотрим, на что мы тратим много энергии и что мы можем с этим поделать.

Когда вы открываете инструменты разработчика в браузерах, вы получаете огромное количество опций. Я почти уверен, что отдел дизайна и маркетинга не был бы счастлив, если бы это был коммерческий продукт. Это потрясающе - получить это в первый раз. Это не личное чувство. Если посмотреть на статистику использования инструментов в браузере, всегда используются 2–3 инструмента. Все остальные рассматриваются только при необходимости, да и то небольшой группой экспертов. Тем не менее, мы добавили их все и сразу сделали доступными. Это общеизвестная кухонная мойка. Это мешает людям использовать расширенную отладку в Интернете. Хотите доказательств? Спросите людей, как часто они используют отладку точки останова. Большинство из нас по-прежнему предпочитают - гораздо менее превосходный - console.log ().

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

Знание всех этих инструментов само по себе требует полной занятости. Прыжки от одного к другому - это когнитивные издержки, которые мы постоянно недооцениваем.

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

Это утомительно и кажется неоптимальным.

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

Многие отличные редакторы основаны на сети и могут работать либо в браузере, либо на компьютере в оболочке Electron. Это означает, что вы можете взломать редактор. Код Visual Studio, например, написан на TypeScript. Его расширения используют хорошо документированный API для создания интерфейсов. Что еще более важно, это также означает, что вы можете установить редактор на свой сервер и запускать его для своих пользователей. Это означает, что им не нужно ничего устанавливать на свои машины. Они могут открыть его в своих браузерах и начать кодировать или изменять настройки. GitHub включает в себя базовый редактор и даже полные IDE, такие как Visual Studio теперь доступна в виде онлайн-версии.

Это также позволяет предварительно настроить редактор на сервере. Участники могут использовать абстракции, такие как TypeScript или Sass, без их установки. Онлайн-редакторы, такие как CodePen, Stackblitz, Codesandbox, JSBin и другие, делают это и пользуются большим успехом. Они не только позволяют людям писать код, но и совместно работать над кодом и пробовать разные вещи без особых накладных расходов.

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

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

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

Оба этих ресурса - это не только продукты в сети. Они поставляются с API для получения контента и использования его в других продуктах.

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

Редакторы Word и другие текстовые редакторы помещают красные волнистые линии под орфографическими ошибками. Редакторы кода, такие как Visual Studio Code, использующие информацию из Mozilla Web Docs, могут делать то же самое. На приведенном выше снимке экрана показано расширение веб-подсказки, работающее внутри редактора. Под некоторыми элементами есть волнистые линии, что означает, что что-то не так.

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

Webhint также знает о проблемах совместимости между браузерами, например, о том, что элемент вывода не поддерживается более старыми версиями Internet Explorer.

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

А как насчет проблемы переключения контекста?

А как насчет проблемы переключения контекста? Поскольку и Visual Studio Code, и Edge основаны на Chromium, мы можем что-то с этим сделать. Представьте, что вы пишете Sass и переключаетесь в браузер, чтобы посмотреть, работает ли результат. Вы изменяете некоторые настройки в визуальных инструментах до тех пор, пока проблемы не будут устранены, а затем возвращаетесь в редактор. Вот тут-то и возникают сложности. Вы исправили сгенерированный CSS, но вам все еще нужно выяснить, какой Sass его сгенерировал. Используя расширение Elements for VS Code, вы можете встроить инструменты разработчика браузера прямо в редактор. Редактор запускает экземпляр браузера и скрывает его в фоновом режиме. Таким образом, вы можете использовать и редактор, и визуальные инструменты в одном контексте.

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

Если люди делают копирование и вставку кода, зачем им это делать? Компьютеры намного лучше анализируют производительность кода и находят закономерности. На этом скринкасте вы можете увидеть экспериментальную функцию Visual Studio Online под названием IntelliSense с искусственным интеллектом. Что он делает, так это использует модель машинного обучения, которая была обучена на наиболее успешных проектах с открытым исходным кодом на GitHub, которые выполняли задачи, аналогичные тем, что вы создаете. Затем он дает вам наиболее вероятные результаты в виде опции автозаполнения в редакторе. По сути, это копирование и вставка с гораздо большими вычислительными возможностями.

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

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

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

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