Хм… Я писал эту новую историю и забыл кое-что важное: будь гибким. Цель этой серии историй — как начать проект выпускного года, что бы ни случилось.

Независимо от того, есть у вас идея или нет, настройка среды — один из самых важных шагов при разработке приложения. Я собираюсь разработать приложение на основе NodeJS, и, извините за нечестность, я собираюсь разработать туристическое мобильное приложение, поддерживаемое серверным API и веб-приложением для создания контента, который будет потреблять мобильное приложение. Я буду использовать некоторые интересные сторонние API, такие как Google Maps и FCM, для отправки push-уведомлений с сервера на любое мобильное устройство.

Резюме.

  1. Настройте среду.
  2. Как управлять кодом?
  3. Где я буду писать свой код?
  4. Как я буду планировать свой проект?
  5. Мне нужно что-нибудь еще?

Настройка всего окружения.

Как я уже сказал, я знаю только, что у меня будет веб-приложение, мобильное приложение и сервер, все они основаны на NodeJS, поэтому первым шагом будет установка NodeJS. Вы можете найти соответствующий установщик на веб-сайте NodeJS: https://nodejs.org/en/download/

Установить NodeJS довольно просто, просто следуйте инструкциям и все. Документации о том, как установить NodeJS в разные операционные системы, очень много, поэтому я не буду тратить время на объяснение того, как это сделать. Эта история не руководство по NodeJS, я скоро напишу пост, посвященный NodeJS, так что сейчас я собираюсь сосредоточиться на том, чтобы запустить проект как можно быстрее.

Краткое описание NodeJS.

Большинство авторов описывают NodeJS как JavaScript, который работает на стороне сервера. И это правда. И, возможно, это единственное описание, которое вам нужно на данный момент. В дополнение к этому плохому описанию я должен добавить, что NodeJS — это асинхронная среда выполнения JavaScript, управляемая событиями(согласно официальной документации).

После того, как вы установили NodeJS на свой компьютер, у вас будут две мощные команды, готовые к работе:

  • Команда node: полезно запускать файлы JavaScript, а также использовать терминал REPL узла для выполнения модулей узла или кода JavaScript. С помощью этой команды мы запустим наше серверное приложение.
  • Команда npm: это Диспетчер пакетов узла, реестр, где мы можем найти множество готовых общих модулей JavaScript, библиотек или фреймворков. импортировать в наш собственный проект.

Команда npm удобна для поиска и последующей установки кода или библиотек, совместно используемых другими людьми, непосредственно в вашем собственном проекте, но вы также можете поделиться своими проектами с другими людьми. Прежде чем поделиться своим проектом, вам понадобится специальный файл, в котором описаны все зависимости, на основе которых был разработан ваш проект, а также информация о вашем собственном проекте и набор полезных скриптов для запуска, отладки, сборки или тестирования вашего проекта. Этот файл называется package.json.

Инициализация модуля NodeJS (или проекта).

Поэтому мы можем инициализировать наш проект, просто набрав npm init. Эта утилита запросит у вас некоторую информацию о вашем проекте и создаст файл package.json с этой информацией.

Установка зависимостей.

Мы инициализировали наш проект, поэтому пришло время добавить некоторые зависимости. Прежде всего, я сосредоточусь на своем серверном приложении. Лучшая комбинация для разработки сервера на основе NodeJS — это сам NodeJS, Express и, возможно, Swagger для создания API на нашем сервере, поэтому давайте приступим к установке зависимостей. Мы будем использовать команду npm install для установки зависимостей в наш проект.

npm install --save express swagger-express-mw

Когда вы используете команду npm install, вы должны иметь в виду несколько общих параметров:

  • --save: он установит зависимости локально в ваш проект и добавит ссылку в файл package.json.
  • --save-dev: он установит зависимости локально в ваш проект, но эти зависимости будут недоступны в рабочем режиме. С этой опцией мы будем устанавливать зависимости, такие как тестовые фреймворки.
  • -g: он установит зависимости глобально. Это полезно, когда зависимость представляет собой CLI, который предоставляет полезную команду, которую мы можем использовать в терминале, например, gulp, typescript и т. д.

Кроме того, когда вы используете команду npm install, она создаст папку с именем node_modules, где вы найдете все установленные зависимости.

Сокращение: если вы не хотите тратить время на установку всех зависимостей самостоятельно, вы можете использовать генератор кода, такой как yeoman. Он имеет множество генераторов для создания всего приложения за считанные секунды.

Обеспечьте защиту своего кода: используйте систему контроля версий.

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

Git за кулисами.

Как я уже говорил, я собираюсь использовать Git, который распространяется, и, поскольку я не хочу терять код, я собираюсь загрузить свой репозиторий на онлайн-хостинг Git. Существует несколько веб-хостингов Git, как бесплатных, так и платных, и, поскольку я нахожусь в студенческом режиме, я упомяну самые популярные:

  1. GitHub: самый распространенный и справочный. Вероятно, в процессе найма кто-то спрашивает вас, есть ли у вас репозиторий в GitHub, чтобы узнать о вашей работе.
  2. GitLab: быстро растет. У него есть преимущество перед GitHub, потому что он включает в себя другие инструменты, такие как непрерывная интеграция.
  3. Битбакет: работает так, как работает GitHub.

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

Git под Windows…

Я в основном использую Windows в качестве среды разработки (эй! не судите меня!), поэтому первый инструмент, который вам понадобится, это git-scm. Он работает как инструмент командной строки, то есть, если вы предпочитаете установить графический инструмент, у вас есть несколько возможностей:

  • GitHub Desktop: мне не очень нравится, но это полезно, и лучше работать в Интернете или с командной строкой. Это бесплатно.
  • Sourcetree: немного лучше, чем GitHub Desktop. Это бесплатно и довольно просто.
  • GitKraken: мой любимый (но иногда). Вы можете увидеть свои ветки графически. Это бесплатно для некоммерческого использования.

Большинство из них включают git-scm, поэтому вам не нужно устанавливать его раньше, хотя это настоятельно рекомендуется.

Войны клонов.

Давайте клонируем наш недавно созданный репозиторий! После клонирования мы сможем создать структуру нашего проекта и первые файлы нашего репозитория. В Интернете есть множество руководств, которые помогут научиться клонировать репозиторий Git и управлять им на основе выбранного вами приложения.

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

После клонирования у вас будет копия вашего репозитория для работы в ваших локальных системах.

Пришло время кодировать! Где мой редактор?

Он сказал редактор? Да, у меня есть! Вы можете кодировать в любом редакторе, который вы хотите. Есть мощные редакторы, такие как Sublime, Atom или Visual Studio Code, и полноценные IDE для простой работы, например, WebStorm или Eclipse. Я привык программировать с помощью Visual Studio Code, но если я вернусь к студенческому режиму, Visual Studio Code — один из лучших вариантов для работы с приложениями на основе NodeJS, особенно если я никогда ничего не разрабатывал.

Я не знаю, чего вы ждете! Перейдите на сайт Visual Studio Code и загрузите установщик для своей системы (да! хотя он разработан Microsoft, они подумали о каждом из нас, и он мультиплатформенный :D). Существует множество плагинов для улучшения нашего кода.

В мою задачу не входит объяснять, как работать с Visual Studio Code, по крайней мере, не здесь, поэтому перед этим прочтите документацию в Интернете. Конечно, если вы предпочитаете другой редактор или IDE, смело скачивайте его.

Фу! Это сложно, я знаю… но у нас есть несколько месяцев на разработку нашего проекта.

Планирование: будь успешным и не поддавайся хаосу.

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

  • Каскадное управление проектами: плохая идея. Если вы хотите тратить время и деньги, то эта стратегия — ваш лучший вариант для запуска вашего приложения на рынок. Разработка программного обеспечения должна быть быстрой, и вам нужно как можно скорее получить бета-версию.
  • Управление проектами Agile: это итеративный процесс, поэтому у вас может быть работающее приложение на каждой итерации, и вы можете вносить новые изменения или исправлять ошибки на каждой итерации. Важно быть маневренным. Быть гибким относится к набору методов и принципов.
  • Управление проектами SCRUM: это фреймворк, основанный на гибкой методологии, который идеально подходит для групп разработчиков. Если вы работаете над своим проектом один, использовать SCRUM нет смысла, а если вы команда из 5–7 человек, то можно! В SCRUM много церемоний, и иногда вы тратите время на то, чтобы поделиться своим статусом с коллегами.

Мы хотим быть гибкими, поэтому мы будем гибко управлять нашим проектом. Есть много инструментов, которые помогут нам спланировать наш проект графически. Бесплатный инструмент, который мы можем использовать, — это Visual Studio Teams Services (VSTS), теперь Azure DevOps Services. Если вы хотите использовать инструмент, это зависит от вас, но пока достаточно документа, в котором вы описываете все свои требования.

Стать ловким.

Хорошо, как мы собираемся применять Agile в нашем проекте?

  1. Определить спринт. Когда мы работаем в agile-режиме, мы устанавливаем период дней или недель, когда команде обещают сделать список требований. У каждого спринта есть начало и конец. На этом шаге мы установим количество недель на спринт (обычно каждый спринт занимает 2 или 3 недели).
  2. В начале спринта спланируйте невыполненную работу. Бэклог — это список требований, которые мы хотим разработать. Существует глобальный бэклог, требования которого не расставлены по приоритетам и не имеют фиксированного спринта, а также бэклог спринта. Бэклог спринта включает в себя все требования, которые мы хотим разработать в каждом спринте, и вся команда решает, какие из них следует разработать, а какие подождать, то есть каждое требование имеет приоритет. Кроме того, если есть баги или эти ошибки исходят из предыдущего спринта, мы должны исправить их в следующем спринте.
  3. Во время спринта. Каждый член команды выберет требование из журнала спринта, разделив каждое требование на задачи, чтобы упростить разработку каждого требования. Каждое требование имеет разные состояния, как правило, назначено, когда требование назначено члену команды, в процессе, когда участник работает над требованием, выполнено когда требование полностью разработано и закрытокогда требование разработано и протестировано.
  4. Завершение спринта. В конце спринта команда просматривает журнал спринта, чтобы узнать, какие требования были выполнены, какие требования находятся в разработке, а какие требования не были выполнены. Кроме того, команда проведет ретроспективу, чтобы узнать, что сработало, что не сработало и что они сделали бы по-другому в следующих спринтах. Эта ретроспектива полезна для улучшения способа управления проектом.
  5. Повторяю: пришло время начать новый спринт.

Гибкая многословность.

Теперь, когда мы знаем, как быть гибкими, следует запомнить несколько интересных слов:

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

Эпические, фичи и пользовательские истории более или менее описываются следующим предложением:

As a <<User>>
I want to <<what User want to do>>
so that <<why User needs this>>

Пользователь может быть конечным пользователем, разработчиком, нашей компанией или клиентом и т. д.

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

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