С момента последней ревизии главной страницы прошло 2 года, 3 месяца и 5 дней. По сравнению с последней редакцией общая структура и процесс разработки домашней страницы были радикальными (предыдущие две редакции резюмировали портал:издание 2016 г.,издание 2017 г.), на этот раз редизайн немного похож на погружение — без всплеска. В соответствии с предупреждением и ожиданием маленького гиганта, стоящего на плечах гигантов, эта версия основана на продолжении структуры и процесса 17-го издания и совершила прорыв в стабильности, безопасности, визуальном опыте и барьерах. бесплатный опыт домашней страницы Добавлены кирпичи и плитки.
В этой статье будут подробно рассмотрены следующие аспекты
- Внедрить строгую проверку типов
- Обновите схему строительства ресурсов
- Доступ к автоматизированному тестированию
- Улучшить систему мониторинга
- Оптимизируйте загрузку страницы: каркасный экран
- Оптимизация доступа к информации
Внедрить строгую проверку типов
Учитывая, что производительность почти безупречна, мы решили начать со стабильности и внедрить в проект строгую проверку типов, чтобы компенсировать непредсказуемость JavaScript, языка со слабой типизацией.
Строго типизированный язык TypeScript выпускается уже более 6 лет, и разработчиков отечественных приложений тоже потихоньку прибавляется. Вообще говоря цикл развития бизнеса короткий и итерации частые.Внедрение TypeScript это трудоемкая и трудоемкая задача для большого количества разработчиков.Если его использовать то бизнес может выйти в онлайн приложение в продакшене . Тем не менее, придерживаясь концепции отсутствия бросков и ударов, новая версия домашней страницы соответствует своей миссии и была перестроена на основе TS.
Сделать рефакторинг TS несложно, достаточно изменить суффикс js на ts. Заканчивать.
Конечно это шутка! Очевидно, что такая ТС бессмысленна. Только код, который строго следует стандарту TS, может максимизировать полезность TS. В проекте включаем строгий режим проверки ТС.Каждый раз при отправке будем делать полную проверку кода.Пока есть ошибка в ТС,подача запрещена.Цель донести сообщение членам——При написании строго типизированных языков надо быть осознанным, иначе будешь хулиганить.
Учащиеся, которые не использовали ТС в глубине, могут почувствовать жизненные трудности на ранней стадии, но онидля тебяЧтобы обеспечить надежность кода. Например, управление глобальными переменными окна, которые раньше было сложно найти и найти, было головной болью для разработчиков, после внедрения TS, пока настройки интерфейса для глобальных переменных сделаны, лишнего не будет. или неизвестные глобальные переменные в каждом компоненте переменная ситуация. Другой пример: при написанииget,setПри сохранении метода TS может помочь определить тип извлеченного контента:
interface MemoryState {
testa: boolean
testb: string
}
class Controller {
state: StateType
constructor() {
this.state = {
state: {},
}
}
get<K extends MemoryStateKeys>(key: K) {
return this.state.memory[key]
}
set<K extends MemoryStateKeys>(key: K, value: MemoryState[K]): MemoryState[K] {
this.state.memory[key] = value
return value
}
}
когда мы используемnew Controller().get("testb")Когда TS может обнаружить на этапе разработкиtestbтак или иначеstringтип. Благодаря подключаемому модулю обнаружения TS мы можем с уверенностью его использовать.stringМетод объекта типа упрощает сложную логику оценки и в то же время гарантирует, что код может быть найден через отчет об ошибке вовремя, когда получено неожиданное значение, все входные и выходные данные стабильны и предсказуемы, а округление автоматически проходить часть теста при написании кода, сопровождать разработку и итерацию проекта.
Обновите схему строительства ресурсов
Athena, инструмент сборки, используемый старым проектом домашней страницы, способствовал автоматизации процесса разработки, но когда дело доходит до настраиваемого процесса сборки, из-за универсальности Athena вносить изменения напрямую неудобно. Домашняя страница содержит три типа ссылок на ресурсы: прямой вывод, синхронный и асинхронный. Для упаковки ресурсов требуется специальная обработка. Поэтому на этот раз мы вернулись к Webpack и сделали следующие оптимизации на основе Webpack 4.0:
Оптимизация издательского процесса
В старой версии процесса выпуска каждый выпуск должен был выполнять проверку изменений измененных файлов, чтобы избежать непреднамеренных ошибочных изменений. Особенностью механизма упаковки Webpack по умолчанию является предоставление последовательно пронумерованного идентификатора для каждого модуля в соответствии с порядком упаковки модулей и управление зависимостями пакета файлов. Файл входа старой версии домашней страницы содержит среду выполнения, которая зависит от управления пакетами, поэтому при изменении последовательности импорта любого пакета файл входа изменится. В приведенном выше механизме упаковки изменение порядка введения файла может повлиять на изменение нескольких или даже дюжины файлов после компиляции, а часть логического кода этих файлов не нуждается в обновлении, что снижает точность. кода diff делает эту промежуточную проверку утраченной. Механизм кэширования домашней страницы и механизм ленивой загрузки ресурсов требуют очистки кэша CDN от измененных файлов при публикации статических ресурсов, а это означает, что чем больше файлов изменено, тем больше ссылок на кэшированные ресурсы необходимо очистить, а Чем он больше, тем выше вероятность асинхронной загрузки ресурсов, вызванной асинхронной очисткой кеша, и в каждом онлайн-релизе есть определенный риск.
Чтобы снизить риск выпуска, механизм упаковки новой версии домашней страницы изменил логику упаковки Webpack.При настройке каждый модуль больше не управляет зависимыми пакетами через идентификатор серийного номера, а генерирует закрытый хеш-кодированный ID через каталог файлов и помещает среду выполнения зависимого пакета из файла записи в виде отдельного запроса ресурсов, так что каждый раз, когда файл изменяется, можно сравнивать только измененный файл и другие непредвиденные ситуации сравнения. можно устранить. Благодаря новой схеме построения изменения кода контролируются в ожидаемом объеме, а стабильность процесса развертывания гарантируется.
Оптимизация архитектуры проекта
В схему оптимизации производительности старой версии страницы включены некоторые js-фрагменты, эти коды являются базовыми функциями, от которых зависит проект и которые необходимо запустить до выполнения основного js-кода. Однако есть у такой схемы и недостатки:
- Поскольку код должен быть непосредственно в шаблоне страницы, с учетом совместимости эти коды не могут использовать какой-либо расширенный синтаксис.Каждый раз, когда вы меняете свой код, вам необходимо убедиться, что ваш код несовместим, что приводит к высоким затратам на обслуживание. При этом шаблон домашней страницы управляется фоном, а изменения в прямом коде нужно выпускать в фоновом режиме, стоимость итерации несколько выше, да и риск не маленький;
- Из-за ограничений упаковки код ядра и код шаблона имеют одинаковый набор общего кода, не говоря уже об избыточности кода.Как только эта часть кода изменится, необходимо модифицировать и выпустить две части кода. в то же время, что увеличивает стоимость обслуживания кода.
В ответ на вышеуказанные проблемы в новой версии мы поместили эти коды обратно в основной код, код шаблона больше не несет никакого логического кода, итеративный выпуск больше не включает выпуск шаблона, можно использовать только выпуск статических ресурсов. единообразно в процессе разработки расширенный синтаксис JS, исключая процесс ручного обслуживания совместимого синтаксического кода.
На данный момент мы оптимизировали план выпуска ресурсов, повысив предсказуемость упаковки ресурсов и оптимизировав архитектуру ресурсов проекта.
Доступ к автоматизированному тестированию
После того, как страница разработана, самотестирование страницы является важным звеном перед ее тестированием. С одной стороны, убедитесь, что функции, разработанные на странице, могут нормально работать; с другой стороны, убедитесь, что разработка функции не влияет на нормальное использование функций в других областях страницы.
Как правило, самотестирование требует ручного тестирования, но есть два недостатка: во-первых, слишком велико количество проверяемых областей, а однотипные тестовые операции выполняются слишком часто, что приводит к лишнему трудозатрату и снижает эффективность теста. ; Во-вторых, поскольку единой спецификации самотестирования для рукотворного самотестирования не существует, в тесте легко допустить упущения, тем самым проигнорировав какие-то, казалось бы, мелкие, но на самом деле огромные баги, потратив уйму времени, но не получив нужного результата. самопроверка, измерение желаемого эффекта. В ответ на эту ситуацию у нас возникла идея реализовать автоматизированное тестирование. Взяв в качестве примера новую версию главной страницы, с помощью Nightwatch.js мы создали скрипт автоматического тестирования для новой версии главной страницы, чтобы выполнить автоматические тесты для 73 вариантов использования новой версии главной страницы.
Результаты показывают, что благодаря автоматизированному тестированию 73 варианта использования новой версии домашней страницы были завершены менее чем за три минуты, время можно контролировать в течение пяти минут, а точность выше. Применяйте автоматизированные тесты перед релизом и в течение 5 минут после запуска, а также вовремя проверяйте тест-кейсы, чтобы обеспечить безопасность каждого релиза.
Улучшить систему мониторинга
Интерфейсная система мониторинга старой версии страницы охватывает информацию о браузере, измерение скорости загрузки страницы и скрытие пола, но информационное уведомление отстает и охватывает только время загрузки страницы. невозможность быстро локализовать проблему.
Ссылаясь на текущий механизм мониторинга апплета покупок Jingdong, в новой версии домашней страницы добавлен мониторинг отчетов для отчетов об ошибках кода и доступности интерфейса.
Мониторинг ошибок кода: BadJS
Захватите ошибки страницы с помощью платформы BadJS, проанализируйте и обработайте информацию об ошибках и сообщите об этом в службу JD BadJS. Сообщая данные, мы можем получить подробную информацию об ошибке и количестве ее возникновения. Анализируя представленные данные, вы можете найти некоторые потенциальные проблемы и вовремя исправить их, чтобы обеспечить надежность кода домашней страницы. При этом по количеству отчетов также можно оценить масштаб влияния проблемы, что удобно для оценки убытков.
Мониторинг доступности бизнеса
В этой версии домашняя страница была дополнена конкретными правилами суждения в системе отчетности о доступности, включая три измерения: количество вызовов, доступность и TP (индекс производительности).Чтобы уменьшить вероятность ложных срабатываний, система недавно запустил функцию голосового оповещения о красном свете.
Система отчетов о доступности обычно используется для контроля доступности интерфейса, но для домашней страницы, помимо интерфейса, также необходимо обращать внимание на скрытое положение этажа. В текущем решении для резервного копирования, если все интерфейсы модуля на каждом этаже недействительны, текущий этаж будет скрыт. Раз пол скрыт, значит, есть серьезная проблема, на которую нужно быстро обратить внимание и решить. Система отчетов о доступности может отправить уведомление в течение 1 минуты при срабатывании правила тревоги, что точно соответствует интерфейсу, что удобно для своевременного обнаружения проблем и своевременной остановки убытков. Следует отметить, что особенно важно установить набор порогов, которые могут более точно отражать возникновение проблем и уменьшать количество ложных срабатываний, ведь когда приходят волки и слишком много кричат, это означает, что мониторинга нет.
Отчет о скорости
Эта часть продолжает старую версию решения для отчетов об измерении скорости Athena и вычитает некоторые части, которые повторяются с отчетами о бизнес-данных.В то же время добавлен отчет об измерении скорости интерфейса для улучшения системы данных отслеживания неисправностей.
Оптимизируйте загрузку страницы: каркасный экран
Старая схема заполнения страницы с отложенной загрузкой использует метод анимации загрузки унифицированной области, который имеет преимущества низкой стоимости повторного использования и высокой адаптивности. Однако, если вы столкнетесь с большой площадью модулей или когда модули будут более плотными, опыт региональной анимации загрузки будет уменьшаться - либо пустая область слишком велика, либо анимация загрузки слишком плотная, а вызванные визуальные эффекты по процессу загрузки модуля Разница в восприятии более очевидна. Для домашней страницы ПК большая пустая область является основной проблемой.
В этой версии мы представили схему каркасного экрана, конечной целью которой является минимизация визуальной разницы между реальной структурой модуля и заполнителем загрузки в виде серых блоков тофу. Исполнение можно разделить на два соответствия по визуальному различию:
- Слабое соответствие: блокировать только основное содержимое модуля, такое как заголовок и подэлементы, с высокой возможностью повторного использования и умеренной адаптивностью;
- Сильное соответствие: на основе визуального эффекта подэлементы далее обрабатываются в блоки изображений и копирайта, а подэлементы с большей площадью и более сложным содержанием делятся на более подробные блоки, а повторное использование Низкий, высокая адаптивность.
Принимая во внимание особенности домашней страницы, мы, наконец, выбрали решение каркасного экрана с сильным соответствием, а для масштабируемости мы использовали каркасный экран, визуализируемый со стилями, а не напрямую используя пространство изображения. В дополнение к увеличению затрат на разработку также увеличился объем кода, загружаемого в верхней части страницы.
Структура проекта
Эффект, который должен быть достигнут при использовании каркасного экрана, включает в себя следующие моменты:
- Займите место заранее, и полоса прокрутки не будет более явно прыгать во время загрузки страницы;
- Заполнитель в стиле каркасного экрана также можно увидеть при быстрой прокрутке страницы.
Это означает, что содержимое каркасного экрана должно загружаться синхронно со страницей.В сочетании с компонентом ленивой загрузки, каркасный экранный компонент необходимо передать в качестве структуры загрузки заранее и убедиться, что стиль загружается в момент загрузки. первый раз рендеринга страницы, иначе скелет будет потерян.значение экрана.
Для каждого компонента, которому требуется скелетный стиль экрана, отдельно выделяется компонент-заполнитель. Структура заполнителя внутри компонента содержит два типа стилей — позиционирование цвета и размера, а также стиль эффекта анимации внешнего слоя контейнера. Цветовой стиль общий для всей страницы, а стиль позиционирования размера общий для формальных компонентов:
Целью совместного использования стиля позиционирования размера с формальными компонентами является обеспечение унифицированной модификации каркасного экрана и формального стиля при изменении стиля компонентов в будущем, избегая упущений в модификации стиля, но в то же время увеличивая стоимость обслуживания стиля. В то же время в процессе написания и разделения стиля разработчикам также необходимо обратить внимание на стиль, совместимый с экраном скелета.Например, выбор отступов и полей контейнера, который должен занимать блок тофу, очень важный. Поэтому попытка скелетного экрана на домашней странице не подходит для быстрого повторного использования в других проектах.
Оптимизация доступа к информации
Интернет-доступность, то есть помощь слабовидящим. Помощь на системном уровне в основном опирается на инструменты чтения с экрана.Инструменты чтения с экрана могут решить 60% препятствий для доступа к информации на веб-странице, а оставшиеся 40% должны быть оптимизированы разработчиками в процессе работы с веб-страницей. разработка.
Веб-страницы без какой-либо обработки доступности информации обычно имеют следующие проблемы при использовании средств чтения с экрана для доступа к ним:
- Трансляция избыточной и бесполезной информации, такой как: ссылка перехода, название картинки;
- Доступ к всплывающему слою недоступен;
- Ленивая загрузка контента пропускается напрямую;
Чтобы помочь одному слабовидящему человеку из 110 человек в Китае (данныездесь), в этой версии мы решили начать первую практику доступности информации на настольной стороне Jingdong Mall на домашней странице ПК.
Операции слабовидящих пользователей на рабочем столе в основном выполняются с помощью клавиатуры. В ответ на только что заданные вопросы предварительный план оптимизации безбарьерного взаимодействия с домашней страницей для ПК разделен на несколько этапов.
Первый этап, семантически все элементы, доступные с помощью вкладок, включая ссылки для перехода за пределы страницы.aДобавляйте метки равномерноaria-labelатрибут, чтобы программное обеспечение для чтения с экрана могло упростить чтение информации об элементах;
На втором этапе обеспечьте доступ к основным модулям страницы — контейнер-плейсхолдер для ленивой загрузки будетtab-indexУстановите значение больше 0, чтобы можно было пройти по клавише табуляции, чтобы вызвать ленивую загрузку страницы и избежать прямого пропуска табуляции;
На третьем этапе расширьте работу с такими элементами, как всплывающие плавающие слои — увеличьте интерактивную логику всплывающих плавающих слоев для доступности и увеличьте входaria-haspopupатрибут, сообщите программе чтения с экрана, что это вход во всплывающий слой, иtab-indexУстановите значение больше 0, чтобы можно было сфокусировать операцию вкладки, и фокус автоматически сфокусируется на плавающем слое после того, как плавающий слой всплывет;
На четвертом этапе добавляются дополнительные быстрые переходы для слабовидящих пользователей — см. страницу результатов поиска Google, а вверху страницы могут быть добавлены некоторые скрытые быстрые переходы. На этот раз в поле поиска и в позицию «Рекомендуется для вас» в нижней части домашней страницы ПК были добавлены скрытые ссылки для перехода, которые могут найти только пользователи, использующие операции с клавиатурой.
Для страницы торгового центра первый этап может соответствовать базовому доступу к контенту, и если может быть достигнут четвертый этап, его можно рассматривать как полный информационный безбарьерный веб-сайт. В бизнесе торговых центров опыту доступности всегда не хватало соответствующих спецификаций и процедур тестирования, поэтому в результате пересмотра домашней страницы ПК была выпущена спецификация разработки доступности информации для страницы канала торгового центра, в том числе:
- Спецификация проекта пути доступа
- Семантическая спецификация
- Спецификация теста чтения с экрана
В будущем эта спецификация будет использоваться для постепенной реализации оптимизации безбарьерного опыта других предприятий торгового центра.
Подводя итог, можно сказать, что самое большое изменение для разработчиков в этой версии заключается в том, что локальная разработка стала более удобной, риск релиза снижен, а отслеживание ошибок стало более полным. слабовидящие пользователи Наконец-то об опыте позаботились. Как вход и фасад настольной части торгового центра, улучшение домашней страницы должно быть чем-то большим.Я надеюсь, что каждую ревизию можно немного оптимизировать, делая проект домашней страницы ближе к совершенству.