Transcription
2026 год. Вайпкодинг перестал быть магией для избранных. Теперь даже человек без знания кода может запустить свой сервис или приложение за выходные. Звучит как фантастика, возможно, но это реальность, в которой мы уже вместе с вами живём. Здорово, вайпкодеры и те, кто хотят стать вайпкодерами.
В этом видео я дам вам полный roadmмаap от нуля до релиза. Расскажу, с чего начать, что изучать и на какие аспекты обратить внимание. Это будет теоретическое видео. По некоторым темам, которые будут затронуты, у меня уже сняты уроки. По другим же они скоро появятся. Но в любом случае после просмотра этого видео вы будете понимать, что вам нужно изучить, с чего начать, как вообще устроен вайп-кодинг и по какому пути идти, чтобы запустить свой первый проект. Да, может быть, уже и не первый. Всё как обычно. С меня годнота, с вас лайк и подписка. И мы начинаем.
Прежде чем начинать что-то делать, нужно понять, зачем это вообще нужно. Вайп-кодинг может быть полезен как трушным разработчикам, так и тем, кто с разработкой напрямую не связан. Поэтому сначала расскажу, какие я вообще вижу мотивы вайп-кодить и как на этом можно заработать.
Если вы разработчик, то всё просто. Для вас это буст вашей работы. С нейронками вы можете выполнять больше задач, делегировать и и агентом рутину, брать больше проектов и, как следствие, зарабатывать больше денег. А с вашим фундаментальным пониманием кода, как работают приложения, вы легко сможете направить нейронку в нужное русло, чтобы она делала то, что нужно именно вам. И в случае чего, если будет какая-то сложная задача, то вы без труда сможете сами залезть в код и исправить ошибки.
Для нетехнических предпринимателей это способ запустить проект без необходимости найма команды. Теперь вам не нужно искать команду разработчиков, платить им, договариваться. Вы можете сами запускать сервисы, тестировать ниши и потом уже, если хотите, нанимать кого-то для поддержки ваших сервисов и приложений. А, возможно, со временем вы решите, что вам и для поддержки никто не нужен, и вы сами можете прекрасно поддерживать ваши приложение.
Для фрилансеров открываются новые возможности брать заказы, которые раньше вы стремались брать, потому что вы не разбираетесь в коде. Ну, допустим, дизайнер, да, напрямую не связанный с разработкой человек. Ну, точнее, как бы связанный, но в код не лезет. Но при этом, если овладеть скилами вайпкодера, то кроме того, что вы нарисуете какой-то макет, вы ещё сможете реализовать его какие-нибудь лендинги. Ну, вообще на изи. А так-то можно и не лендинги, можно и приложение писать. То есть представьте, что раньше вы просто продумывали интерфейс, а теперь вы можете, кроме как продумать интерфейс, реализовать его, дать заказчику, а там он дальше уже сам пускай решает, что с этим делать. Может нанять каких-то разработчиков либо вообще дальше продолжать работать с вами. Но в любом случае он посмотрит уже не просто на картинку, а как минимум на рабочий прототип. И согласитесь, это гораздо более впечатляющий результат, за который можно, соответственно, и больше денег взять, и проще продавать свои услуги.
Но если говорить не про дизайн, то, в принципе, можно брать какие-то заказы по разработке, вайп-кодить их и зарабатывать на этом деньги. И нейронки уже на текущий момент хорошо работают с кодом. И с помощью них можно сделать достаточно много проектов, которые выходят далеко за пределы простого лендинга. Люди пилят саасы, люди пилят Telegram ботов, люди пилят какие-то нативные приложения и всё на нейронках. Я знаю кейсы, когда это всё делается людьми, которые вообще к коду никогда в жизни не прикасались. Это феноменально и очень круто.
И, наконец, вайпкодить можно для себя, ну или для своего бизнеса. Например, сделать приложение, которое нужно именно вам, которым лично вы будете пользоваться, либо будут пользоваться в вашей компании. То есть какое-то приложение внутри организации, которое поможет вам в вашей работе. При этом вы можете его упаковать, прикрутить туда оплату и зарабатывать ещё и на продаже этого приложения.
Надеюсь, этой вступительной частью у меня получилось вас замотивировать. Наверняка существуют и другие способы применения вайп-кодинга, но ограничимся этим. Давайте приступим уже к нашему Roadмаapпу. Roadmap, если что - это дорожная карта. В общем-то, просто пошаговый план освоения вот вайп-кодинга.
Так, всё-таки с чего начать? Я думаю, что если вы уже определились, что хотите что-то завайп-кодить, хотите вообще поизучать это направление, что-то попробовать сделать, то в первую очередь нужно выбрать инструмент, с помощью которого вы будете создавать приложения, сервисы, веб-сайты, в общем, что вам только захочется. За 2025 год появилось достаточно много инструментов, которые очень даже пригодны для вайп-кодинга. Но, на мой взгляд, два самых топовых инструмента на текущий момент - это курсор и клод-код. По клод-коду у меня есть полный гайд на моём канале. Очень подробное и полезное видео получилось, поэтому если заинтересуетесь, то перейдите, посмотрите, очень рекомендую.
Основная разница между этими двумя инструментами в том, что клодко-код - это консольная программа, то есть она открывается в консоли. Это на первый взгляд может показаться каким-то страшным чёрным окном, ну или уже не чёрным, собственно, где как. Но на самом деле относиться к ней надо гораздо проще. То есть это просто чат с нейронкой внутри терминала. По сути, это тот же самый привычный чат, как в ClД дектопе, в Chat GPT, ну и вообще много в каких сервисах уже вы этот интерфейс встречали, только он упакован в терминальное окно, и у него есть классные фишечки для того, чтобы разрабатывать проекты. Например, доступ к файловой системы. Он умеет запускать там команды, проекты, настраивать сервера. В общем, всё, что нам нужно. Но всё-таки, на мой взгляд, важно иметь какой-то графический интерфейс. Да, мы можем делать приложение из вот этого терминального окна, где у нас чат с клодом. Клод, если что, это продукт от компании Antropic. В нём используются модели от компании Antropic. Это модели Sonet, Opus и Хайку. Самая ходовая и, на мой взгляд, топовая модель - это Sonet. И я пользуюсь ей, ну, в 99% случаев. Оставшийся 1% я использую модель OPС, поскольку она более умная. Если задача прямо сверхсложная, я использую OPСus, но это уже детали. И, к слову сказать, во втором инструменте для вайп-кодинга, который я озвучил, а именно в курсоре, я также использую модель Sonet 4.5 от Антропика. И вообще, лично я, если бы выбирал инструмент, я в первую очередь смотрел на наличие этой модели. Не знаю, есть, конечно, другие хорошие модели, я с этим не спорю, но в моём топе самая первая модель - это Sunet 4,5 от Antropic. Вернёмся к нашим инструментам. Это было небольшое лирическое отступление промодели.
Клод-код и курсор. В случае с курсором это полноценный графический интерфейс. Ну, графическая привычная программа для редактирования кода. Ну, за исключением того, что там есть чат с нейронкой встроенный. Плюс недавно появился агентский режим, в котором на первый план выходит работа с иагентами, а просмотр кода он там вообще скрыт по умолчанию. Ну, то есть это такая тенденция. Сейчас мы всё больше и больше будем работать именно с и-агентами и в код смотреть, по всей видимости, всё реже и реже. Такие вот у нас тренды. Так вот, на мой взгляд, вам в любом случае нужна. IDE - это редактор кода вот простым языком. То есть даже если вы не будете редактировать руками код, вам всё равно какие-то файлы, возможно, понадобится редактировать, какую-то документацию, про которую мы чуть позже поговорим. В общем, писать какие-то файлы, заметки, может быть, текст просто поменять где-то. И для этого вам нужен какой-то редактор файла. Так вот, курсор - это два в одном. Ну, это де, то есть это редактор кода. Плюс он супер прокачанный в плане нейронок, то есть там есть чат с нейронкой. Шикарный инструмент. И чтобы разрабатывать проект через нейронки, он вам прекрасно подойдёт.
Лично я использую оба эти инструмента. Обычно я открываю курсор, работаю в нём. И также у меня в курсоре открыт терминал, в котором запущен клод-код. Я работаю, так сказать, с двух чатов. Пишу в курсор, пишу вдкод. Они немного разные программы. В принципе, я использую там одни и те же модели, но где-то удобнее использовать клод-код, где-то удобнее использовать курсор. Если вы абсолютно с нуля сейчас начинаете, то всё-таки я вам советую начинать с курсора. Вам будет привычнее, потому что там есть визуальный интерфейс. Ну и для начала понятно. Но плод-код тоже, посмотрите, очень крутая штука, и очень многие вайп-кодеры уважают этот инструмент.
И ещё одно важное отличие между курсором и клодкодом заключается в лимитах. Лимиты устроены следующим образом. Вы покупаете подписку, например, Pro за 20 баксов или какую-то подороже, и у вас есть лимиты. То есть вы можете исчерпать количество запросов, которое рассчитано было на месяц. Их достаточно много, реально много. Но при очень активной работе вы можете их исчерпать. Они у вас закончатся раньше, чем пройдёт месяц, и они у вас не обновятся, то дальше вы сможете пользоваться курсором за отдельную оплату. То есть вам нужно будет докидывать туда деньги и платить уже за использование. За каждый запрос у вас будет с баланса какая-то сумма списываться. Если вы купили подписку, ну, например, на год, то в начале следующего месяца, очевидно, лимиты у вас обновятся, и вы начнёте как бы с нуля.
В clдкод лимиты устроены иначе. Во-первых, вы можете использовать клод-код пописке клод. Это очень круто. Таже подписка 20 баксов. Но кроме самого клод-кода вы также можете использовать клод des дектоп, ну или в браузере пользоваться клодом. Если вы не знаете, что такое клод, то по сути это практически то же самое, что чат GPT. Только на мой взгляд ещё круче. Несколько месяцев назад я перешёл полностью с чата GPT на клод. Тут на вкус и цвет все фломастеры разные. Просто имейте в виду, что вы можете использовать одну подписку сразу для клодсктопа и для клод-кода.
В случае, если вы используете клод-код по подписке, то у вас будут пятичасовые лимиты, которые каждые 5 часов обновляются. Также будут недельные лимиты, которые обновляются каждую неделю. Ну и, естественно, месячные лимиты, которые обновляются каждый месяц. Плюс такой системы в том, что у вас не будет ситуации, когда вы потратили все лимиты и вам придётся ждать до конца месяца. Максимум, сколько вам придётся подождать до восстановления лимитов - это до конца недели. Это и хорошо, и плохо. По объёму лимитов, честно говоря, сравнить сложно, но если вы всё-таки в какой-то момент упрётесь в эти лимиты, значит, вы суперактивно используете инструмент. И, в принципе, вы можете просто купить подписку подороже. Кстати, по оптимизации контекста и как реже втыкаться в лимиты, я записывал отдельное видео, и как будете готовы, можете его посмотреть. Я думаю, вам будет очень полезным.
Давайте чуть-чуть подведём итоги этой секции. Если вы начинаете полностью с нуля вайп-кодить, берите курсор, не ошибётесь. Если вы уже более-менее продвинуты пользователей, вы можете посмотреть в сторону клод-кода и дополнить им, так сказать, курсор. Вы можете комбинировать две подписки за 20 баксов, пользоваться клодом, пользоваться курсором и внутри курсора в терминале пользоваться клодом. Классная связка, рекомендую. Мне нравится.
О'кей, с инструментами вроде как определились. Давайте двигаться дальше. Дальше нужно выбрать направление проекта, ну или тип проекта. В общем, какой проект вы хотите делать. На мой взгляд, сейчас самые актуальные направления - это веб-приложения, веб-сервисы, Саасы, это Softare a севиice, то есть софт по подписке, либо какие-то Telegram-боты, какие-то, может быть, другие боты. Telegram миниэпы, это вот приложение внутри Телеграма. Это всё очень классное сейчас направление. Есть вариант, конечно, делать нативные приложения на телефоны, но, честно говоря, к ним я такого благоговения не испытываю. Ну, в принципе, можно, если хотите, пожалуйста, флаг вам в руки. Всё реально.
После того, как вы определились с типом приложения, который вы хотите завайп-кодить, нужно определиться со стеком. Стектехнологии - это немножко технической информации, которую стоит сейчас вкинуть, но воспринимайте это просто как обзорный момент. Потом, если нужно будет, разберётесь. Основная рекомендация при выборе стекакотехнологий - это использовать один и тот же язык программирования для фронтэнда и для бэкэнда. По крайней мере, если вы вот именно трушный вайп-кодер, который хочет всё делать через нейронки, усложнять жизнь несколькими языками программирования лишний раз не стоит.
Фронтндом называется пользовательское приложение. Ну, по сути, это интерфейс. Это визуальный интерфейс там сайтов или приложений. Вот эти все кнопочки. Это вот frontend. Backend - это сервер, который обрабатывает запросы, сохраняет данные в базу данных, достаёт из базы данных, делает какие-то запросы к нейронкам или делает какие-то другие запросы, что-то анализирует. В общем, это вот, то есть код, который запускается на сервере.
Если вы делаете сайт веб-приложение, веб-сервис Telegram Mini App, который по сути является под капотом теми же сайтами, то выбор тут небольшой. Вам нужно использовать Typeescript. И даже если бы вы нейронки об этом ничего не писали, скорее всего, она бы это и предложила. Для комплексной разработки серверной и клиентской части есть классный фреймворк, который называется Т3Sстек. В нём сразу настроена базовая связка между бэкэндом, фронт-тендом, и начать на нём разрабатывать будет проще.
Если у вас серверное приложение, например, Telegram боot без графического интерфейса, здесь можно выбрать Python. Питон тоже очень популярный язык. На нём прекрасно пишутся Telegramботы, хотя на Тайпскрипте тоже можно писать ботов, так что не парьтесь, если что, из-за этого. Typeesриpt супер универсальный язык, на нём можно писать практически всё. Поэтому, если что, можете выбирать Typeesриpt практически для любых своих задач. По поводу питона есть классный фреймворк, называется Джанга. Он классный тем, что у него из-под капота есть админка, и вы можете графически, удобно, визуально смотреть на состояние базы данных, управлять данными, и это достаточно удобно. В принципе, с ним работать классно, комфортно, и нейронки хорошо работают с этим фрейворком. Поэтому, если вы делаете чисто серверное приложение, ну, Telegramбот, например, да, у которых нет интерфейса, то Python вместе с Jang хороший вариант.
По поводу нативных приложений можно использовать React Native. Он удобен тем, что с помощью него можно сразу делать приложение как на iOS, так и на Android. Вам не нужно будет делать два разных приложения под две операционные системы. Поэтому React Native, в принципе, классная штука. Можете его использовать.
Это был раздел с такой технической документацией. Если вы ничего не поняли, то ничего страшного. Это нормально. Просто имейте в виду, что эти названия можно загнать в нейронку, чтобы она понимала, на основе чего создавать вам приложение. И таким образом мы плавно переходим к следующему разделу, а именно создание документации.
Это чуть ли не самое важное в процессе вайп-кодинга какого-то приложения. На документацию нужно обязательно уделить должное внимание, поскольку это критически важный этап. Перед началом, непосредственно самой разработки, нам нужно детально описать приложение, описать функционал, описать, как оно должно выглядеть, какие экраны там будут, если там будет графический интерфейс или какие функции, какие кнопочки, какие команды. В общем, описать всёвсёвсёвсёвсё полное техническое задание, то есть описать полное ТЗ для нейрон. Представьте, что вы пишете техническое задание для программиста, которого вы наняли. Чем точнее вы опишите ему желаемый результат, тем лучше, соответственно, он его сделает, и это будет похоже на то, что вы действительно от него ожидали.
Про документацию у меня есть два видео. Одно обзорное, в котором я рассказываю, что вообще стоит включать в документацию. И второе видео - это где я в реальном времени, собственно, создаю эту документацию, чтобы вы могли посмотреть на процесс написания этой документации. Документацию можно писать также с нейронками, но её желательно просматривать самостоятельно и если что исправлять. В документации не должно быть каких-то сверхсложных кодов. Там должно быть простым языком описано то, что вы хотите от приложения. Ну, в первую очередь, да, там могут быть какие-то примеры кода или структуры данных, которые там нейронкой можно также сгенерить в этой документации. Не проблема, всё о'кей. Но самое главное - это описать то, как вы видите своё приложение. И это не стоит полностью делегировать неронки. Всё-таки имеет смысл смотреть на файлы, которые вы генерируете с нейронкой. Да, их можно базово сгенерировать, потом вы по ним пробегаетесь и смотрите, что всё корректно.
Документацию лучше всего писать в Mark. Margдаун - это формат разметки. То есть в нём можно указать заголовки, выделение текста жирным курсивом, списки какие-то разделения по секциям. Это достаточно удобно и нейронки хорошо с ним работают. Плюс можно также на превьюхе смотреть, как это выглядит в каком-то приятном для вас виде.
Кроме текстового описания вашего приложения, в котором вы расписываете, как вы его видите, имеет смысл создавать аски визуализацию. То есть это символьная визуализация в текстовом файле экранов вашего приложения. Ну или не только экранов. По сути, это диаграммы в текстовом виде. И с ними нейрон тоже классно справляется. Их можно нейронкой также и редактировать. Вообще не рекомендую редактировать это руками. Эти диаграммки лучше и создавать через нейронку и редачить. Удобно то, что это всё в тексте, легко редактируемое, везде открывается и нейронки достаточно хорошо работают с такими диаграммами.
Переходим к следующему этапу. создание. Следующим шагом нужно создать Roadmap, то есть план реализации этого проекта. Roadmap делается точно так же с нейронкой. Загоняете и и агенту свою документацию и говорите создай мне roadmap по разработке этого проекта. Нейронка генерит вам Roadmap. При этом, как лучше это сделать? Лучше создать один файл, в котором будут все этапы с кратким описанием, и в каждом этапе приложить ссылку на отдельный Markу файл, в котором подробно описана задача по реализации этого этапа. Не обязательно создавать только один файл для описания этапа. Можно создать несколько, если информации много. Но суть в том, чтобы был один какой-то файл, в котором описан полностью путь от нуля до релиза. и в нём будут ссылки на подробное описание задач. Вот это классный подход. Делается это точно так же с неронкой. Просто просите её создать Radmap и сделать отдельные файлы под каждый этап или каждую задачу.
После того, как у нас будет готов ROADMap, можно переходить к следующему этапу, а именно к разработке. Когда у нас есть Roadmap на руках, процесс разработки с Eи агентами становится крайне простой. Всё сводится к тому, что вы кидаете в контекст к и агенту свой roadmap и просите его выполнить определённый этап, ну, начиная с первого и так далее. Если в процессе разработки у вас появились дополнительные требования, которые связаны с какими-то уже описанными задачами, то лучше их подкорректировать, то есть подкорректировать файлы документации. И если вы уже реализовали какой-то этап и потом скорректировали документацию, то попросите и и агента обновить существующий код с учётом новой документации.
Если вдруг в процессе разработки у вас появляются какие-то новые задачи, которые вы ещё не описывали в своём родмапе и в документации, то для них лучше создать отдельные файлы. По аналогии с родмапом и документацией, которую мы писали до этого, можем попросить и и агента написать техническое задание по задаче, описать, что мы хотим в этой задаче сделать, и и агент скомпонует это всё в нормальный вид и создаст новый файл для этой задачи. После этого в нужный момент, когда вы решите необходимым реализовать эту задачу, вы можете кинуть этот файл в контекст и и агенту и попросить его сделать эту задачу. Какие-то мелкие задачи можно, конечно, файлы и не выделять, просто просить и агента сделать какое-то небольшое нововведение или поменять что-то в уже существующем проекте. Однако, если задача достаточно объёмная, то создание отдельного файла поможет вам вернуться к этой задаче. Если в контексте одного чата вы не успеете полностью её реализовать, контекст одного чата с нейронкой ограничен. То есть в какой-то момент вы просто упираетесь в контекстное окно и дальше неронка начинает забывать то, о чём вы с ней говорили, начинает галлюцинировать. И, соответственно, отдельные файлы, в которых описаны задачи или прогресс, в частности, может быть, тоже описан в отдельных файлах по задачам, помогает сохранить вот этот общий контекст того, что сделано, что нужно сделать. И вы без труда можете переключаться между чатами с и агентами, можете переключаться из клодкода в курсор или какие-то другие инструменты. И вам не придётся каждый раз заново описывать своё техническое задание, когда вы просите нейронку что-то реализовать.
В процессе разработки проекта вам, скорее всего, понадобится гит. Что это такое? Простыми словами, это как облачное хранилище для вашего кода. Ну, что-то типа Google Драйва или Яндексдиска. Ну, только для кода. ГиIT, в отличие от обычного облачного хранилища, имеет дополнительные функции. В частности, он сохраняет всю историю изменений файлов, и вы сможете откатиться к нужной версии, если вдруг у вас что-то сломается. Кроме того, нейронки также умеют работать с гитом, и вы можете просить нейронку посмотреть, что там было исправлено или какие изменения были внесены, что сломало ту или иную функцию. В общем, это достаточно удобно, и это очень простое описание гита. На самом деле функций там достаточно больше, но если в двух словах, то это как машина времени для вашего кода, и вы можете откатываться на нужный этап, когда вам этого захочется. По гиту у меня есть подробный гайд, как использовать гиit для вайб-кодинга. И если вдруг вы захотите подробнее с ним разобраться, как применять его в своём вайп-кодерском процессе, то советую посмотреть. Я постарался там объяснить простыми словами, как пользоваться гитом для вайп-кодинга.
Важный момент - это безопасность и аудит кода. Нужно помнить, что ИИ не всегда генерирует идеальный код. Иногда он может забывать про технику безопасности, не учитывать какие-то моменты. За счёт этого у вас в проекте могут быть уязвимости. Например, если ИИ не сделал защиту от SQL-инъекции, то злоумышленники могут получить доступ к вашей базе данных, например, через форму авторизации или как-то ещё. Очевидно, что нам этого не хочется. И нужно держать в голове, что ИИ может написать рабочий, но уязвимый код. Что я могу посоветовать на таком, ну, базовом, примитивном уровне? Ну, во-первых, вы можете погонять своего ИИ-агента, чтобы он поискал эти уязвимости. Ну, это самое, наверное, простое, что можно сделать. Во-вторых, конечно, стоит упомянуть об этом в своей документации, что обязательно нужно сделать проверку на уязвимости вашего кода. И в принципе, если погонять иишку по всем разделам, по всем секциям, по всем функциям, то она может выявить многие штуки, о которых в процессе почему-то не задумалась, и пофиксить это. Это прямо совсем базовая штука, но она на самом деле достаточно эффективная, и это стоит сделать.
Затем стоит тестировать вручную то, что написала Иишка. По крайней мере, то, что вы можете сделать. То есть, например, проверить корректность валидации, проверить, что будет, если вы указываете какие-то неправильные суммы или значения, то есть потестировать приложение и попробовать вести себя так, как вы, ну, не предполагаете, что пользователь будет себя вести. Какие-то критические значения повставлять, попробовать какие-то подобрать там, не знаю, пароли, написать неверный пароль, в конце концов, потому что если вдруг с неверным паролем вас впустят в аккаунт, ну, это явно уязвимость и так далее. То есть попробовать максимально неестественное для обычного пользователя поведение, попробовать, насколько вы понимаете, самостоятельно взломать приложение или хотя бы просто сломать его. По безопасности я планирую снять отдельное подробное видео. Если вам интересна эта тема и вы не хотите, чтобы вас легко взломали, то можете подписаться на YouTube или Telegram-канал Годный Вайбкодинг, и вы оперативно узнаете, когда выйдет это видео. Кроме того, можете погуглить, почитать статьи, поискать видео на эту тему, в принципе, чтобы закрыть хотя бы базовое понимание о том, как могут взламываться приложения.
Следующий важный момент в процессе разработки - это тестирование. После каждого завершённого этапа разработки, ну, поадмапу или после каждой новой сделанной задачи, нужно открыть приложение, протестировать нововведение, чтобы быть уверенным, что они работают корректно. Частично это можно автоматизировать с помощью нейронок. Есть различные MCP, то есть как дополнительные плагины или расширения для нейрона, которые позволяют им открывать браузер, нажимать кнопки самостоятельно тестировать все процессы. Но ручное тестирование всё равно никто не отменял. Попробовать попользоваться своим приложением вам в любом случае будет нужно, и желательно проверять каждый сделанный нейронкой этап.
Следующий момент, который вам, скорее всего, нужно знать - это база данных. Если предполагается, что ваше приложение будет хранить какие-то данные, хотя бы информацию о пользователях, то вам нужна база данных, в которой это всё будет храниться. Базу данных можно очень упрощённо воспринимать как Google таблицы, Excel, ну вот что-то такое, да, то есть табличка с данными, но, конечно, база данных отличается от таблиц. Это не одно и то же, но для супер упрощённого понимания можно провести такую аналогию. Для базы данных я советую использовать вам отдельный сервер. В процессе разработки это, конечно, не обязательно, но когда вы будете публиковать проект, лучше запускать базу данных на отдельном сервере специальном, чтобы на нём крутилась база данных. Такие специальные сервера, на которых прямо из коробки крутится база данных, есть у Яндекса, Амазона, Time Webcoud. И это, конечно, не полный список, но, в принципе, можно выбрать какой-то из этих, либо поискать то, что вам по какой-то причине больше понравится. Суть в чём? Вы арендуете сервер, на котором сразу крутится база данных. Вы прокидываете данные для доступа к этой базе данных в
свой проект, и ваше приложение или сервис сохраняет в эту базу данных информацию, которая используется дальше в работе вашего приложения. Сейчас речь шла про сервер, но в качестве базы данных, это как вот как язык программирования, только тип базы данных, можно это так сказать. Я рекомендую использовать Postgress QL. Если по какой-то причине вам нужно что-то другое, то, скорее всего, вы и так сами понимаете, почему, зачем и что вам нужно. Поэтому тут уже разберётесь сами.
Если вдруг вы пишете проект не для себя, а хотите, чтобы за него платили пользователи, за его использование, вам нужно будет подключить платёжную систему для РФ. Из таких как бы основных, которые я знаю, можно использовать Юкаasса или Робокасса. Они вроде обе принимают и российские, и зарубежные карты. Ну, Робокасса точно, Юкаса вроде тоже, но там, по-моему, какие-то дополнительные требования есть. Но не знаю, надо посмотреть. У них, в принципе, русским языком написано, что они принимают и на каких условиях, поэтому можете просто посмотреть эти два сервиса и выбрать тот, который вам больше понадобится.
У обоих этих сервисов есть документация по подключению кассы в ваш проект. Вы просто смотрите эту документацию, можете прямо ссылку в нейронку кинуть и попросить её подключить вам проект. Вам же нужно будет настроить только сам магазин в этой кассе. Это всё делается, в принципе, несложно. Есть инструкции на обоих этих сервисах. И вам нужно будет также взять оттуда как бы апи ключи для доступа к приёму платежей через ваше приложение и номер там магазина. Ну, плюс-минус, да, прокинуть это всё в ваш проект. Опять же, неронка по документации сможет с этим тоже разобраться. Вам же нужно будет обязательно это всё протестировать. И в принципе вы можете принимать платежи, сохранять вот эти оплаченные там подписки в базе данных, и у вас будут платные пользователи, которые будут приносить вам деньги за удобный и полезный проект.
Правда, с кассой есть один нюанс, с которым вы можете столкнуться. Если вы разрабатываете проект вот на этом этапе всё ещё на своём компьютере, никуда его не загружали, то чтобы получить от кассы сообщение о том, что платёж получен, вам не подойдёт локальный сервер. Ну, то есть проект локальный, который вы у себя на компе запускаете. Вам нужно будет опубликовать свой проект, так сказать, зарелизить его, чтобы получать эту информацию о приёме платежей, ну и, соответственно, сохранять это в базу данных.
И мы как раз переходим к следующему. И, наверное, последнему этапу - это релиз проекта. Когда у вас проект уже работает и вас это вполне устраивает, наступает, да, этап релиза проекта. Тема достаточно большая, в двух словах так не сказать. Про неё будет отдельное видео на канале, но всё-таки как-то вас направить нужно. Поэтому сейчас постараюсь как-то кратко, обзорно рассказать, на что вообще смотреть, на что обратить внимание.
По большому счёту, есть два способа. Первый - это аренда облачного сервера. По сути, вы арендуете голый сервер, и вам нужно будет его самостоятельно настраивать. Способ достаточно сложный, особенно если вы никогда с этим не сталкивались. Вам придётся с нуля со всем этим разбираться. Это можно сделать с нейронкой, то есть спрашивать у неё, как и что настроить, но процесс достаточно трудоёмкий. Но для начинающих людей, кто не сталкивался с настройкой сервера, это может быть сложно для восприятия. Это, конечно, реально, и я про это как-нибудь отдельно расскажу обязательно. Но пока что давайте остановимся на втором способе.
Это использование специального сервера для деплоя. Деплом называется загрузка вашего проекта на сервер. Ну, если по-простому. А специальные сервера для деплоя делают это автоматически, и вам практически ничего не нужно настраивать. Вы можете просто подключить свой Git репозиторий к этому серверу. И каждый раз, когда вы будете загружать новый код в Git, этот сервер автоматически будет подкачивать изменения и обновлять проект на сервере. Это очень удобно, особенно если вы в этом не разбираетесь. Такие сервера есть у Яндекса, TimeW, Cloud, есть сервис Versil, но он из России недоступен. Ну, точнее, сайты, которые там публикуются, они недоступны из России. В общем, с этим могут быть проблемы. Поэтому обращайте внимание на регион, для которого вы делаете свой сервис. Если это Россия, то Яндекс или Time Web Cloud. В принципе, там есть специальные сервера. У Яндекса - это Cloud Apps, у Time Webcloud называется App Platform. В общем, можете использовать один из них.
Следующий момент, который нужно понимать, если вы делаете какой-то веб-сервис, может быть, сайт или веб-приложение, и вы хотите, чтобы оно было доступно в браузере по какому-то имени, вам это имя нужно купить, скорее арендовать, потому что вы его оплачиваете на какое-то время. Ну не суть. Это имя называется домен. Ну, например, Google.com домен или Yandex.ru - это домен. И вам нужно какой-то ваше приложение.com, например, да, вам нужно купить этот домен. Для этого используются специальные регистраторы этих доменов, например, regruру или тот же TimeW Cloud. В принципе, не так важно, у какого регистратора вы будете покупать домен, потому что все они, в общем-то, подключаются нормально к ко всем серверам. Но тут нужно иметь в виду, что у разных регистраторов может быть разный набор доступных доменных зон. Ну, такие классические доменные зоны, как или скорее всего, будут доступны практически везде. Ну, а если говорить про что-то более изысканное, например, то AI или точка app, они могут где-то отсутствовать, поэтому имейте это в виду.
После покупки домена его нужно будет подключить к вашему серверу. Делается это несложно. Обычно на всех серверах и на всех сервисах есть инструкция по подключению доменов. В двух словах, вам нужно будет просто прописать айпишники своего сервера в настройках домена, чтобы он ссылался на ваш сервер. После прописание этих айпишников иногда нужно подождать какое-то время, там должны обновиться DNS-сервера. Это может занять там, ну, полчаса, час, когда как. Обычно за это время сервера уже обновляются, и после этого ваш домен будет перенаправлять пользователя на ваш сервер.
Ещё один важный момент, который относится, в общем-то, и к разработке, ну, и к релизу тоже. Ну, то есть это мониторинг и обработка ошибок. Это нормальная ситуация, когда вы выкатываете свой продукт, вы вроде его протестировали, вроде бы всё работает, потом туда заходят пользователи, и вдруг внезапно возникают какие-то ошибки, которые вы вообще не предвидели, вы о них не думали, но вот они есть. Их, по-хорошему, нужно как-то мониторить, куда-то логировать, записывать, чтобы потом их пофиксить, то есть исправить. Самое простое, что можно здесь сделать - это попросить нейронку логировать все ошибки куда-то файлы, чтобы вы их могли потом посмотреть, либо создать отдельную таблицу в базе данных. Тоже через нейронку можно это сделать, чтобы туда логировались все ошибки и вы могли потом их проанализировать. Например, ошибка оплаты или регистрации или ещё что-то, плюс какие-то данные с кодом ошибки, который вы потом можете скормить нейронки, чтобы она исправила эту ошибку.
Следующая важная подтема раздела релиза проекта - это докеer. Если у вас в приложении используется фнт-end иэнд, то фактически это одновременно два работающие сервера, а иногда даже больше. Но трудности возникают, когда вы начинаете загружать своё приложение на вот этот специальный сервер для деплоя. В некоторых серверах для деплоя, ну, может даже во всех, не знаю, некоторые сервера для деплоя не запускают два сервера параллельно. То есть вам нужно либо как-то разделять это на два приложения, чтобы арендовать два разных сервера для бэкэнда и для фронт-тенда, но это не всегда удобно. Вы можете упаковать свои frontend и бэкэнд сервер в один контейнер докера. Депло сервер будет запускать вот этот контейнер, в котором уже будут запускаться два сервера. И вот такая схема вполне рабочая, это нормальная практика, но да, для этого нужно упаковать их как бы вот в нечто единое. Для этого используется докер. Вы можете про него погуглить, на самом деле. Ну, прямо детально с ним разбираться может быть и нет необходимости. Тема, конечно, интересная, но сложная. То есть, если мы рассматриваем эту тему с точки зрения там трушных вайбкодеров, которые вообще в код не лезут, ну, блин, тяжеловато. Но, по крайней мере, вы можете попросить Нейронку упаковать в докер ваши сервера, чтобы они все запускались там в одной командой докера. И после этого ваш деплой сервер уже сможет запускать ваши сервера вот одной командой, и всё будет о'кей.
Вот вы сделали проект, вы его упаковали, вы его задеплоили, всё работает, домен подключен, база данных крутится, оплаты принимаются, кайф. Не жизнь, а сказка. Но в какой-то момент что-то может пойти не так. Это вообще часто непредсказуемая штука. Сервак вдруг могут ломануть или вдруг что-то пойдёт не так, сломается или что-то ещё. В общем, разные случаи бывают. Чтобы избежать каких-то критичных последствий, нужно делать бэкапы. то есть резервные копии. И в нашем случае, где у нас отдельный сервер специальный для базы данных, на котором крутится база данных, отдельный сервер для нашего приложения с автоматическим деплоем, обычно на этих серверах можно прямо в настройках, в панели управления настроить автоматические бэкапы. И это обязательно нужно сделать. И чем чаще, тем лучше. Ну, хотя бы раз в неделю. И ещё, как только у вас проект вообще заработал, запустился и вы сказали: "Всё круто работает", тоже стоит сделать бкап. То есть да, у вас есть код вашего проекта в гите, то есть вот в этом обке. Круто. Но база данных у вас только на сервере, для неё точно надо делать бкап. Если говорить про сам сервер, допустим, на нём вот автоматический деплой, да, он просто берёт код из гита, загружает его, запускает и всё работает. Все данные хранятся в базе данных. В принципе, ну, не так критично, потому что это всё восстанавливается из гита. Но вот с базой данных прямо очень важно. Обязательно настройте автоматические бэкапы.
В общем-то, на этом всё. Да, информации здесь было много, и некоторые аспекты мы не разобрали детально. По некоторым из пунктов уже есть видосы. По другим я планирую их записать. Если вам нужно срочно сейчас разобраться, поищите в интернете. Информация есть. Самое главное, что вы поняли путь от нуля до релиза, и вы понимаете, какую информацию вам вообще нужно искать. Что вы понимаете, что вы не понимаете. Вот там, где не понимаете, как раз надо искать. Спрашивайте нейронку, гуглите, ищите видосы. В общем, ищите, разбирайтесь, и всё у вас получится. Главное, что у вас есть план развития, и вы понимаете, как с нуля дойти до релиза.
В одиночку проходить такой путь с нуля достаточно сложно. Поэтому, если вам нужна какая-то поддержка и общение с единомышленниками, то приглашаю вас в наш вайбкодерский чат в Telegram. В нём можно пообщаться с другими вайб-кодерами, позадавать вопросы, поотвечать ответы. Иногда там даже какие-то предложения по проектам или вакансии появляются. В общем, подключайтесь к нашему вайпкодерскому комьюнити. Ссылки на все упомянутые видео я оставлю в описании. И когда появятся новые видео, я буду это описание обновлять. Поэтому, возможно, там появилось что-то ещё, кроме уже упомянутых видео.
Если вдруг в процессе вашей вайпкодерской деятельности у вас возникают сложности и вам нужна помощь, нужно с кем-то проконсультироваться, то можете написать мне в личку. У меня есть формат консультации. Это обсуждается в индивидуальном порядке. Ну а на какие-то простые вопросы я стараюсь по возможности отвечать, как у меня появляется свободное время. А на этом я с вами прощаюсь. Всем успешных проектов Годного кода и до скорых встреч.