Популярные технологии, документация и единый стиль кода. Что учесть при разработке MVP ИТ-проекта

Содержание:

• От MVP к продукту: стоит ли продолжать «по накатанной»
• Как выстроить прозрачный и предсказуемый процесс разработки
• Рекомендации по разработке готового продукта из MVP

От MVP к продукту: стоит ли продолжать «по накатанной»

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

И если проблемы, связанные с плохим кодом, можно компенсировать увеличением вычислительных ресурсов, то проблемы на уровне архитектуры приложения или на уровне архитектуры инфраструктуры можно будет исправить, только остановив работу сервиса.

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

• CI/CD — возможность удобно и оперативно доставлять созданные разработчиками новые функции в приложение, обычно без остановки его работы, сокращать затраты за счет автоматизации процессов и гарантировать полностью идентичную работу приложения на всех этапах — в разработке, тестировании и продакшене;
• Резервное копирование; 
• Мониторинг и централизованный процессинг логов — правильный сбор, хранение и обработка служебной информации о состоянии приложения помогают быстрее понять, где произошла ошибка, и оперативно узнать о проблемах, в том числе скрытых; 
• Сканеры качества кода и безопасности версий ПО; 
• Документация для сработавших триггеров — подробно расписаны действия в случае отказа или предотказной ситуации в работе приложения, настроена нотификация. В идеале — написан Runbook. Runbook — это механизм, который автоматически запускается и восстанавливает работоспособность системы при обнаружении конкретной проблемы; 
• Проверен план аварийного восстановления (DRP); 
• Предусмотрен трейсинг для больших микросервисных продуктов — при длинной цепочке взаимодействия микросервисов это решение помогает понять, на каком шаге произошла ошибка. 

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

Готовое приложение развертывается в спроектированной ранее инфраструктуре, то есть написанный код превращается в то самое приложение, с которым взаимодействует пользователь. 

Есть два подхода к управлению этим процессом и самой инфраструктурой: ручной и автоматизированный (более известный как IaC, Infrastructure as a Code). 

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

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

Подход Infrastructure as a Code (или «инфраструктура как код») позволяет описать действия, необходимые для развертывания и настройки системы, как выполняемый код и зафиксировать результат его выполнения, достигнув повторяемости и неизменяемости.

Для настройки IaC потребуется дополнительный блок работ и участие DevOps-специалистов, однако у этого подхода есть преимущества: 

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

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

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

Эти недостатки дешевле было бы устранить или вовсе не допустить на более ранней стадии.

• Без CI/CD команда разработки вынуждена будет при каждом обновлении вручную развертывать новую версию приложения на сервере, что сильно увеличивает временные рамки проекта и загруженность команды.
• Без мониторинга невозможно контролировать работоспособность приложения и вовремя определять его недоступность для пользователей и обнаружить скрытые проблемы (например, долгий отклик для малого процента пользователей).
• Без системы логирования сложно быстро определить причину ошибки и быстро отладить ее.
• Без трейсинга невозможно определить, где возникла ошибка, которая вызвала отказ всего приложения или отдельных микросервисов. 
• Непродуманная архитектура не позволяет правильно масштабировать решение.

Как выстроить прозрачный и предсказуемый процесс разработки

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

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

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

По теме: Как провести аудит мобильного приложения 

Рекомендации по разработке готового продукта из MVP

На что в первую очередь стоит обратить внимание после того как вы поняли, что ваш продукт успешен?

Масштабируемая архитектура

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

Это критически важно для того, чтобы соблюсти баланс — чтобы, с одной стороны, первая же маркетинговая активность не «положила» приложение под нагрузкой, а с другой — чтобы при небольшом количестве пользователей инфраструктура не стоила как крыло от Боинга.

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

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

CI/CD, мониторинг и другие DevOps-инструменты, описанные выше

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

Планирование подходов в разработке

Единый для команды стиль кода, внедренные принципы автоматического тестирования, установленные и работающие статические анализаторы кода, а также внедрение перекрестного Code Review в процесс разработки может существенно поднять качество кода и дать бизнесу уверенность в том, что продукт можно развивать и поддерживать. 

Документация

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

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

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