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

То, что должно было составлять «архитектуру пользовательского интерфейса» (архитектуру ПИ), как правило, являлось процессом “ad hoc” структурирования, определяемым требованиями момента, часто без достаточного рассмотрения будущих последствий. Достаточно сказать, независимо от того, насколько большой пользовательский опыт или насколько хорош дизайн, все равно все оставалось безолаберным под внешним лоском.

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

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

Лучшие практики, связанные с архитектурой ПИ, в последнее время приобретают все большую значимость, вероятно, отчасти из-за того, что все более сложный механизм интерфейса и возникающие в результате рабочие процессы требуют более структурированного подхода к разработке интерфейса. Мика Годболт, автор книги «Архитектура Пользовательского Интерфейса: Современный План для Масштабируемых и Устойчивых Веб-сайтов» определяет архитектуру ПИ как: «Набор инструментов и процессов, которые направлены на улучшение качества нашего интерфейсного кода при создании более эффективных и устойчивых рабочих процессов» Это определение, достаточное по масштабу, но достаточно конкретное, чтобы сформировать понятие, которое послужит для серьезного восприятия архитектуры ПИ сообществом разработчиков.

В течение многих лет мы имели доступ к скаффолдингам, которые обеспечивают набор общих компонентов ПИ и библиотеки классов стиля, каждый из которых имеет свои собственные соглашения о том, как управлять уровнем представления. Однако его главной задачей был стиль, а не структура. Хотя это ограничение по объему вызвано целым рядом причин, и существует также место для такого типа фреймворка, который выходит за рамки стиля, обеспечивая гибкую платформу для создания вашего ПИ.

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

1. Описать свою архитектуру с семантическим структурным словарем
2. Обеспечить структурную целостность с правилами управления эссетами
3. Выдать шаблоны, которые допускают прогнозированное масштабирование

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

• Поддержку рабочего процесса проекта с интегрированным источника эссетов
• Небольшое количество шаблонов
• Коллекция утилит-классов
• Библиотека компонентов

Я помню как в 2013 году я начал собирать сниппеты разметки, стиля и скриптов с целью улучшения повторного использования регулярных шаблонов - процесса, который, я уверен, касается многих из вас. Это было примерно в то же время, когда я преобразовывал CSS препроцессор, и мне пришлось выбрать что то особенное. Мне понравились особенность Стайлус и синтаксическая гибкость, и я сделал выбор. В то время не было никаких фреймворков, которые использовали Стайлус, поэтому использование этого направления означало жертвовать способными, хорошо проверенными вариантами, такими как Twitter’s Bootstrap и Zurb’s Foundation.

Ну, на этом этапе вы либо модифицируете существующее решение, либо остаетесь при своем решении. Я выбрал второй вариант. В начале 2014 года, используя постоянно растущую коллекцию сниппетов, я решил создать скаффолдинг, проведя все движущиеся части до базового, но функционального многостраничного шаблона. Сначала он запускался на HTML 5, Стайлус и на логике pre-ES6, и был протестирован в производстве по четырем отдельным проектам малого и среднего размера.

Он сработал, но он не имел определенной структуры, был монолитным, а не модульным, не способствовал повторному использованию компонентов и не имел интегрированного источника эссетов. Со временем я внедрил свой опыт в этот проект, неуклонно воплощая свои идеи в дело развития ПИ.

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

Я решил, что я назову его «Платфрейм»-ом, поскольку он будет по существу структурированной платформой, которая послужит основой для этой структуры. Я заменил HTML с Pug и принял ES2015, поскольку он стал стабильным. Этот стек позволил мне достичь модульности структурного, представительного, а также функционального слоя. Грант отвечает за источники ессетов, а вся энчилада собрана со скромной попыткой более явного структурного проектирования.

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

• Структурирован с определенной архитектурой
• Может легко взаимодействовать с рекурсивными шаблонами для управления эссетами
• Оптимизирован рабочий процесс с источником эссетов
• Определяет повтор (DRY-aware) с помощью взаимозаменяемых компонентов
• Оснащен системой цветов, которая поддерживает совместно используемые пакеты схем
• Загружен основным шаблонным стилем и стартовым шаблоном
• Предполагает минимальную методологию разработки

Я не собираюсь расширять приведенный выше список ради краткости и сделаю ссылку на документацию проекта содержащую подробную информацию.

Для реализации вышеуказанного набора функций в одном интегрированном пакете потребовалось немало усилий, но я, наконец, закончил финальные штрихи в феврале 2018 года. С тех пор я выпустил программное обеспечение с открытым исходным кодом с лицензией MIT (Массачусетским технологическим институтом).

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

• Разделение и кодификация архитектуры. Основополагающая архитектура должна быть четко отделена от конкретных технологий. Она лучше послужит как формализованное общее руководство, которое может быть принято любым стеком, удовлетворяющим требуемому набору функций для реализации.
• Большой выбор компонентов. В настоящее время существует только несколько компонентов для иллюстрирования концепции многоразовых пакетов в фреймворке.
• Больше цветовых схем. Эта система поставляется с тремя стандартными схемами. Схемы легко подключаются к вашему проекту и могут каскадироваться до самых тонких деталей вашего ПИ, включая активные компоненты.
• Расширенный выбор утилиты. Текущий выбор ограничен и несколько устаревший. Он нуждается в обновлении и расширении, чтобы включить больше разнообразия элементов взаимодействия.
• Построение системы более низкого уровня для сокращения общих зависимостей.
• Родной менеджер пакетов для компонентов (хотя и низкий на сортировке).

Я продолжу работу над списком, так как у меня есть время, но любая помощь будет очень ценной. Вы можете проверить проект на GitHub для дополнительной информации.