Счастливый путь к MVP

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

Реальность такова, что большинство разработчиков изо всех сил пытаются поддерживать качество и количество, когда речь идет о постоянно ускоряющемся темпе, необходимом для того, чтобы не отставать от требований рынка. Одна из лучших вещей, которую может сделать любой разработчик, — это выбрать стек и создать стартовый пакет на основе своего идеального рабочего процесса. Эта статья поможет вам создать один из них для GraphQL API с внешним интерфейсом ReactJS и внутренним интерфейсом TypeScript.

Предупреждение — неполный пример

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

Стек

В настоящее время мой предпочтительный стек для создания функционального прототипа во время проекта с нуля выглядит следующим образом.

Машинопись — Я думаю, что при создании API-интерфейсов GraphQL существенное использование типов как во внешнем, так и во внутреннем коде приводит к гораздо лучшему результату.

ПРИМЕЧАНИЕ. Я начал экспериментировать с Причина в качестве замены TypeScript, но обнаружил, что не все инструменты, которые я предпочитаю, совместимы.

Реагировать — Я использовал Angular 2+, Vue и некоторые другие, но обнаружил, что доступные ресурсы и библиотеки компонентов, доступные в React, дали мне лучшую стартовую панель для быстрого продвижения. Я бы сказал, что лучше всего использовать то, что вам наиболее удобно или соответствует потребностям проекта.

Героку / AWS — Для хостинга использую либо Heroku, либо AWS — в зависимости от нормативных требований. Я верю в инфраструктуру как в код, который необходим для быстрой итерации.

КИ/КД — Это абсолютно выбор дилеров. В зависимости от потребностей вашего проекта и среды существует множество вариантов, убедитесь, что вы автоматизировали набор тестов и развертывание с первого дня.

Гит — Да. Сделай это.

Процесс

Теперь, когда мы создали сцену, давайте начнем! Создайте новую пустую папку и cd внутрь.

# 1 Структура папок

Я знаю, у вас есть мысли или идеи о том, куда положить вещи, и вы хотите сказать мне, куда это положить. Выслушайте меня.

mkdir code docs design

Я начинаю с создания трех папок — code, docs и design. Если вы не начнете с четкой структуры папок, это может привести к беспорядку файлов, который заставит вас часами искать электронную почту. ПОТЕРПЕТЬ НЕУДАЧУ. Мне нравится держать вещи в порядке с помощью следующего:

code — Здесь вы создаете репозиторий проекта, чтобы сохранить свой код.

docs — Это не ваша документация по коду, она должна быть в code/docs — это для бизнес-документов и предоставленных клиентом ресурсов, связанных с требованиями или доменными ресурсами, связанными с проектом.

design — Эта папка очень важна (видите, что я там делал?). Одним из часто упускаемых из виду аспектов надежного MVP является дизайн. Успех не выглядит как Bootstrap из коробки. Даже для тематических наборов пользовательского интерфейса требуется цветовая палитра, связанная с брендом или другими различными элементами и активами, которые не готовы войти в кодовую базу без дополнительной работы.

# 2 Git на это.

cd code && touch README.md && git init && git add . && git commit -a -m 'PROJECT START'

Да, я начинаю с README.md — нет npm init. Почему? Просто, я не всегда знаю, будет ли проект одним приложением или несколькими приложениями в монорепозитории, пока я не углублюсь в него. Я начинаю с пустой папки, а README настроил систему безопасности git без принуждения.

# 3 Разделить и инициализировать

Далее я хотел бы подумать о существующей инфраструктуре компаний. Будут ли API и пользовательский интерфейс развернуты отдельно? Является ли пользовательский интерфейс частью микросервисной системы пользовательского интерфейса (да, это важно)? Ответив на пару вопросов, вы сможете быстро разобраться в этом.

  1. Как это делается в настоящее время?
  2. Каков самый простой способ, который я могу изменить позже?
  3. Вы слишком усложняете вещи?
  4. Перечитайте №3.
  5. Настройте базовый API и пользовательский интерфейс с помощью простого теста, вызова API hello world и пользовательского интерфейса с помощью наблюдателей и тестирования и запустите его с помощью одного сценария. Шаг сборки имеет множество опций (скрипты npm, nodemon, PM2, Lerna).

# 4 Не начинайте в пользовательском интерфейсе.

Я знаю, клиент хочет видеть прогресс раньше. Не волнуйтесь, GraphQL вас прикроет. Первое, что я делаю, это начинаю со схемы, основанной либо на DSL, либо на коде, и запускаю GraphQL Playground. При этом вы можете показать клиенту модальную схему, которая еще не реализована, но может показать хороший визуальный эффект — поверьте мне — они впечатлены.

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

#5 Тестирование, Тестирование 1…2…3

Тьфу, не очередной фанатик TDD. Не бойтесь; Я выздоравливающий TDD’ер. Но при работе над новым проектом — это обязательно, и чтобы делать это уверенно, нужно провести некоторое тестирование. Подойдите к этому любым способом, который вам нравится, но не пропускайте его. Если пропустить, они придут — и под ними я подразумеваю баги и недовольных клиентов.

Создавая свой API на основе тестов, вы знаете, когда приступите к созданию своего пользовательского интерфейса, что API-интерфейсы GraphQL будут работать и не требуют переключения контекста между интерфейсом и сервером, пытаясь разработать функции.

№6 Строить или не строить.

Выберите зрелый комплект пользовательского интерфейса или создайте его из минимального количества библиотек. НЕ сворачивайте свои собственные для MVP. При быстром перемещении нетрудно дважды связать действия щелчка или плохо запомнить компоненты, которые могут создать клудж. Мне нравится AntD и его дизайн-система из-за качества и простоты использования компонентов.

# 7 Найдите кого-нибудь еще для контроля качества или автоматизируйте и это.

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

# 8 Задокументируйте это, как будто это не так.

Оставляйте комментарии к коду и создавайте четкую и удобную документацию для других разработчиков, которые придут после вас. И нет, «код как документация» здесь не правильный ответ. Мне еще не приходилось сталкиваться с командой разработчиков, которая так хорошо поддерживает код с принципами SOLID и DRY, что для него не требуется НИКАКОЙ документации. Кроме того, чтение сотен файлов для трассировки вызовов стека — это боль, и никто не хочет этого делать. Надежная документация и комментарии о том, что и почему вы решили сделать, будут иметь большое значение в будущем.

№9 Корабль. Судно. Судно.

Абсолютно необходимо, чтобы вы отправляли код ежедневно и несколько раз в день. Ежедневная отправка служит двум целям: во-первых, вы выполняете итерацию, что очень важно, а во-вторых, вы можете показать клиенту, что делаете работу, даже если может показаться, что проект застопорился вскоре после начала.

# 10 Поговорите с клиентом.

Разговор с клиентом может показаться очевидным, но если серьезно, вам нужно постоянно говорить с клиентом о том, что вы делаете и что планируете делать. Чрезмерное общение может очень быстро выявить недопонимание на ранней стадии, прежде чем его станет труднее исправить.

Вывод

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

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *