Внешняя архитектура: Часть 1 - Файловая структура
Более быстрое прототипирование, более стабильная кодовая база и более легкий рефакторинг.
В течение многих лет, как разработчики интерфейса, мы структурировали наши файлы, разделяя три столпа Интернета: HTML, CSS, Javascript. Такое разделение проблем было отличным, поскольку позволило нам расположить наши страницы снизу вверх.
Этот стиль хорошо подходит для сайтов, ориентированных на контент, таких как блоги и документы (истоки в сети). Однако по мере того, как веб-сайты стали более интерактивными и программными, мышление изменилось.
Следуя принципам чего-то вроде атомарного дизайна, вы можете рассматривать элементы пользовательского интерфейса вашего сайта как серию отдельных компонентов, связанных вместе в виде снимка (страницы).
Каждый компонент должен заботиться только о себе, отображении переданных ему данных и отправке соответствующих действий при взаимодействии с ним.
Разделить по компонентам
Исходя из нашего первого замечательного сайта, мы могли бы решить разделить HTML, CSS и Javascript на отдельные файлы, чтобы помочь управлять компонентами нашего сайта. Мы можем использовать такие инструменты, как SCSS, Twig и Browserify для компиляции файлов в полностью рабочий сайт.
Это даже лучшее разделение, чем было раньше. У каждого компонента есть собственный файл для HTML, CSS и Javascript, что позволяет нам сосредоточиться на небольшом фрагменте кода, который нужно усовершенствовать. Меньший фокус означает, что большая часть вычислительной мощности вашего мозга может быть направлена на то, чтобы сделать этот фрагмент кода твердым, как камень.
Проблема, с которой мы сталкиваемся с этой настройкой, заключается в том, что, хотя мы и разделили наши файлы на компоненты, мы все же разбили их на соответствующие языки. Это приводит к двойному разделению ментальной модели, и поиск всего кода, относящегося к компоненту, может быть трудным в большом проекте.
Сгруппированы по компонентам
Следующий этап - перегруппировать наши файлы чисто по компонентам.
У нас все еще есть несколько базовых файлов SCSS и Javascript в их собственных папках, но большая часть кода пользовательского интерфейса теперь сгруппирована по компонентам. Это означает, что каждый компонент полностью сосредоточен на себе и может быть отредактирован или удален без особого внимания к остальной части пользовательского интерфейса.
Работа с бэкенд-командой
В традиционном водопадном потоке разработки команда внешнего интерфейса может создать полные шаблоны и передать их команде серверной части для интеграции. И наоборот, бэкэнд-команда может нарастить функциональность и передать фронтэнду-команде для стилизации.
Схема управляемая
Чтобы позволить нам запускать оба потока разработки параллельно, мы переходим к разработке, управляемой схемой.
Схема JSON - это способ определения ожидаемых данных для компонента. В приведенном выше мы требуем, чтобы заголовок и свойство содержимого передавались компоненту в виде строк.
Определяя эту схему перед началом сборки, как клиентская, так и серверная команды могут работать над достижением цели либо предоставления данных, либо работы с отображением данных, не беспокоясь о состоянии работы друг друга. .
Это значительно ускоряет наш процесс сборки, чтобы быстрее делать лучшее программное обеспечение.
Прототипирование с фиктивными данными
Сосредоточившись на пользовательском интерфейсе, нам понадобится способ тестирования различных вариантов данных, чтобы убедиться, что наш компонент обрабатывает их правильно.
Мы добавляем папку с именем варианты в папку компонентов. Это может хранить несколько файлов JSON, содержащих разные состояния / варианты для отображения компонентов.
Их можно передать компоненту в нашей библиотеке стилей / компонентов, чтобы мы могли видеть его поведение вживую. Важно отметить, что это также дает нам хороший массив данных для тестирования.
Тестирование: функциональное и визуальное
Теперь у нас есть автономный компонент с множеством фиктивных данных, у нас есть компонент, который можно протестировать в изолированной среде.
Это важная разработка, поскольку она открывает возможность тестирования нашего пользовательского интерфейса независимо от остального состояния нашего приложения.
Нам понадобится маршрут в руководстве по стилю / библиотеке компонентов, где варианты можно будет просматривать по отдельности, а затем мы сможем запускать в них функциональные и визуальные тесты.
Функциональное тестирование компонентов добавляет еще один уровень стабильности вашему веб-сайту / приложению.
Для визуального тестирования мы можем использовать что-то вроде Wraith или BackstopJS, чтобы проверить, не изменился ли внешний вид наших компонентов с момента подписания.
Это также дает нам библиотеку эталонных изображений для каждого компонента, которые можно использовать без запуска приложения.
Документация
Наконец, нам может понадобиться документация для нашего компонента. Следует включить краткое описание ожидаемого использования и функциональности, а также некоторых типичных вариантов использования.
Компонент ориентирован
Как видите, мы прошли долгий путь с момента простого разделения на HTML, CSS и Javascript, но Интернет тоже прошел долгий путь. Хотя это может показаться большой начальной работой, это дает нам гораздо более стабильную и гибкую систему для дальнейшей работы.
Создание прототипа становится проще простого, поскольку мы можем быстро объединить различные компоненты на странице и знать, что они будут работать.
Рефакторинг безопасен и стабилен, поскольку у нас есть единый источник достоверной информации о поведении и отображении компонента. Мы также знаем всю потенциальную структуру данных из нашей схемы.
Развертывания вызывают меньше нервов, потому что мы можем быть уверены, что наш пользовательский интерфейс надежен, протестирован и работает должным образом.
Вступая в эту серию, мы более подробно рассмотрим каждую область нашей папки компонентов, от CSS до Javascript, до тестирования и всего, что между ними.
Сделать программное обеспечение лучше.
Прочтите еще несколько мыслей о нашем интерфейсе ниже:
Etch специализируется на веб-программном обеспечении - создании систем дизайна, библиотек компонентов и прогрессивных веб-приложений.
Мы работаем вместе с внутренними командами разработчиков или занимаемся полной сборкой продукта от начала до конца.
Свяжитесь с нами [email protected]
