Соответствие экосистеме платформы JavaScript
В нашем вводном сообщении в блоге мы рассказали, как многому научились при создании и использовании платформ и инструментов для разработки и поддержки крупномасштабных веб-приложений, таких как Поиск Google, Карты, Фотографии и т. д. Защищая разработчиков от написания кода, который может негативно повлиять на взаимодействие с пользователем, мы доказали, что платформы могут играть ключевую роль в изменении результатов в отношении производительности и качества приложений.
Внутри Google мы использовали термин « Соответствие » для описания этой методологии, и в этой статье рассказывается, как мы планируем открыть исходный код этой концепции для экосистемы платформы JavaScript.
Что такое соответствие?
В Google соответствие стало эволюцией. Команды полагались на небольшую группу опытных специалистов по сопровождению, которые проводили обширные проверки кода, отмечая проблемы, которые влияли на качество и удобство обслуживания приложения, выходящие далеко за рамки проблем с корректностью. Чтобы масштабировать это для растущих команд разработчиков приложений, была разработана система соответствия, позволяющая систематизировать лучшие практики таким образом, чтобы это было автоматизировано и осуществимо. Это обеспечило неизменно высокую планку качества приложений и удобства сопровождения кодовой базы независимо от количества участников кода.
Соответствие — это система, которая гарантирует, что разработчики останутся на хорошо освещенном пути; это укрепляет доверие и обеспечивает предсказуемые результаты. Это делает команды продуктивными и становится решающим фактором для масштабирования — по мере того, как команды растут и одновременно разрабатывается больше функций. Это дает разработчикам возможность сосредоточиться на создании функций продукта, освобождая их от мелочей и меняющегося ландшафта в различных областях, таких как производительность, доступность, безопасность и т. д. Любой может отказаться от соответствия требованиям в любое время, и его следует настраивать в той степени, в которой это необходимо. что команды будут иметь возможность обеспечивать соблюдение всего, что они решат взять на себя.
Соответствие основано на строгих значениях по умолчанию и обеспечении действенных правил , которые можно применять во время разработки . Это распадается на следующие 3 принципа.
1. Сильные дефолты
Основополагающим аспектом соответствия является обеспечение наличия в инструментах, используемых разработчиками, надежных параметров по умолчанию. Это означает, что решения не только встроены в фреймворки, но и шаблоны проектирования фреймворков позволяют легко поступать правильно и трудно следовать антишаблонам. Платформа поддерживает разработчиков в дизайне приложений и структуре кода.
Для повышения производительности загрузки каждый ресурс (шрифты, CSS, JavaScript, изображения и т. д.) должен быть оптимизирован. Это сложная задача, включающая обрезку байтов, сокращение циклов обработки и разделение того, что необходимо для первого рендеринга, визуальной готовности и взаимодействия с пользователем. Например, извлечение критического CSS и установка приоритета для важных изображений.
2. Действенные правила
Даже при наличии фундаментальных оптимизаций разработчикам все равно приходится делать выбор. Существует целый ряд возможностей для оптимизации, когда дело доходит до того, сколько усилий потребуется разработчику:
- Значения по умолчанию, которые не требуют участия разработчика, например встраивание критического CSS.
- Требовать согласия разработчика. Например, используя компонент изображения, предоставляемый платформой, для изменения размера и масштабирования изображений.
- Требуйте согласия разработчика и настройки. Например, пометить важные изображения для ранней загрузки.
- Это не конкретная функция, а вещи, которые все еще требуют решения разработчика. Например, избегайте использования шрифтов или синхронных скриптов, которые задерживают ранний рендеринг.
Оптимизации, требующие какого-либо решения со стороны разработчиков, создают риск для производительности приложения. По мере добавления функций и масштабирования вашей команды даже самые опытные разработчики не могут идти в ногу с постоянно меняющимися передовыми практиками, и это не лучшее использование их времени. Для соответствия соответствующие действенные правила так же важны, как и строгие значения по умолчанию, чтобы гарантировать, что приложение продолжает соответствовать определенному стандарту, даже когда разработчики продолжают вносить изменения.
3. Время создания
Важно выявлять и предотвращать проблемы с производительностью на ранних этапах жизненного цикла разработки. Время разработки до фиксации кода идеально подходит для выявления и решения проблем. Чем позже проблема обнаруживается в жизненном цикле разработки, тем труднее и дороже ее решить. Хотя это относится к проблемам корректности, это также верно и для проблем с производительностью, поскольку многие из этих проблем не будут решены задним числом после внесения в базу кода.
Сегодня большая часть отзывов о производительности выходит за рамки документации, разовых аудитов или обнаруживается слишком поздно из-за регрессии показателей после развертывания в рабочей среде. Мы хотим перенести это на время разработки.
Соответствие в фреймворках
Чтобы поддерживать высокий уровень пользовательского опыта для производительности загрузки, необходимо ответить на следующие вопросы:
- Что представляет собой оптимальная загрузка и каковы общие проблемы, которые могут отрицательно повлиять на нее?
- Какие решения можно внедрить, не требуя участия разработчика?
- Как мы можем гарантировать, что разработчик использует эти решения и использует их оптимально?
- Какой еще выбор разработчик мог бы повлиять на производительность загрузки?
- Какие шаблоны кода могут рассказать нам об этих вариантах (№ 3 и № 4 выше) на ранних стадиях разработки?
- Какие правила мы можем сформулировать для оценки этих шаблонов кода? Как их можно предоставить разработчику во время разработки и при этом легко интегрировать в его рабочий процесс?
Чтобы перенести модель соответствия, которую мы имеем в Google, на платформы с открытым исходным кодом, наша команда провела активные эксперименты с Next.js, и мы рады поделиться нашим усовершенствованным видением и планами. Мы поняли, что лучший набор правил, позволяющий оценить шаблоны кода, должен представлять собой комбинацию статического анализа кода и динамических проверок. Эти правила могут охватывать несколько поверхностей, в том числе:
- ESLint
- Машинопись
- Динамические проверки на сервере разработки пользователя (после создания DOM)
- Сборщик модулей (веб-пакет)
- Инструменты CSS (все еще в стадии разработки)
Воспользовавшись преимуществами предоставления правил с помощью различных инструментов, мы можем обеспечить их связность, а также учесть любые проблемы взаимодействия с пользователем, которые напрямую влияют на производительность загрузки. Кроме того, эти правила также могут быть доступны разработчикам в разное время:
- Во время локальной разработки на сервере разработки браузер и IDE пользователя будут отображать предупреждения, побуждающие разработчиков внести небольшие изменения в код.
- Во время сборки нерешенные проблемы будут снова отображаться в терминале пользователя.
Короче говоря, команды будут выбирать результаты, которые их волнуют, такие как основные веб-показатели или производительность загрузки, и включать соответствующие наборы правил для всех участников кода.
Хотя это очень хорошо работает для новых проектов, нелегко обновить большие базы кода, чтобы они соответствовали полным наборам правил. В Google имеется обширная система отказа на различных уровнях, таких как отдельные строки исходного кода, целые каталоги, устаревшие кодовые базы или части приложения, которые не находятся в активной разработке. Мы активно изучаем эффективные стратегии, позволяющие донести это до команд, использующих платформы с открытым исходным кодом.
Соответствие в Next.js
ESLint широко используется среди разработчиков JavaScript. и более 50% приложений Next.js используют ESLint в той или иной части рабочего процесса сборки. В Next.js v11 представлена встроенная поддержка ESLint, которая включает в себя собственный плагин и общую конфигурацию , чтобы упростить выявление распространенных проблем, специфичных для платформы, во время разработки и во время сборки. Это может помочь разработчикам исправить серьезные проблемы во время разработки. Примеры включают случаи, когда определенный компонент используется или не используется таким образом, что может нанести ущерб производительности, как в случае «Нет ссылки HTML для страницы »). Или, если определенный шрифт, таблица стилей или скрипт могут негативно повлиять на загрузку ресурсов на странице. Например, Нет синхронного сценария .
Помимо ESLint, встроенная проверка типов как при разработке, так и при производстве поддерживается в Next.js начиная с версии 9 с поддержкой TypeScript. Несколько компонентов, предоставляемых платформой (Image, Script, Link), были созданы как расширение элементов HTML ( <img> , <script> , <a> ), чтобы предоставить разработчикам эффективный подход к добавлению контента на веб-страницу. Проверка типов поддерживает правильное использование этих функций, гарантируя, что назначенные свойства и параметры находятся в допустимой области поддерживаемых значений и типов. Пример см. в разделе требуемая ширина и высота изображения .
Выявление ошибок с помощью всплывающих уведомлений и наложений
Как упоминалось ранее, правила соответствия могут применяться в нескольких областях. В настоящее время изучаются всплывающие уведомления и наложения как способ выявления ошибок непосредственно в браузере в локальной среде разработки пользователя.
Многие инструменты проверки ошибок и аудита, на которые полагаются разработчики (Lighthouse, вкладка «Проблемы Chrome DevTools»), являются пассивными и требуют определенной формы взаимодействия с пользователем для получения информации. Разработчики с большей вероятностью будут действовать, когда ошибки обнаруживаются непосредственно в их существующих инструментах, и когда они предлагают конкретные и конкретные действия, которые следует предпринять для устранения проблемы.
Соответствие в других платформах
Соответствие сначала изучается в Next.js с целью распространения на другие платформы (Nuxt, Angular и т. д.). ESLint и TypeScript уже используются во многих средах по-разному, но концепция целостной системы времени выполнения на уровне браузера активно исследуется.
Заключение
Соответствие кодифицирует лучшие практики в наборы правил, которые могут быть использованы разработчиками в виде простых шаблонов кода. Команда Aurora сосредоточила внимание на производительности загрузки, но другие передовые методы, такие как доступность и безопасность, также применимы.
Следование правилам соответствия должно привести к предсказуемым результатам, а достижение высокой планки пользовательского опыта может стать побочным эффектом расширения вашего технологического стека. Соответствие повышает продуктивность команд и обеспечивает высокий уровень качества приложения, даже если команды и кодовые базы со временем растут.