Этот пост в блоге будет посвящен более мелким деталям выбора технологий и сервисов, подходящих для разработки веб-приложения. Он выходит за рамки базовой базы данных/сервера/интерфейса (например, MEAN = MongoDB, Express.js, AngularJS, Node.js) и включает в себя более конкретные сведения, например, какой препроцессор CSS, какая служба непрерывной интеграции и какой компилятор использовать. использовать.
Каждая из этих точек принятия решений была и, вероятно, будет оставаться предметом множества хороших сообщений в блогах, которые, я уверен, вы найдете сами. Эта запись в блоге представляет собой пример из практики, который поможет всем, кто начинает проект разработки, обдумать логику того, что будет лучше для их индивидуального приложения, а не попадаться в ловушку предположения, что один инструмент всегда является правильным. решение поставленной задачи. Как гласит старая поговорка: Если у вас есть только молоток, все выглядит как гвоздь.
Сначала краткое описание нашего приложения:
- MVP (минимально жизнеспособный продукт): синхронизируемая в реальном времени общая доска/текстовый редактор для использования в интервью, удаленном сотрудничестве и удаленном обучении.
- (Основной) технический стек: React/Redux, Express.js, Node.js, PostgreSQL
- Расширенные цели: интеграция аудио/видео телеконференций (вероятно, через WebRTC), интеграция с проблемами GitHub, различные режимы обмена и настройки ввода (цвет/размер/форма пера, подсветка синтаксиса текста и т. д.)
- Сроки: 4 недели — в идеале 1 неделя на исследование/планирование, 1 неделя на создание MVP, 1 неделя на создание расширенных функций и 1 неделя чистой полировки.
- Команда: 5 full-stack разработчиков Javascript
Шаг 1. Определите области согласия
Мы довольно быстро определились с нашим базовым техническим стеком, хотя было необходимо некоторое обсуждение того, что можно использовать в сочетании с React (Redux, Native и т. д.). Но как только мы начали обсуждать более мелкие детали того, как настроить и запустить проект, мы поняли, что есть много решений, над которыми нам нужно подумать.
У нас была очень сильная команда, но также и очень самоуверенная: у каждого человека были определенные инструменты, которые он знал лучше всего или которые больше всего интересовали, и между многими из нас это было довольно много.
Мы рассмотрели виды инструментов и соглашений, которые хотели использовать, и определили, с какими из них мы все уже согласились. Это были:
- Redux.js: для управления сложным состоянием всего приложения
- Material-UI: для легкого внешнего оформления и дизайна
- Socket.io с использованием пространств имен: для обработки отдельных комнат с синхронизацией в реальном времени, каждая с доской и текстовым редактором.
- ESLint: следуя руководству по стилю AirBnB Javascript/React
- ES2015/ES6: транспилировано Babel
Шаг 2: Определите точки принятия решений
Оттуда мы определили, какие типы инструментов мы также хотели использовать, но у нас возник вопрос, какой из них будет работать лучше всего:
- Язык препроцессора/расширения CSS (Sass или LESS)
- Сервис непрерывной интеграции (CircleCI, TravisCI или Codeship)
- Компилятор/Бандлер (Browserify или Webpack)
- Управление проектами (Trello/Waffle.io или нативные Github Issues/Project boards)
У нас были члены группы с предпочтениями для каждой категории, но мы знали, что никто в нашей группе не использовал оба инструмента ни в одной из этих категорий, и мы не хотели принимать решения, не учитывая обе стороны.
Шаг 3: Исследование
Чтобы не принимать опрометчивых решений, мы решили позволить каждому кратко взглянуть на обе стороны каждой проблемы самостоятельно.
Чтобы мы могли получить немного больше глубины, мы также назначили каждую проблему одному или членам команды, которые будут более подробно изучать этот конкретный набор и сообщать о том, что они нашли.
Мы прервались на вечер и снова собрались на следующий день, чтобы обсудить. Каждый из нас просматривал сайты для каждого инструмента, чтобы увидеть их предложения, а также множество сторонних статей, в которых сравнивались и противопоставлялись рассматриваемые инструменты. На каждый из этих вопросов есть миллион сообщений в блогах. Каждая из них будет предлагать немного разные точки зрения, но ни у кого нет времени прочитать их все. Как правило, прочитав несколько, вы обнаружите, что понимаете основные различия. Затем, зная основные вопросы, вы можете легко просмотреть еще полдюжины относительно быстро и все же понять с некоторыми нюансами, где они стоят. В этот момент вы должны быть готовы обсудить это.
(Этот подход разработан для небольших приложений, где перенастройка по мере необходимости относительно проста. Для более крупных корпоративных приложений может быть целесообразно, чтобы назначенный член команды провел ограниченные пробные версии с каждым отдельным инструментом, чтобы получить более глубокий и личный смысл для как они работают, чтобы вы могли быть уверены, что они будут соответствовать вашим целям, прежде чем тратить значительное время на разработку, используя неправильный инструмент.)
Шаг 4: Групповое обсуждение
На следующий день мы снова собрались вместе и сообщили о наших находках.
Мы узнали, что Sass больше похож на полноценный язык расширений CSS в сочетании с препроцессором, тогда как LESS — это скорее простой препроцессор. LESS вел себя как родной CSS и не требовал никакой работы с командной строкой для его настройки. Это часто делало его идеальным для людей, только начинающих работать с препроцессором, или для дизайнеров, которые не хотели возиться с поведением языка (например, запуск сверху вниз и переназначение переменных по ходу дела) или устанавливали его с помощью команды линия. Но для такой команды разработчиков Javascript, как мы, командная строка и поведение языка были довольно знакомы, а простая расширяемость Sass с помощью библиотек/наборов инструментов, таких как Compass или Bourbon, значительно упростила изучение и сделала его более универсальным в использовании.
Подходящий инструмент для нашего приложения: Sass
Мы обнаружили, что CircleCI, TravisCI и Codeship имеют схожую функциональность: каждый из них запускал регрессионные тесты на запросах на вытягивание, чтобы убедиться, что был слит только жизнеспособный код. CircleCI может похвастаться немного более быстрыми тестовыми сборками, но это было единственное функциональное отличие, которое мы могли заметить на первый взгляд. Выбор сводился к тому, что имело наилучшую поддержку для нашего типа проекта: а именно, быстро и интенсивно разрабатываемое приложение с открытым исходным кодом, которое было бы построено на бюджете. Хотя у CircleCI был один бесплатный неограниченный контейнер, он не был хорошо настроен для работы с открытым исходным кодом. И Codeship ограничил свой бесплатный контейнер 100 сборками в месяц, что мы, вероятно, превысим. TravisCI, с другой стороны, предоставил полную бесплатную поддержку всем проектам с открытым исходным кодом, что сделало его очевидным выбором для нас.
Правильный инструмент для нашего приложения: TravisCI
- Компилятор/сборщик (Browserify или Webpack)
Наше предварительное исследование показало, что, хотя Webpack предлагает больше функциональных возможностей (полное управление задачами для тестирования, линтинг, минимизация и т. д.), длительное время настройки не будет стоить MVP, для которого нам просто нужен простой упаковщик. Но это было бы хорошо, когда приложение начало выходить за рамки базовой настройки. Поэтому мы выбрали нестандартный подход: использовать оба инструмента, каждый для разных этапов разработки. Мы использовали бы быструю и грязную настройку для Browserify, пока не сделали основы, а затем переходили бы к использованию Webpack для более поздней разработки, вероятно, на неделе 3, когда мы (в идеале) работали над дополнительными целями.
Правильный инструмент для нашего приложения: Browserify для запуска, Webpack для последующего использования.
У нас в группе были сильные мнения, которые исключали такие решения, как Zenhub (потому что это слишком сильно изменило пространство репозитория Github), поэтому у нас был выбор между использованием внешней системы управления проектами, такой как Trello, или остаться в рамках Github и использовать их. доски проекта. Оба метода теоретически могут быть интегрированы с проблемами Github, хотя это, безусловно, проще с собственными досками проектов Github. Такие инструменты, как Waffle.io, отлично подходят для координации различных команд, но, поскольку вся наша команда состоит из разработчиков Javascript, и мы все равно будем выполнять большую часть нашей работы в нашем репозитории Github, мы решили, что будет проще просто использовать их собственные доски проектов. .
Правильный инструмент для нашего приложения: задачи Github/доски проектов
Шаг 5: Подведение итогов и повторное посещение
Теперь, когда мы решили, какие инструменты использовать, мы обсудили другие проблемы организации, например, если/когда/как мы хотим проводить проверки кода, кто возьмет на себя какие agile-роли и как мы хотим структурировать наши спринты.
Мы также решили периодически пересматривать, какие инструменты мы использовали и как мы их использовали, в наших ретроспективах спринта, чтобы убедиться, что все они работают хорошо. Если в конечном итоге мы обнаруживали, что данный инструмент добавляет больше блокировщиков, чем помогает, нам нужна была гибкость для переключения.
Вывод:
Надеюсь, этот пример помог вам обдумать, как решить, какие инструменты использовать. Может быть, дал вам некоторые идеи инструментов, которые вы, возможно, захотите попробовать в своем следующем приложении. Для разработчика почти всегда полезно попробовать новые инструменты, но это может быть ошеломляюще с таким количеством инструментов! С каждым днем появляется все больше и больше.
Тем не менее, небольшое исследование и групповое обсуждение помогут вам определить новые инструменты, которые облегчат ваш процесс, не добавляя лишнего беспорядка в рабочий процесс. Таким образом, вы всегда можете учиться и расширять свой набор инструментов как разработчик.
