Стартап глазами разработчика. Какой framework лучше выбрать

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

Что объединяет эти идеи, и что это значит? Люди стали ценить свое время выше денег, которые они зарабатывают на работе. При этом необязательно иметь какую-то совсем уникальную идею, достаточно уметь делать что-то лучше других или иметь некоторую изюминку.

В интернете много вдохновляющих историй о том, что вышел очередной перспективный стартап, который уже обрел многомиллионные инвестиции. На конференции «Продвижение», организованной Программой «Единая фронтальная система», много говорили о создании новых продуктов и о стартапах, а в финале конкурса даже выбирали лучшие идеи банковского приложения.

И сегодня в нашем посте Николай Надоричев, лидер front-end разработки Программы «Единая фронтальная система» Сбербанка, расскажет о своем видении стартапов, о распространенных ошибках и о том, как с помощью технологии React создать приложение за один вечер.

Подходы к разработке

Что мы знаем о разработке стартапа? Она состоит из нескольких этапов:

1. Proof of concept
2. Получение инвестиций
3. Сбор команды
4. Разработка MVP
5. Презентация инвестору и получение нового раунда финансирования

Многие стартапы совершают ошибку, пытаясь разработать MVP до похода к венчурным фондам. Это приводит к тому, что со временем мотивация команды падает, и увеличивается вероятность того, что проект не увидит свет. Чтобы этого не случилось, необходимо четко понимать, когда стоит остановиться и выводить продукт вовне. Если взглянуть на консалтинговые компании, то можно увидеть, что многие их продукты проходят стадию presale, когда время на разработку жестко фиксируют, чтобы не допустить разбазаривания ресурсов компании.

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

Причины неудач

Мы придумали стартап, он классный, но не выстрелил. Почему?

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

Вторая причина — проработка детальной архитектуры приложения. Всегда хочется создать идеальный продукт с идеальной архитектурой. Но это работает только в крупных корпорациях, где есть возможность финансировать даже продукт, в котором не написано ни одной строчки кода. И часто это отсылка к водопадной модели разработки ^[1].

Однако затягивание процесса получения обратной связи от инвестора может повлечь колоссальные затраты по переписыванию кода. Если есть в команде человек, который знает гибкие методологии разработки, то полезно будет построить разработку по модели scrum ^[2]. Если такого человека нет, то можно не использовать методологии разработки вовсе. Достаточно общего командного чата для оперативного решения возникающих проблем и задач.

Стек технологий

Фреймворк

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

Во-первых, необходимо определиться с фреймворком, который будет использоваться в проекте. Основная цель фреймворка — задать правила игры, по которым будет происходить разработка продукта. В мире фронтенда огромное количество различных технологий, но давайте обозначим критерии выбора:

• поддержка сообществом
• продвижение гигантами IT-индустрии
• легкость освоения
• зрелость технологии.

Начнем по порядку. Поддержка сообществом подразумевает количество npm-пакетов, которые могут расширить функционал приложения, а также количество коммитов в проекте от внешних разработчиков. Далее обратим внимание на продвижение гигантами IT: каким бы хорошим продукт ни был, всегда важна его узнаваемость. Если у продукта за плечами стоит огромная корпорация, то велик шанс того, что он внезапно закроется, превратив ваш мегапроект в кучу legacy-кода. Третий немаловажный факт — легкость освоения. На мой взгляд, здесь не нужны дополнительные комментарии: зачем разрабатывать на фреймворке, который убьет много времени на освоение? И последний по списку, но не по важности параметр — зрелость. Как долго технология существует на рынке? Как активно развивается? Ответив на эти вопросы словами «давно» и «активно», можно говорить о том, что технология вам подходит.

Исходя из этих соображений, мы в Программе «Единая фронтальная система» выбрали основным фреймворком для разработки React. Почему? Давайте пройдемся по всем пунктам: для React существует огромное количество написанных элементов UI, библиотек для управления состоянием приложения и других модулей ^[3]. Это делает возможным не делать часть своей работы — можно просто взять готовый компонент и встроить его в приложение.

Ко всему прочему, React прост в освоении и разработчиков, знающих его, на рынке довольно много. Это позволит собрать команду и отправить ее сразу в бой.

При всех преимуществах React имеет ложку дегтя в виде сложной настройки проекта. К счастью, Facebook позаботился об этом и выпустил проект Create React App ^[4]. Он изначально заточен на быстрый старт проекта с переходом от идеи сразу к разработке.

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

UIKit

Позволить себе создать свой собственный уникальный набор UI-компонентов могут только компании, у которых уже есть отдельная команда для разработки UIKit'а. Известны истории, когда UIKit разрабатывается всеми продуктовыми командами совместно, но у этого подхода есть ключевой недостаток: чем больше разработчиков, тем больше мнений. И в конечном счете это приведет к тому, что каждая команда будет перетягивать одеяло на себя.

Но наша цель — выпустить MVP в короткие сроки. На просторах сети есть множество готовых решений, как платных, так и open source. Можно назвать несколько популярных:

• Semantic UI ^[5]
• react-bootstrap ^[6]
• react-material ^[7]

У каждого из них свой дизайн, остается только выбрать, какой больше нравится.

MVP

Или Minimum Viable Product — минимально жизнеспособный продукт. Он подразумевает то, что есть некоторый минимум приложения, который обеспечивает подтверждение концепции. Его основная цель — в том, чтобы показать, что продукт имеет право на жизнь. Он не требует детальной проработки архитектуры баз данных, работе под высокой нагрузкой и красивого дизайна. Зачастую он показывает некоторую интерактивную картинку, которую можно пощупать.

И главное — не забывайте всегда думать о будущем проекта. Надо понимать, нужен ли продукт, каковы его дальнейшие перспективы. И если вы честно ответите себе на этот вопрос положительно – тогда стоит рваться в бой и побеждать. А вы пробовали участвовать в стартапе или организовывали свой? Какие успехи? Приглашаем к обсуждению в комментариях. 

Автор: EFS_programm

Источник ^[8]