Почему мой сайт не падает, хотя я собрал его вайбкодом

Дисклеймер. Эта статья — высокоуровневая. Если вы пришли сюда учиться, то с непривычки её начало может показаться сложным, и это нормально — она не про "как что-то сделать", она про "как я думаю, когда работаю с кодом". Я пишу её честно ради одной вещи: показать, что я не хер с горы. Когда меня спрашивают "а ты-то сам что умеешь?" — я хочу иметь возможность дать ссылку и сказать: вот это умею. Технические термины я по ходу объясняю в скобках, как будто читателю пять лет.

Вайбкод (это когда ты не пишешь код руками, а наговариваешь нейросети, что хочешь, и она пишет за тебя) имеет дурную репутацию. И заслуженно: так и правда можно за вечер собрать красивую штуку, которая развалится от первого же чиха. Мой сайт собран вайбкодом — и последние десятки обновлений ничего не уронили. Расскажу почему.

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

Сначала я построил сайт, чтобы его выкинуть

Первое, что я сделал, — собрал прототип (черновую версию, которую заведомо не жалко). На это ушло часа два. Работало криво-косо, и это меня вообще не смущало — я с самого начала знал, что буду это убивать. Смысл был не в том, чтобы получить рабочий сайт. Смысл в том, чтобы своими глазами увидеть всё, что в него на самом деле входит: какие куски, как они связаны, что я вообще хочу.

Раньше для такого делали просто документы — расписать на словах, что должно быть. Сейчас быстрее накидать прототип и посмотреть, как оно ведёт себя вживую. Два часа — и у меня в голове полная картина объёма.

Потом я выбрал архитектуру под то, что увидел

Когда я увидел весь объём, я не кинулся сразу строить начисто. Я сказал нейросети примерно так: смотри, будет вот такая система. Её придётся долго поддерживать. Будут обновления, будут штуки, которые надо то подключить, то отключить. Подскажи мне оптимальную архитектуру (это как план дома: где несущие стены, где можно двигать перегородки) именно под это — не под "сделать сейчас", а под "жить с этим долго".

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

Дальше — правила для самого тупого разработчика

Когда архитектура была выбрана, я попросил собрать гайдлайн — свод правил разработки. Формулировка была буквально такая: представь, что ты пишешь инструкцию для максимально тупого разработчика. Чтобы он каждый раз перед тем, как написать строчку кода, шёл, смотрел правила — и не мог их нарушить.

Так появился набор правил: как устроен дизайн, как ведётся разработка, что можно, чего нельзя. Отдельно я попросил две вещи: плотно покрывать всё комментариями (пояснениями прямо в коде, зачем тут что) и плотно покрывать всё автотестами (это маленькие программы-проверки, которые сами прогоняют сайт и кричат, если что-то сломалось).

И самое важное — что мы делаем, когда что-то всё-таки ломается

Тут ядро всей системы. Если падение всё же случилось — что-то старое сломалось от чего-то нового, или новое делается долго и криво, — я не просто это чиню. Откатить назад (вернуть всё к рабочей версии) я всегда могу, это не фокус.

Фокус в другом. Каждую проблему я разбираю: как именно она появилась. Подключаюсь ко всему коду, логирую (записываю по шагам, что происходило), нахожу причину. А дальше — главный вопрос: почему действующие правила её не поймали? Почему она вообще смогла произойти?

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

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

Как изменения доезжают до живого сайта

Последний слой — дисциплина выкатки. У меня есть ветки разработки (отдельные «черновые дорожки», где изменения живут, пока не доказали, что годятся).

Путь такой: сначала из черновой ветки я качу изменение на stage (это копия сайта для проверки, на которой не страшно сломать — настоящие посетители её не видят). На сайте так проверить можно почти всё. Глазами смотрю прямо на ветке, что изменение ничего не ломает. Если правка совсем простая — например, просто добавил новое поле в базу данных, — могу положиться на автотесты и не вглядываться.

На stage я всегда убеждаюсь, что работает. И только потом — merge в main (объединение в главную версию, ту самую, что видят люди). В main я качу реже, чем на stage: там накапливается по несколько проверенных обновлений сразу, а не каждая правка по отдельности.

(Честности ради: с ботом так гладко пока не выходит — там история работает чуть иначе и часть проверок на stage не сделать. Надо будет завести себе второго бота под это. Но это уже мелочь на фоне общей схемы.)

Что из этого следует

Вайбкод сам по себе не делает сайт ни хрупким, ни прочным. Хрупким его делает то, что человек останавливается на «оно заработало». А прочным — то, что ты обращаешься с ним как с системой, которую тебе ещё жить и поддерживать: сначала понимаешь объём, потом выбираешь фундамент, потом обкладываешь правилами и проверками, а каждое падение превращаешь в новое правило.

Я не пишу код руками. Но я знаю, как им управлять так, чтобы он держался. Вот это, собственно, и умею.