Что такое ide в контексте devtools

Консоль разработчика

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

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

Для решения задач такого рода в браузер встроены так называемые «Инструменты разработки» (Developer tools или сокращённо — devtools).

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

Для начала знакомства с этими мощными инструментами давайте выясним, как их открывать, смотреть ошибки и запускать команды JavaScript.

Google Chrome

В её JavaScript-коде закралась ошибка. Она не видна обычному посетителю, поэтому давайте найдём её при помощи инструментов разработки.

Нажмите F12 или, если вы используете Mac, Cmd + Opt + J .

По умолчанию в инструментах разработчика откроется вкладка Console (консоль).

Она выглядит приблизительно следующим образом:

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

• В консоли мы можем увидеть сообщение об ошибке, отрисованное красным цветом. В нашем случае скрипт содержит неизвестную команду «lalala».
• Справа присутствует ссылка на исходный код bug.html:12 с номером строки кода, в которой эта ошибка и произошла.

Под сообщением об ошибке находится синий символ > . Он обозначает командную строку, в ней мы можем редактировать и запускать JavaScript-команды. Для их запуска нажмите Enter .

Многострочный ввод

Обычно при нажатии Enter введённая строка кода сразу выполняется.

Чтобы перенести строку, нажмите Shift + Enter . Так можно вводить более длинный JS-код.

Теперь мы явно видим ошибки, для начала этого вполне достаточно. Мы ещё вернёмся к инструментам разработчика позже и более подробно рассмотрим отладку кода в главе Отладка в браузере.

Firefox, Edge и другие

Инструменты разработчика в большинстве браузеров открываются при нажатии на F12 .

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

Safari

Safari (браузер для Mac, не поддерживается в системах Windows/Linux) всё же имеет небольшое отличие. Для начала работы нам нужно включить «Меню разработки» («Developer menu»).

Откройте Настройки (Preferences) и перейдите к панели «Продвинутые» (Advanced). В самом низу вы найдёте чекбокс:

Теперь консоль можно активировать нажатием клавиш Cmd + Opt + C . Также обратите внимание на новый элемент меню «Разработка» («Develop»). В нем содержится большое количество команд и настроек.

Итого

• Инструменты разработчика позволяют нам смотреть ошибки, выполнять команды, проверять значение переменных и ещё много всего полезного.
• В большинстве браузеров, работающих под Windows, инструменты разработчика можно открыть, нажав F12 . В Chrome для Mac используйте комбинацию Cmd + Opt + J , Safari: Cmd + Opt + C (необходимо предварительное включение «Меню разработчика»).

Теперь наше окружение полностью настроено. В следующем разделе мы перейдём непосредственно к JavaScript.

Прокачиваем навыки отладки с помощью инструментов разработчика Chrome (часть 2)

Вы научились проверять сгенерированный HTML и применённые стили? Уже смело можете отлаживать JavaScript в браузере? Надеюсь, поскольку в этой серии мы рассмотрим продвинутые функции отладчика Chrome, закрепив навыки, полученные в первой части.

Освоив новые навыки, мы поэкспериментируем с базовыми примерами Kendo UI, а в конце статьи возьмём реальный пример jQuery Grid, чтобы отточить на нем свежеприобретенные знания.

В этой статье:

• Умное автодополнение
• Лёгкое обращение к выбранным элементам и вычисленным выражениям
• Просмотр всплывающих подсказок и элементов, которые скрываются автоматически
• Продвинутая отладка с помощью отладчика Chrome
• Контексты выполнения в отладчике Chrome
• Пример: компонент jQuery Grid из Kendo UI

Умное автодополнение

Умное автодополнение — известная функция в IDE, помогающая эффективнее писать код. В Chrome 68 разработчики DevTools включили аналогичные функции в консоль. А именно: упреждающее вычисление, автодополнение после выполнения функции и подсказки для аргументов.

Давайте рассмотрим эти возможности на примере следующей функции:

function test(yourValue) < return < value: yourValue, multiplied: yourValue * 3 >; >

Упреждающее вычисление

Вот что отобразится в консоли отладчика Chrome с включённым упреждающим вычислением:

Таким образом можно вычислять выражения в коде в консоли, если у этих выражений нет побочных эффектов (когда выполнение кода не только возвращает значение, но и делает ещё что-то). Подробнее о побочных эффектах можно узнать из вопроса «JavaScript-замыкания и побочные эффекты простым языком?» на StackOverflow

Совет: такое же вычисление происходит, когда вы открываете вкладку «Исходники» (Source) в режиме отладки и наводите на выражение или выделяете его.

Автодополнение после выполнения функции

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

Совет: сохраните результат функции в переменной (см. «Автодополнение IntelliSense для объектов на стороне клиента») и для проверки результата выполните функцию в консоли.

Затем используйте API консоли и сохраните выражение в переменной как var lastEvaluatedExpression = $_; .

Подсказки для аргументов

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

Лёгкое обращение к выбранным элементам и выполненным выражениям

В предыдущем разделе я не пояснил, что делает переменная $_. Это не магия, а часть встроенного API командной строки. Отладчик Chrome присваивает объекты и выражения списку предопределенных переменных. Например, при вычислении выражения 40+2 получится 42. И, допустим, мне лень запоминать, как называлась переменная или что это было за выражение, а тем более ждать 7.5 миллионов лет, пока компьютер высчитывает этот ответ. С отладчиком Chrome теперь достаточно переменной $_ .

API командной строки в отладчике Chrome сохраняет объекты и результаты выражения в предопределённые переменные. Консоль предоставляет ещё и такие полезные сокращения: $0 , $1 , $2 , $3 и $4 . $0 ссылается на последний выбранный элемент в панели «Элементы», $1 — на предыдущий, и так далее. Это может оказаться полезным, когда нужно получить ссылку на DOM-элемент, предоставляющий компонент или виджет, и вам нужно быстро проверить его доступные части.

Давайте поупражняемся с этим на примере PanelBar для Kendo UI, где мы обратимся к первому элементу, скроем его, а после покажем снова.

Совет: отладчик Chrome может подсказать вам, как оптимизировать изменения HTML и DOM, которые происходят в вашем приложении (см. «Молниеносное отображение списка в Angular»)

Просмотр всплывающих подсказок и элементов, которые скрываются автоматически

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

setTimeout() нужен для выполнения определённой логики через заданное время. А ещё он меняет порядок выполнения функций. Это пригодится при выполнении функции после быстрой анимации (см. «Почему setTimeout(fn, 0) иногда полезен?»)

Разобравшись, как работает setTimeout() , мы можем объединить его мощь с оператором debugger , и тогда можно будет активировать режим отладки, когда автоматически скрываемый элемент виден, и не бояться, что он тотчас же исчезнет.

На анимации ниже показано, как можно просмотреть всплывающую подсказку, вызывая setTimeout(function(), 3000) в консоли:

Совет: чтобы вывести в лог элементы, на которые в данный момент перешёл фокус, вставьте следующий код консоль: window.focusedelement; setInterval(function()< if(window.focusedElement != document.activeElement)>)

Для отмены повторения с интервалом можно перезагрузить страницу или использовать clearInterval() :

Продвинутая отладка с помощью отладчика Chrome

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

Точки останова по изменению DOM

Они прерывают выполнение скрипта, если у выбранного элемента в DOM меняется структура, атрибут или он удаляется с помощью JavaScript. Чтобы включить/выключить эту возможность, кликните правой кнопкой по элементу в панели «Элементы», наведите на пункт «Остановить» (Break) в контекстном меню и выберете «модификации поддерева» (subtree modifications), «модификации атрибута» (attribute modifications) или «удаление узла» (node removal).

Точки остановка для XHR/Fetch

Они прерывают выполнение скрипта, если адрес запрошенного ресурса содержит строку, на которую настроена точка останова. Чтобы включить/выключить эту возможность: разверните область «Точки останова для XHR» (XHR Breakpoints) в панели «Исходники», кликните на кнопку «Добавить точку останова» (Add breakpoint) и введите нужную часть URL.

Точки останова для обработчиков событий

Они прерывают выполнение скрипта при срабатывании событий мыши, клавиатуры, устройства, анимации и так далее. Чтобы включить/выключить эту возможность: разверните область «Точки останова для обработчиков событий» (Event Listeners Breakpoints) во вкладке «Исходники» и отметьте нужные (категории) события.

Точки останова для исключений

Они прерывают выполнение скрипта, когда выбрасываются обработанные или необработанные исключения. Чтобы включить/выключить эту возможность: нажмите кнопку «Пауза при исключении» (Pause on Exception) во вкладке «Исходники»; когда эта кнопка включена, появляется добавочная опция «Пауза при обработанных исключениях» (Pause on caught exceptions).

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

• Нажмите на кнопку «Продолжить» (Continue), чтобы показать раскрывающийся список и выберите кнопку «Продолжить без прерывания» (Continue without interruption).
• Нажмите F12 , чтобы быстро закрыть отладчик Chrome.

Во вкладке «Исходники» стоит упомянуть еще несколько областей.

• Вкладка «Выражения для отслеживания» (Watch expressions): позволяет отслеживать значения переменных и выражений в разные моменты времени.
• Раздел «Стек вызовов» (Call Stack) показывает путь выполнения, который привёл код к этой точке останова в обратном хронологическом порядке.
• Панель «Область видимости» (Scope): показывает, какие локальные и глобальные переменные определены в данный момент.

Контексты выполнения в отладчике Chrome

Вы когда-нибудь сталкивались с ошибкой ReferenceError (говорящей, что функция не определена) при попытке выполнить уже объявленную функцию в консоли браузера? Вы не одиноки, это частый случай.

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

Немного соображений насчёт контекста выполнения:

• Когда вы просматриваете какой-либо элемент, в качестве контекста выполнения автоматически выбирается страница, содержащая этот элемент
• Чтобы получить логи из всех контекстов в консоли, уберите галочку «Только выбранный контекст» (Selected context only) в настройках консоли.
• С правой стороны есть ссылка на файл, выполнивший функцию, которая отвечает за запись в логе.

Эти контексты хорошо видны в «песочнице» по Kendo UI, в которой мы сейчас потестируем вышеприведенные советы.

Пример: компонент jQuery Grid из Kendo UI

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

Задача: используйте JavaScript для изменения фона плавающего элемента, созданного при перетаскивании заголовка в этом примере из «песочницы» на основе демо компонента jQuery Grid из Kendo UI.

Пробуйте сделать это сами, но если не выйдет, воспользуйтесь следующими советами:

• Нужно поменять контекст на сам пример: Контексты выполнения в отладчике Chrome
• В правильном контексте прервите выполнение скрипта на странице после появления элемента: Просмотр всплывающих подсказок и элементов, которые скрываются автоматически
• Просмотр плавающего элемента: Просмотр сгенерированного HTML-кода элемента
• Доступ к элементу в консоли: Лёгкое обращение к выбранным элементам и вычисленным выражениям
• Используйте функциональность автодополнения, чтобы найти правильные свойства стилей элемента: Умное автодополнение

К этому моменту вы должны быть уже на «ты» с отладчиком Chrome — никакая магия CLI, автоматически скрывающиеся элементы или сложные сценарии отладки не могут помешать вам. Мы здорово овладели всем этим и одолели тёмную сторону. Кроме шуток, надеюсь, что эта статья была полезной и ответила хотя бы на один сложный вопрос — дайте знать. А что насчёт ваших советов и приёмов? Пожалуйста, поделитесь ими (потому что вам не всё равно) в комментариях ниже.

P.S. Это тоже может быть интересно:

• Псевдокласс :has() — не только «родительский селектор»
• Укрощаем режимы наложения: difference и exclusion
• Удар откуда не ждали: псевдокласс :has() ломает сайты на jQuery

Если вам понравилась статья, поделитесь ей!

Как использовать Google Chrome в качестве IDE?

В Developer Tools вроде есть кусками всё, что нужно для IDE: всякие отступы-подсветки-автодополнения, есть REPL, можно редактировать локальные файлы, но всё равно оно как-то непонятно и неудобно. Посоветуйте какие-то туториалы или что-то подобное, как настроить его, чтобы полноценно разрабатывать сайты с HTML+JS+CSS, как я это делаю в том же WebStorm-е, например.

Legioner ★★★★★
09.02.21 14:02:34 MSK

не ну я конечно понимаю что мы линуксоиды красноглазики, но это извращение

enep ★★★★
( 09.02.21 14:05:02 MSK )

Ты забыл тег «вещества».

Как Chrome DevTools с велосипеда на стандарт пересели

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

Введение

Как вы, возможно, знаете, Chrome DevTools — это веб-приложение, написанное с использованием HTML, CSS и JavaScript, которое с годами стало еще более многофункциональным. Хотя DevTools расширился, его архитектура во многом напоминает первоначальную, когда инструмент был частью WebKit.

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

Вначале не было ничего

Сейчас у фронтенда есть множество модульных систем и их инструментов, а также стандартизированный формат модулей JavaScript. Ничего этого не было, когда начинался DevTools. Инструмент построен поверх кода WebKit, написанного более 12 лет назад.

Первое упоминание о модульной системе в DevTools относится к 2012 году: это было введение списка модулей с соответствующим списком исходников. Часть инфраструктуры Python, используемой в то время для компиляции и сборки DevTools. В 2013 года модули были извлечены в файл frontend_modules.json этим коммитом, а затем, в 2014 году, в отдельные module.json (здесь). Пример module.json :

С 2014 года module.json используется в инструментах разработчика для указания на модули и исходные файлы. Тем временем экосистема веба быстро развивалась, и было создано множество форматов модулей: UMD, CommonJS и в конечном итоге стандартизированные модули JavaScript. Однако DevTools застрял на module.json . Не стандартизированная, уникальной модульная система имела несколько недостатков:

1. module.json требовал собственные инструменты сборки.
2. Не было интеграции с IDE. Конечно же, она требовала специальных инструментов для создания файлов, понятных ей: ( оригинальный скрипт генерации jsconfig.json для VS Code).
3. Функции, классы и объекты были помещены в глобальную область видимости, чтобы сделать возможным совместное использование между модулями.
4. Был важен порядок перечисления файлов. Не было никакой гарантии, что код, на который вы полагаетесь, загружен, кроме проверки человеком.

Преимущества стандарта

Мы выбрали модули JavaScript. Когда принималось это решение, модули в языке еще включались флагом в Node.js и большое количество пакетов NPM не поддерживало их. Несмотря на это, мы пришли к выводу, что модули JavaScript были лучшим вариантом.

Основное преимущество модулей в том, что это стандартизированный в языке формат. Когда мы перечислили минусы module.json , мы поняли, что почти все они были связаны с использованием не стандартизированного, уникального формата модуля. Выбор не стандартизированного формата модуля означает, что мы должны вкладывать время в построение интеграций с помощью инструментов сборки и инструментов наших коллег. Такие интеграции часто были хрупкими и не поддерживали функции, требуя дополнительного времени на техническое обслуживание, а иногда приводя к хитрым багам. Баги в конечном итоге доставались пользователям.

Поскольку модули JavaScript были стандартными, это означало, что IDE, такие как VS Code, инструменты проверки типов, похожие на компилятор Closure/TypeScript, и инструменты сборки вроде Rollup и минификаторов смогут понять написанный исходный код. Более того, когда новый человек присоединяется к команде DevTools, ему не приходится тратить время на изучение проприетарного module.json .

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

Сколько стоит блеск новизны?

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

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

Последний пункт оказался очень важным. Несмотря на то, что теоретически мы могли добраться до модулей JavaScript, во время миграции мы получили бы код, который должен был бы учитывать оба типа модулей. Такое не только технически сложно, но и означает, что все инженеры, работающие над DevTools, должны знать, как работать в такой среде. Они должны были бы постоянно спрашивать себя: «Что происходит в этом коде, это module.json или JS, и как я могу внести изменения?».

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

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

1. Убедиться, что стандартные модули максимально полезны.
2. Убедиться, что интеграция с существующими модулями на базе module.json безопасна и не приводит к негативному воздействию на пользователя (ошибки регрессии, разочарование пользователя).
3. Давать руководства по миграции DevTools. В первую очередь с помощью встроенных в процесс сдержек и противовесов, чтобы предотвратить случайные ошибки.

Электронная таблица, преобразования и технический долг

Цель была ясна. Но ограничения module.json оказалось трудно обойти. Потребовалось несколько итераций, прототипов и архитектурных изменений, прежде чем мы разработали удобное решение. Мы закончили тем, что написали проектный документ со стратегией миграции. В этом документе указывалась первоначальная оценка времени: 2-4 недели.

Самая интенсивная часть миграции заняла 4 месяца, а от начала до конца прошло 7 месяцев!

Первоначальный план, однако, выдержал испытание временем: мы хотели научить среду выполнения DevTools загружать все файлы, старым способом использовать перечисленные в массиве scripts module.json , в то время как все файлы, перечисленные в массиве modules должны были загружаться динамическим импортом языка. Любой файл, который будет находиться в массиве modules , может работать с import и export из ES6.

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

Фрагмент таблицы миграции здесь.

Фаза экспорта

Первым этапом было добавление операторов экспорта для всех сущностей, которые должны быть разделены между модулями/файлами. Трансформация автоматизировалась с помощью запуска скрипта для каждой папки. Допустим, в module.json есть такая сущность:

Module.File1.exported = function() < console.log('exported'); Module.File1.localFunctionInFile(); >; Module.File1.localFunctionInFile = function() < console.log('Local'); >; 

Здесь Module — это имя модуля. File1 — имя файла. В дереве кода это выглядит так: front_end/module/file1.JS .

Код выше преобразуется в такой:

export function exported() < console.log('exported'); Module.File1.localFunctionInFile(); >export function localFunctionInFile() < console.log('Local'); >/** Legacy export object */ Module.File1 = < exported, localFunctionInFile, >; 

Первоначально мы планировали переписать импорт в один файл на этом этапе. Например, в приведенном выше примере мы бы переписали Module.File1.localFunctionInFile на localFunctionInFile . Однако мы осознали, что было бы проще автоматизировать и безопаснее разделить эти два преобразования. Таким образом, «перенос всех сущностей в один файл» станет второй подфазой импорта.

Поскольку добавление ключевого слова export превращает файл из «скрипта» в «модуль», большая часть инфраструктуры DevTools должна была быть обновлена соответствующим образом. Инфраструктура включала среду выполнения с динамическим импортом, а также такие инструменты, как ESLint для запуска в режиме модуля.

Одна неприятность заключалась в том, что наши тесты выполнялись в «нестрогом» режиме. Модули JavaScript подразумевают, что файлы работают в строгом режиме. Это влияло на тесты. Как оказалось, нетривиальное количество тестов полагалось на нестрогий режим, включая тест, в котором присутствовал оператор with .

В конце концов, обновление самой первой папки (добавление export) заняло около недели и несколько попыток с перекладываниями.

Фаза импорта

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

Например, следующие сущности module.json :

Module.File1.exported(); AnotherModule.AnotherFile.alsoExported(); SameModule.AnotherFile.moduleScoped(); 

import * as Module from '../module/Module.js'; import * as AnotherModule from '../another_module/AnotherModule.js'; import from './AnotherFile.js'; Module.File1.exported(); AnotherModule.AnotherFile.alsoExported(); moduleScoped(); 

Однако при таком подходе есть оговорки:

1. Не каждая сущность была названа по принципу Module.File.symbolName . Некоторые сущности были названы Modele.File или даже Module.CompletelyDifferentName . Несоответствие означало, что мы должны были создать внутреннее сопоставление от старого глобального объекта к новому импортированному объекту.
2. Иногда возникали конфликты имен moduleScoped . Наиболее заметно, что мы использовали шаблон объявления определенных типов Events , там, где каждая сущность названа просто Events . Это означало, что при прослушивании нескольких типов событий, объявленных в разных файлах, в операторе import у этих Events возникнет коллизия именования.
3. Как оказалось, между файлами существовали циклические зависимости. Это было прекрасно в контексте глобальной области видимости, так как сущность использовалась после загрузки всего кода. Однако, если вам требуется импорт, циклическая зависимость проявит себя. Такое не приводит к проблеме сразу, если только у вас нет побочных вызовов функций в коде глобальной области видимости, (они были у DevTools). В общем, потребовалось некоторое хирургическое вмешательство и рефакторинг, чтобы обезопасить трансформацию.

Дивный новый мир модулей JavaScript

В феврале 2020 года, через 6 месяцев после старта в сентябре 2019 года, были выполнены последние очистки в папке ui/. Так миграция неофициально закончилась. Когда осела пыль, мы официально отметили миграцию как законченную 5 марта 2020 года.

Теперь DevTools работают только с модулями JavaScript. Мы все еще помещаем некоторые сущности в глобальную область видимости (в файлах легаси module.js ) для устаревших тестов или интеграций с другими частями инструментов разработчика архитектуры. Они будут удалены со временем, но мы не рассматриваем их как блокирующие развитие. У нас также есть руководство по стилю работы с модулями JavaScript.

Статистика

Консервативные оценки количества CL (аббревиатура changelist — термин, используемый в Gerrit, аналогичное пул-реквесту GitHub), участвующих в этой миграции, составляют около 250 CL, в основном выполняемых 2 инженерами. У нас нет окончательной статистики о размере внесенных изменений, но консервативная оценка измененных строк (сумма абсолютной разницы между вставками и удалениями для каждого CL) составляет примерно 30 000 строк, то есть около 20% всего интерфейсного кода DevTools.

Первый файл с применением экспорта поддерживается в Chrome 79, выпущенном в стабильном релизе в декабре 2019 года. Последнее изменение для перехода на импорт поставляется в Chrome 83, выпущенном в стабильном релизе в мае 2020 года.

Мы знаем об одной регрессии из-за миграции в стабильном Chrome. Автозавершение фрагментов кода в меню команд сломалось из-за постороннего экспорта по умолчанию. Было и несколько других регрессий, но наши автоматизированные тестовые наборы и пользователи Chrome Canary сообщили о них. Мы исправили ошибки до того, как они могли попасть в стабильные релизы Chrome.

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

Чему мы научились?

1. Принятые в прошлом решения могут оказать долгосрочное влияние на ваш проект. Несмотря на то, что модули JavaScript (и другие форматы модулей) были доступны в течение довольно долгого времени, DevTools не был в состоянии оправдать миграцию. Решение о том, когда мигрировать, а когда нет, трудно и держится на обоснованных догадках.
2. Первоначальные оценки времени — недели, а не месяцы. В значительной степени это связано с тем, что мы обнаружили больше неожиданных проблем, чем ожидали при первоначальном анализе затрат. Даже при том, что план миграции был основательным, технический долг блокировал работу чаще, чем нам хотелось бы.
3. Миграция включала большое количество (казалось, не связанных между собой) очисток технического долга. Переход к современному стандартизированному формату модулей позволил нам перестроить лучшие практики кодирования на современную веб-разработку. Например, мы смогли заменить пользовательский упаковщик Python на минимальную конфигурацию Rollup.
4. Несмотря на большое влияние на нашу кодовую базу (~20% измененного кода), было зарегистрировано очень мало регрессий. Хотя было много проблем с миграцией первых двух файлов, через некоторое время у нас был надежный, частично автоматизированный рабочий процесс. Это означало, что негативное влияние на наших стабильных пользователей было минимальным.
5. Научить коллег тонкостям конкретной миграции трудно, а иногда и невозможно. Миграции такого масштаба трудно отслеживать и они требуют большого объема знаний в предметной области. Передача этих знаний другим людям, работающим в той же кодовой базе, сама по себе нежелательна для работы, которую они выполняют. Знание того, чем делиться, а чем не делиться — необходимое искусство. Поэтому крайне важно сократить количество крупных миграций или, по крайней мере, не выполнять их одновременно.

Получить востребованную профессию с нуля или Level Up по навыкам и зарплате, можно, пройдя онлайн-курсы SkillFactory:

• Профессия Java-разработчик с нуля (18 месяцев)
• Курс по JavaScript (12 месяцев)

Eще курсы

• Обучение профессии Data Science с нуля (12 месяцев)
• Профессия Веб-разработчик (8 месяцев)
• Курс по Machine Learning (12 недель)
• Продвинутый курс «Machine Learning Pro + Deep Learning» (20 недель)
• Курс «Математика и Machine Learning для Data Science» (20 недель)
• Курс «Python для веб-разработки» (9 месяцев)
• Курс по DevOps (12 месяцев)
• Профессия аналитика с любым стартовым уровнем (9 месяцев)
• Профессия UX-дизайнер с нуля (9 месяцев)
• Профессия Web-дизайнер (7 месяцев)