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