Из чего состоит нормальный IT проект

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

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

Проблемы кроются в безопасности, нарушениях законодательства при хранении данных, отсутствии системы контроля версий, резервных копий и процессах доставки кода в "боевую" среду.

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

Гайд для вайбкодеров: что должно быть в проекте

Начнем с основ.

Git или система контроля версий

В любом нормальном проекте, который зарабатывает деньги, есть Git. Эта штука хранит всю историю проекта: первые никому уже не понятные строчки кода из далекого 2007-го и вчерашние исправления в интеграции с Битрикс24.

Когда начинаете проект, в первую очередь установите на компьютер Git и инициализируйте репозиторий. Дальше выберите сервис, который будет хранить этот репозиторий. Это может быть GitHub, GitLab, Bitbucket и другие сервисы. Что-то из них бесплатное, что-то платное, выбирайте сердцем и душой.

CI/CD или процессы доставки кода

Раскрою секрет, но разработчики руками сами не обновляют код на боевом сервере, обычно у них есть CI/CD.

Например, есть репозиторий GitLab, там есть две ветки (разные состояния проекта): main и test. Все изменения попадают в test. После того как тестировщик все проверил, он мержит (делает слияние) две ветки. И в этот момент на сервере где-то крутится какой-нибудь инструмент типа GitLab Runner, который видит новые изменения в ветке main, подхватывает их и совершает сборку проекта с новыми исходниками.

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

Резервные копии

Никогда не храните единственный экземпляр приложения на своем компьютере.

Первое, что у Вас должно быть – это копия кода. Для этого есть Git.

Второе, если проект уже лежит где-то на "проде" и приносит деньги, у него должны быть резервные копии (далее бэкапы). Бэкапы создаются из актуальных данных, желательно один раз в день минимум, а лучше два. Сам бэкап должен храниться вообще в другом месте, на втором сервере. Чтобы в случае чего был шанс на восстановление.

Законодательство

Это очень сложная тема, поэтому кратко и с примерами.

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

Например, персональные данные можно шифровать с помощью AES-256 или других надежных алгоритмов. Сам GDPR – General Data Protection Regulation – не предписывает конкретный алгоритм. Документы в открытом доступе, можете ознакомиться сами.

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

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

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

Безопасность

А эта часть еще комплекснее, чем предыдущая.

На безопасность многие крупные компании тратят миллионы денег. А хакерство – целое искусство.

Человек без опыта в IT-сфере делает кучу тупых ошибок: оставляет SSH-порты открытыми для любых подключений, не закрывает порты к базе данных, не думает о нагрузке, а также забывает про человеческий фактор – слабые пароли, скидывает API-ключи в нейронку.

Тут наша команда может посоветовать только одно: проведите независимый аудит безопасности. Если нет денег нанять людей, то хотя бы проведите два-три цикла аудита проекта разными нейросетями. Запустите DeepSeek Flash, потом ChatGPT Astra, а после добейте Claude Fable. Вы не исправите все, скорее всего, нейронки даже будут латать проблемы, которых нет и которые сами выдумали, но часть очевидных проблем они помогут найти. Кроме доступа к SSH, про это помните сами – сделайте вход на сервер по ключам, а не по паролю.

Качество кода

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

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

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

Итого

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