Как мы создали наше первое полнофункциональное веб-приложение на JavaScript за три недели
Простое пошаговое руководство от идеи до развернутого приложения
Мой трехмесячный учебный курс по программированию в программе Grace Hopper подошел к концу, и название этой статьи на самом деле не совсем соответствует действительности - я создал три полнофункциональных приложения: an e -коммерческий магазин с нуля , персональный проект хакатона на мой выбор и, наконец, трехнедельный проект, посвященный завершению проекта. Этот завершающий проект был, безусловно, самым интенсивным - трехнедельное путешествие с двумя товарищами по команде - и это мое самое большое достижение на буткемпе. Это первое надежное и сложное приложение, которое я когда-либо полностью создал и спроектировал.
Как известно большинству разработчиков, даже когда вы «умеете кодировать», может быть действительно сложно приступить к созданию своего первого полнофункционального приложения. Экосистема JavaScript невероятно обширна: с менеджерами пакетов , модули, инструменты сборки, транспиляторы, базы данных, библиотеки и решения, которые нужно принять по всем из них, неудивительно, что так много начинающих программистов никогда не создают ничего, кроме руководств по Codecademy. Вот почему я хочу провести вас через пошаговое руководство по решениям и шагам, которые моя команда предприняла для создания нашего живого приложения Align.
Во-первых, немного контекста. Align - это веб-приложение, которое использует интуитивно понятный интерфейс временной шкалы, чтобы помочь пользователям ставить долгосрочные цели и управлять ими с течением времени. Наш стек включает Firebase для серверных служб и React для внешнего интерфейса. Я и мои товарищи по команде объясняем больше в этом коротком видео:
Так как же мы перешли от первого дня, когда нас распределили по командам, до финального живого приложения? Вот краткое изложение предпринятых нами шагов:
Шаг 1. Придумайте
Первым шагом было выяснить, что именно мы хотим построить. В моей прошлой жизни в качестве консультанта в IBM я проводил семинары по формированию идей с руководителями компаний. Исходя из этого, я предложил своей группе классическую стратегию пост-мозгового штурма, в которой мы все набрасываем столько идей, сколько можем - даже «глупых», - чтобы мозги людей продолжали двигаться и никто не избегает высказывать идеи из страха.
Сгенерировав несколько десятков идей для приложений, мы отсортировали их по категориям, чтобы лучше понять, какие темы нас интересовали вместе. В нашей группе мы увидели четкую тенденцию к идеям, касающимся самосовершенствования, постановки целей, ностальгии и личного развития. Исходя из этого, мы в конечном итоге отточили конкретную идею: персональную панель инструментов для постановки и управления долгосрочными целями с элементами сохранения памяти и визуализации данных с течением времени.
На основе этого мы создали набор пользовательских историй - описаний функций, которые мы хотели иметь с точки зрения конечного пользователя, чтобы прояснить, что именно мы хотели от нашего приложения.
Шаг 2: каркасный UX / UI
Затем на белой доске мы нарисовали основные представления, которые мы предусмотрели в нашем приложении. Мы включили наш набор пользовательских историй, чтобы понять, как эти представления будут работать в каркасе приложения.
Эти наброски гарантировали, что мы все на одной странице, и предоставили визуальный план того, над чем именно мы все работали.
Шаг 3. Выберите структуру данных и тип базы данных.
Пришло время разработать нашу структуру данных. Основываясь на наших каркасах и пользовательских историях, мы создали в документе Google список моделей, которые нам понадобятся, и какие атрибуты должны включать в себя. Мы знали, что нам нужна модель «цели», модель «пользователя», модель «вех» и модель «проверки», а также, в конечном итоге, модель «ресурсов» и модель «загрузки».
После неформального наброска моделей нам нужно было выбрать тип базы данных: «реляционный» или «нереляционный» (также известный как «SQL» или «NoSQL»). В то время как базы данных SQL основаны на таблицах и требуют предопределенной схемы, базы данных NoSQL основаны на документах и имеют динамическую схему для неструктурированных данных.
Для нашего случая использования не имело большого значения, используем ли мы базу данных SQL или базу данных без SQL, поэтому в конечном итоге мы выбрали облачную базу данных NoSQL от Google Firebase по другим причинам:
- Он может хранить загруженные изображения пользователей в своем облачном хранилище.
- Он включает интеграцию с WebSocket для обновления в реальном времени.
- Он может обрабатывать нашу аутентификацию пользователей и предлагать простую интеграцию OAuth.
После того, как мы выбрали базу данных, пришло время понять отношения между нашими моделями данных. Поскольку Firebase - это NoSQL, мы не могли создавать таблицы соединения или устанавливать формальные отношения, такие как «Проверки принадлежат целям». Вместо этого нам нужно было выяснить, как будет выглядеть дерево JSON и как объекты будут вложены (или нет). В конечном итоге мы структурировали нашу модель следующим образом:
(Примечание: Firebase предпочитает неглубокие нормализованные структуры данных для повышения эффективности, но для нашего варианта использования имеет смысл вложить их, поскольку мы никогда бы не извлекли цель из базы данных без ее дочерних этапов и отметок.)
Шаг 4. Настройте Github и гибкий рабочий процесс
Мы с самого начала знали, что организованность и практика гибкой разработки сослужат нам хорошую службу. Мы создали репозиторий Github, на котором мы не допустили слияния с мастером, чтобы заставить себя проверять код друг друга.
Мы также создали гибкую доску на Waffle.io, которая бесплатна и легко интегрируется с Github. На доске Waffle мы перечислили наши пользовательские истории, а также ошибки, которые, как мы знали, необходимо исправить. Позже, когда мы начали кодировать, каждая из нас создавала ветки git для пользовательской истории, над которой мы в настоящее время работаем, перемещая ее с плавательной полосы на плавательную по мере продвижения.
Мы также начали каждое утро проводить «стоячие» встречи, чтобы обсудить прогресс за предыдущий день и любые препятствия, с которыми каждый из нас сталкивался. Эта встреча часто определяла ход дня - кто будет заниматься парным программированием, а кто будет работать над проблемой в одиночку.
Я настоятельно рекомендую какой-то подобный структурированный рабочий процесс, поскольку он позволил нам четко определить наши приоритеты и добиться эффективного прогресса без каких-либо межличностных конфликтов.
Шаг 5. Выберите и загрузите шаблон
Поскольку экосистема JavaScript настолько сложна, мы решили не строить наше приложение с нуля. Не было необходимости тратить драгоценное время на подключение наших сценариев сборки и загрузчиков Webpack, а также на нашу символическую ссылку, указывающую на каталог нашего проекта. Моя команда выбрала скелет Firebones, потому что он подходит для нашего случая использования, но есть много вариантов скелета с открытым исходным кодом, доступных на выбор.
Шаг 6. Напишите маршруты внутреннего API (или прослушиватели Firebase)
Если бы мы не использовали облачную базу данных, пора было бы начать писать наши внутренние экспресс-маршруты для выполнения запросов к нашей базе данных. Но поскольку мы использовали Firebase, который уже находится в облаке и имеет другой способ взаимодействия с кодом, мы просто работали над настройкой нашего первого успешного прослушивателя базы данных.
Чтобы убедиться, что наш слушатель работает, мы разработали базовую пользовательскую форму для создания цели и увидели, что действительно, когда мы заполняли форму, наша база данных обновлялась в реальном времени. Мы были связаны!
Шаг 7. Создайте «Доказательство концепции»
Нашим следующим шагом было создание «доказательства концепции» для нашего приложения или прототипа наиболее сложных фундаментальных функций для реализации, демонстрирующих, что наше приложение может в конечном итоге существуют. Для нас это означало найти интерфейсную библиотеку для удовлетворительного рендеринга временных шкал и успешно подключить ее к Firebase для отображения некоторых исходных данных в нашей базе данных.
Мы нашли Victory.JS, библиотеку React, построенную на D3, и потратили день на чтение документации и составление очень простого примера компонента VictoryLine и Компонент VictoryScatter для визуального отображения данных из базы данных. Действительно, сработало! Мы были готовы к строительству.
Шаг 8. Закодируйте функции
Наконец, пришло время реализовать все замечательные функции нашего приложения. Это гигантский шаг, который, очевидно, будет широко варьироваться в зависимости от приложения, которое вы создаете лично. Мы просмотрели наши макеты и начали кодировать отдельные пользовательские истории в нашем Waffle. Это часто включало касание как внешнего, так и внутреннего кода (например, создание интерфейсной формы, а также подключение ее к базе данных). Наши функции варьировались от основных до второстепенных и включали такие вещи, как:
- способность создавать новые цели, вехи и отметки
- возможность удалять цели, вехи и отметки
- возможность изменить название, цвет и детали временной шкалы
- возможность увеличивать шкалу времени
- возможность добавлять ссылки на ресурсы
- возможность загружать медиа
- способность перебрасывать ресурсы и медиа с вех и отметок до связанных с ними целей
- интеграция с редактором форматированного текста
- регистрация пользователя / аутентификация / OAuth
- всплывающее окно для просмотра параметров временной шкалы
- загрузочные экраны
По очевидным причинам этот шаг занял большую часть нашего времени - именно на этом этапе происходила большая часть сложного кода, и каждый раз, когда мы завершали работу над функцией, всегда было что доработать!
Шаг 9: Выберите и закодируйте схему дизайна
Как только мы получили MVP желаемой функциональности в нашем приложении, пришло время очистить его и сделать красивым. Моя команда использовала Material-UI для таких компонентов, как поля формы, меню и вкладки входа в систему, благодаря чему все выглядело гладко, безупречно и согласованно без каких-либо глубоких знаний о дизайне.
Мы потратили некоторое время, выбирая цветовую схему и редактируя CSS, что дало нам хороший перерыв в кодировании в окопах. Мы также разработали логотип и загрузили значок.
Шаг 10. Найдите и устраните ошибки
Хотя нам с самого начала следовало использовать разработку через тестирование, временные ограничения не оставляли нам драгоценного времени на что-либо, кроме функций. Это означало, что последние два дня мы потратили на моделирование каждого пользовательского потока, о котором только могли подумать, и на поиск ошибок в нашем приложении.
Этот процесс не был самым систематическим, но мы обнаружили множество ошибок, которые заставляли нас быть занятыми, в том числе ошибку, при которой экран загрузки в определенных ситуациях длился бесконечно, а также ошибку, при которой компонент ресурсов полностью переставал работать. Исправление ошибок может раздражать, но когда оно наконец сработает, оно приносит огромное удовлетворение.
Шаг 11. Разверните живое приложение
Последним шагом было развертывание нашего приложения , чтобы оно было доступно вживую! Поскольку мы использовали Firebase для хранения наших данных, мы развернули Firebase на хостинге, который был интуитивно понятным и простым. Если ваша серверная часть использует другую базу данных, вы можете использовать Heroku или DigitalOcean. Как правило, инструкции по развертыванию легко доступны на сайте хостинга.
Мы также купили дешевое доменное имя на Namecheap.com, чтобы сделать наше приложение более удобным и доступным.
Вот и все - мы внезапно стали соавторами настоящего живого полнофункционального приложения, которое кто-то мог использовать! Если бы у нас была более длинная взлетно-посадочная полоса, на шаге 12 было бы проведено A / B-тестирование пользователей, чтобы мы могли лучше понять, как реальные пользователи взаимодействуют с нашим приложением и что они хотели бы видеть в версии 2.
На данный момент, однако, мы довольны конечным продуктом и неизмеримыми знаниями и пониманием, которые мы приобрели в ходе этого процесса. Проверьте Align здесь!
- -
Если вам понравился этот кусок, я бы хотел, если бы вы попали в зеленое сердце 💚, чтобы другие могли наткнуться на него. Не стесняйтесь ознакомиться с исходным кодом Align и подписывайтесь на меня на Github, а также с членами моей крутой команды, Sara Kladky и Melanie Mohn.
