Эта запись размещена на сайте dev.to

Недавно я запустил арт-проект Важные люди, который снимал два года.

Я развернулся в октябре, но обслуживание и отладка затянулись больше месяца. Частично это было из-за неопытности, а другая - из-за превышения сроков.

На сайте представлены стилизованные профили из стоковых фотографий мужчин, которые играют огромную роль в моей жизни. Передняя часть статична с тахионами; серверной частью был Node / Express, API Sendgrid для ввода данных в форму и отправки электронных писем со встроенной формой, все записи собирались в MongoDB на MLab, а серверная часть размещалась на Heroku.

После нескольких критических замечаний с дизайнером я сделал мокапы в InVision, но под конец у меня было так мало времени, что я потратил больше времени на обработку ответов api и адаптацию проекта к Heroku, чем на проверку ошибок.

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

Передняя часть отсоединена от задней.

Пока данные возвращаются в формате JSON, я могу манипулировать ими, как мне нравится, в любой конечной точке URL, в которой я ссылаюсь на файл js с запросом на выборку.
Более года назад на курсе погружения в Angular я узнал, что маршрутизация должна обслуживать определенные части или файлы на конечных точках (т.е. '/' должен отвечать index.html и т. д.). Маршрутизация предназначена для отправки данных туда и обратно. Маршрутизация предназначена для отправки данных туда и обратно. Я все время вспоминаю об этом.

Сначала получите базовую функциональность. Отлаживайте одну вещь за раз.

Вместо того, чтобы собирать блоки кода с решениями из StackOverflow (что я делаю в стрессовых ситуациях), создание небольших тестовых приложений и проверка каждой строки кода имело смысл для создания функции, помогло больше, чем написание 10 строк спагетти-кода, который ломался в нескольких местах. . У меня возникло искушение добавить все больше и больше функций, таких как временная метка и логины Oauth, для комментирования (на мой взгляд, это было большим препятствием для такого небольшого проекта), но я должен был реалистично оценивать свои возможности.

Я не могу следовать своему собственному плану спринта.

… Так что я мог бы также выбрать наиболее продуктивный и увлекательный список задач, к которому я бы обязательно пересмотрел. Для меня это было трелло. Поскольку у меня было несколько завершенных проектов, было намного более реалистично выгрузить все в несколько столбцов на trello и переместить все, что было сделано, в столбец «Готово».

Создавайте API с учетом логических визуальных результатов

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

В случае отображения ответов на вопросы я не подумал:
1) об уведомлении пользователей по электронной почте, когда был опубликован ответ на вопрос
2) отображении только тех записей, в которых были как вопросы, так и ответы чтобы не было похоже на то, что вопросы остались без ответа или что запрос на получение не сработал
3) наличие такого количества переключаемых ярлыков для отображения важной информации на странице было ненужным (на самом деле минималистская одержимость функцией)
4) включая загрузчик или какую-то визуальную подсказку во время загрузки ответа выборки, но это также может быть чрезмерным

Определитесь с инструментами и прочтите документацию по ним, прежде чем переходить к этой части плана.

Я не думал о развертывании и имел только практическое представление о ведрах AWS. Было бы слишком рискованно изучать, как настроить сервер накануне запуска, поэтому Heroku казался хорошей ставкой, поскольку я уже был знаком с git.

Не тратьте время, пытаясь изучить новый фреймворк

(особенно в срок), если вы не готовы использовать его в продакшене.

Для сайта из 10 страниц это может быть просто лишним раздуванием и вводит ненужный трудоемкий градиент обучения.

Всегда тестируйте локально

Вернитесь к тестированию на локальном хосте, если что-то не удастся после развертывания на Heroku, и вместо этого создайте фиктивную страницу («Мы работаем над этим»). Импульсивное разочарование означало, что у меня было так много версий на Heroku, что я забыл, какие изменения я внес в бэкэнд-код. Console.logs для MongoDB также будет более разборчивым (поправьте меня, если я ошибаюсь)

Платить за игру - отстой, но последовательность может того стоить.

Я не знал, что у меня было время просмотра до 15 секунд!
Если вам нужно, чтобы он работал молниеносно, вероятно, стоит заплатить за уровень Heroku Hobby. Я слышал все эти замечательные вещи о бесплатном размещении небольшого проекта на Heroku, но это бессмысленно, если желаемое поведение простаивает, потому что сервер засыпает после получаса бездействия и его нужно разбудить по запросу. Я слышал, как люди писали сценарии, чтобы каждые полчаса будить сервер, чтобы он не спал. Похоже, это будет лишняя работа для человека, находящегося под давлением.

Дайте себе достаточно времени, чтобы все испортить.

… Примерно в 1,5 раза больше от финального спринта.

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

  • создать robots.txt, чтобы разрешить сканирование и индексацию в Интернете.
  • протестируйте метатеги Open Graph для Facebook и Twitter, чтобы обеспечить предварительный просмотр изображений и подписей для работы по обмену ссылками
  • привлечение нескольких пользователей к тестированию ссылок на веб-сайты
  • Используйте chrome devTools, чтобы проверить время производительности
  • убедитесь, что люди могут переходить по ссылкам и полям ввода
  • проверил, как страница выглядит на разных устройствах
  • убедился, что могу перемещаться по входам или кнопкам для фокусировки (доступность)

Этот список можно продолжать, но я бы очень хотел, чтобы это было несколько вещей.

Защитите свой проект и портфолио перед подачей заявления о приеме на работу.

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

Спасибо, что прочитали мои мысли о новичках. Каковы некоторые из ваших контрольных списков и рабочих процессов перед развертыванием?