Это вторая часть серии статей Переосмысление интерфейса. В этой части мы рассмотрим конкретный пример разработки относительно большого реального приложения.
Одна из проблем работы разработчика - переход от младшего к старшему. Это означает выходить за рамки реализации и начинать думать о дизайне и архитектуре.
Дизайн включает в себя два навыка: 1. создание / обнаружение / рассмотрение целей и проблем, 2. построение подходов / решений.
В этой статье мы рассмотрим некоторые из этих основных соображений.
Учитывайте все заинтересованные стороны
Прежде чем написать хоть одну строчку кода, важно подумать о своем продукте с разных точек зрения, чтобы создать правильные концепции и абстракции.
Хороший код - это гораздо больше, чем просто работающий код. Качество кодовой базы настолько хорошо, насколько она служит людям, которых она касается. Как правило, существует три основных заинтересованных лица для большинства продуктов: конечные пользователи, специалисты по разработке продукта и разработчики. Это те места, где вы можете достичь большинства своих целей.
Конечные пользователи и конечный продукт
Для принятия правильных решений о вашей интерфейсной системе необходимо глубокое понимание конечного пользователя и продукта. Дизайн для конечного пользователя обычно создается комбинацией дизайнеров UX, графического дизайна и управления продуктом (включая маркетинг). Хотя основные решения по дизайну могут принимать другие люди, понимание конечного продукта поможет вам выяснить требования к проекту и принять решения о проектировании сущностей / структур данных.
Пример:
В течение последнего месяца моя компания (Journy) работала над инструментом для создания гибких викторин. Наш основной продукт - это разработка и создание индивидуальных маршрутов для путешественников, которые хотят испытать подлинные впечатления без трудностей и стресса, связанных с исследованием и бронированием каждого аспекта поездки. В качестве первого шага мы предлагаем клиентам заполнить анкету, чтобы помочь нашим дизайнерам спланировать идеальное путешествие. Это значит спрашивать об интересах, датах поездки, ценах, причине поездки и т. Д.
Откройте для себя важные требования
Конечные пользователи и продукт помогают понять необходимые функции. Понимание продукта в целом значительно упрощает проектирование вашей архитектуры. Поскольку вы проходите через этот процесс, попробуйте подумать о том, как бы вы реализовали каждую часть, и подумайте о любых трудностях и проблемах. Например, одной из важных функций нашего приложения была условная визуализация: изменение того, что отображается, в зависимости от реакции пользователя.
Эта функция показывала контент на основе ответов пользователя. Если бы мы не подумали об этом заранее, одной из распространенных ошибок в интерфейсе могло бы стать встраивание ответов на вопросы в сам компонент.
Например, компонент ButtonSelect сохранит ответ в своем собственном локальном состоянии. В React вы должны использовать useState или setState, или в Vue вы должны использовать свойство data.
Если бы это было так, как бы вы справились с условным рендерингом? Чтение данных из родственных компонентов всегда неудобно. Как бы вы извлекли все ответы на викторину, когда пользователь отправил их? Что делать, если несколько блоков должны устанавливать / совместно использовать одни и те же данные?
Извлечь сущности
Очень важно согласовать ваши программные объекты с тем, как клиенты думают о вашем продукте. Согласованные сущности упрощают проектирование и рассуждение о функциях для всех вовлеченных сторон.
Размышляя на этом уровне, вы можете рассуждать о том, как все должно быть организовано. В викторинах есть разделы, в разделах есть шаги, шаги - блоки содержимого и т. Д.
Как вы можете видеть выше, есть определенные блоки, которые можно адаптировать к любой ситуации, в то время как дополнительные настраиваемые функции, вероятно, должны быть настраиваемыми блоками (не гибкими). Предварительное понимание этих типов требований помогло разработать данные и компоненты.
В большинстве случаев решение о структуре данных, API и конечных точках является задачей серверной группы. Это скорее отстает, поскольку конечным потребителем данных является команда внешнего интерфейса. Преобразование данных на стороне клиента имеет множество проблем (больший размер пакета, более медленное время выполнения, возможные несоответствия между веб-платформами и мобильными платформами и т. Д.). Хорошо организованная команда будет вести диалог между этими двумя подразделениями. Команда внешнего интерфейса будет описывать тип данных, которые сделают написание кода наиболее удобным, в то время как команда внутреннего интерфейса отодвигает любые проблемы или трудности с реализацией.
Специалисты по продуктам
Чтобы улучшить продукт, код также должен быть гибким и адаптируемым. Специалисты по продуктам всегда анализируют и разрабатывают новые функции, создают новый контент и придумывают новые способы нацеливания и общения с клиентами. Если ваша архитектура не будет гибкой там, где она должна быть, инженерия будет огромным узким местом.
Перед тем, как начать этот проект, у нас была проблема с нашей старой викториной. Наша анкета была построена с фиксированным потоком: предварительно определенные страницы / просмотры с фиксированным поведением. Это сделало A / B-тестирование сложным и немасштабируемым, потому что требовалось инженерное решение для внесения мелких правок в каждый тест. Нам был нужен инструмент, который позволил бы нашим UX и нетехническим специалистам легко создавать и вносить изменения.
Внесение изменения в одну копию, добавление нового условного сообщения или добавление одного настраиваемого события отслеживания без построителя будет стоить от 30 минут до часа на каждое изменение. Почему так долго? Большинство этих изменений потребуют короткой встречи, чтобы описать изменение инженеру, инженер должен найти правильный файл, внести небольшое изменение, а затем создать запрос на вытягивание. Затем есть контроль качества, проверка кода, тестирование кода и развертывание.
Приложение-конструктор изменяет это время обработки примерно на одну минуту. Поговорите с людьми, чтобы выяснить, какие инструменты окажут наибольшее влияние!
Думая о гибкости
Внутренний инструмент CMS не всегда может быть правильным решением вашей проблемы. Гибкость означает, что ваш код легко изменить и дополнить. Это означает хорошее разделение проблем (вы можете вносить изменения, не беспокоясь о том, что это повлияет на другие вещи) и добавление параметров / переключателей, которые вы можете щелкнуть, чтобы внести изменения. Стратегии гибкости будут рассмотрены в следующей статье.
Разработчики
Распространенной статистикой является то, что разработчики тратят примерно в 9 раз больше времени на чтение кода, чем на его написание. Для того, чтобы у разработчиков был хороший опыт, очень важно качество связи внутри вашего приложения.
Никто не хочет тратить время на прыжки из файла в файл, пытаясь выяснить, что его волнует. Это означает, что хорошая организация имеет первостепенное значение. Хорошая организация требует некоторого предвидения. Это означает, что неделю или две уходит на создание хорошей архитектуры, а затем на создание короткого документа из 400–1000 слов, который поможет донести архитектуру до команды. Эти усилия с самого начала сэкономят вам и вашей команде месяцы времени на внедрение.
Хорошая организация кода?
Вы когда-нибудь работали над проектом, в котором все файлы упорядочены по «типу»? Представления помещаются в одну папку, компоненты - в другую, действия - в другую. Звучит нормально, правда? Работаете над приложением Ruby on Rails? Работаете в приложении React? Обратите внимание, как все приложения выглядят более или менее одинаково, даже если они делают совершенно разные вещи. В чем проблема?
Организация кода по типу похожа на написание учебника и систематизацию всех знаний, как в словаре или глоссарии. Люди читают вашу книгу и разбираются в файлах по отдельности, но они теряются, если пытаются увидеть, что делает ваша программа в целом.
Что имеет больше смысла, так это организовывать вещи на основе целей / проблем. Цели определяют, что мы должны хранить в рабочей памяти и что делает код. Это поможет вам найти конкретный код, который вы ищете, не отвлекаясь от переключения контекста.
Не бойтесь нестандартной файловой структуры
Корневой каталог нашего приложения был следующим:
Удобство разработчика / Папки для конкретных платформ
- Assets - папка для изображений, шрифтов и т. Д.
- Блоки - универсальные повторно используемые компоненты
- Композиции - Компоненты для конкретных приложений
- Импорт библиотек - скрипты инициализации для разных библиотек
- Стили - базовые таблицы стилей, включающие все переменные, функции и миксины.
Папки на основе функций
- Builder App - приложение для построения викторин
- Viewer App - приложение для просмотра викторины.
- Блоки шагов - компоненты, используемые для построения шагов в викторине.
Вы можете думать о каждом уровне папки как об одном уровне, вызывающем беспокойство. При этом каждая папка помогает раскрыть один уровень программы. На верхнем уровне вас больше интересует, как части сочетаются друг с другом. По мере того, как вы углубляетесь в файловую структуру, вы все больше и больше заботитесь о реализации.
Идея здесь в том, что ваша структура папок помогает понять, как работает ваша программа.
Если все сделано правильно, читатель сможет понять, как ваша программа сочетается друг с другом. Им не нужно искать в каталоге файлов файлы, относящиеся к этому уровню абстракции (все они находятся в папке). Это также означает, что очень ясно, где должны располагаться новые файлы и папки относительно этого слоя, что упрощает работу с ними. Это также естественное место для README!
Второстепенное преимущество состоит в том, что он, естественно, обеспечивает более «подключаемую» / модульную архитектуру. Этот сегмент кода больше не нужен? Вы можете просто удалить папку и соответствующий импорт. Не нужно рыться в поисках других файлов, которые могут оказаться мертвым грузом.
Заключение
Это краткий обзор некоторых общих соображений, необходимых для разработки хорошего внешнего интерфейса. Мы рассмотрели, как ставить цели дизайна и некоторые большие проблемы, которые вам нужно будет решить.
- Учитывайте все заинтересованные стороны
- Откройте для себя сущности
- Общайтесь со своим сервером, чтобы описать нужные данные
- Определить требования
- Подумайте о реализации и потенциальных проблемах
- Решите, что должно быть гибким
- Подумайте о файловой структуре и документации
Чего не хватает?
- Разделение проблем
- Компонентный состав
- Преобразование целей и задач в архитектуру
- Инструменты и стратегии тестирования
- Планирование и выполнение рефакторинга
Следующая глава будет посвящена выбору правильного разделения / группировки проблем!
Спасибо за прочтение! Пожалуйста, оставьте любые вопросы и отзывы или темы, которые вы хотите затронуть!
