Привет, Хабр! Меня зовут Семён, я разработчик приложений в экосистеме ИТ-продуктов «Лукоморье». До этого я работал дежурным инженером у телеком-оператора: принимал звонки, регистрировал аварии и раскладывал их по пяти Excel-таблицам. В плохие дни через двух операторов проходило до сотни инцидентов, а раз в месяц кто-то тратил полдня, чтобы собрать из этого зоопарка один отчёт для руководства.

Я захотел облегчить жизнь себе и коллегам и решил собрать приложение, которое снимет этот хаос: два месяца по вечерам учил Django, разбирался с миграциями и собирал интерфейс с нуля методом проб и ошибок. До минимально рабочего состояния проект я довёл, но работы оставалось ещё много.

Потом я сменил работу, а задача меня догнала: уже в «Лукоморье» мне прилетело ТЗ на похожую учётную систему, только для диспетчерской службы из другого региона. На этот раз я собрал работающую систему за неделю, не написав ни строчки кода.

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

Проект первый: как я не дописал систему

Работая оператором, я видел проблему изнутри: учёт инцидентов вёлся в Excel-таблицах плюс бумажный журнал. В конце смены данные передавались следующей смене и докладывались руководителю. Я решил упростить эту рутину и написать своё приложение. Друг посоветовал Django — с него и начал. Это была личная инициатива: руководство смотрело скептически, менять что-то у нас было не принято.

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

Работа заняла несколько месяцев в свободное от основной работы время. Я настраивал миграции, писал SQL-запросы, собирал интерфейс, изучая фреймворк параллельно с работой. В какой-то момент честно признал: до минимально рабочего состояния приложение я довёл, но чтобы отдать его людям на смены, нужно было потратить ещё столько же времени. А его у меня не было, поэтому проект остался незавершённым.

Проект второй: подход с новым инструментом

Из телекома я ушёл в «Лукоморье». Один из продуктов в экосистеме компании — «Акола»: no-code-платформа, где приложения собираются визуальными инструментами. «Акола» — мой рабочий инструмент, и эта статья не про то, что лучше или хуже. Это скорее рассказ о том, как выглядит разработка на no-code изнутри, с оглядкой на мой небольшой опыт классической разработки.

Спустя несколько месяцев в рабочий чат прислали новый проект: система учёта инцидентов. Заказчик — Единая дежурно-диспетчерская служба, которая собирает данные по всему региону. В ТЗ: таблицы, фильтры, загрузка Excel, дашборды.

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

Дизайн к этому проекту решили делать не как классический макет, а с помощью нового ИИ-инструмента в Figma. Такой подход позволяет наглядно увидеть, каким должен быть продукт, заложить паттерны поведения, показать в целом визуал страниц. Но быстро вскрылась основная проблема такого подхода — ИИ никому не обещал придерживаться единых паттернов стилей, из-за чего однотипные элементы могли быть с разными отступами, размерами, шрифтами и прочее. Нашлись скроллбары там, где их быть не должно, и не нашлись там, где они были нужны. Думаю, что это недоработки промпта, и если посидеть чуть дольше, объясняя ИИ все нюансы, макет был бы целостнее. Но есть как есть, и эта «проба пера» в будущем добавила мне работы.

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

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

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

Процесс разработки

Шаг 1. Создание и настройка БД

Вне зависимости от инструмента любая разработка начинается с проектирования БД. Сбор информации и анализ того, что будет лежать в таблицах, сделал аналитик, но продумывать объём и связи в БД нужно мне. Так как проект небольшой, у меня получилось 15 таблиц. Чисто механически создание БД свелось к выбору типов полей и паре настроек: всё выбирается из списка и легко считывается визуально.

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

Визуально оценить структуру можно тут же, в соседней вкладке:

Шаг 2. Создание интерфейса оператора

Следующий этап — создание пользовательских интерфейсов, и для меня это самая приятная часть работы. Одна из особенностей no-code-платформы — конструктор макетов — страницы собираются из заранее созданных компонентов. Таким образом собираем основу страницы: хедер, тело и футер, далее собираем внутри аккордеона фильтр, добавляем кнопки и таблицу. Преднастроенный компонент таблицы тянет из БД поля и отображает их содержимое, которое позже ещё нужно будет добавить для тестов, мне для настройки нужно выбрать только какие поля отображать.

Далее компоненты нужно привести к визуалу макета. Тут вспоминаем о том, что макет — это ИИ-прототип, и занимаемся пиксель-хантингом, частично поправляя то, что нарисовала нейросеть.

Шаг 3. Загрузка данных из Excel

Следующий этап — самая объёмная часть работы. Основным требованием заказчика была обратная совместимость с Excel-таблицами: то есть мне нужно было сделать возможность подгружать файл с данными, которые соберутся в мои таблицы. Кроме таблиц с инцидентами, у заказчика есть справочники: районы, адреса, причины, ответственные. Эти данные также нужно подгружать из файлов.

В «Аколе» есть Алгоритмизатор — блочный визуальный конструктор, где логика собирается как цепочка блоков. С помощью этого инструмента собираем парсер для файлов. Базово парсинг Excel-файла выглядит несложно:

1. Взять файл.

2. Прочитать столбцы.

3. Форматировать данные: обрезать пробелы, привести к одному регистру.

4. Проверить, есть ли запись в БД.

5. Если нет — создать.

6. Если есть — обновить.

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

Вариант дать заказчику шаблон для данных не рассматривался. Да и на практике человек всё равно может сломать заданное форматирование. Вокруг моего алгоритма платформа делает обработку базовых ошибок: если файл пустой или не того формата, система сообщает об этом.

Шаг 4. Дашборды для руководителя

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

На Django ради этого пришлось бы писать SQL с группировкой и агрегацией, поднимать API-эндпоинты под каждый виджет, верстать графики на фронтенде и настраивать кеширование. Это минимум день работы. Здесь ушло два часа: выбрал готовые диаграммы и указал, какие данные в них показывать.

Шаг 5. Тестирование и правки

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

Новые требования много времени не заняли: отображать ещё одно поле в таблице — 5 минут, добавить фильтр — 10, скорректировать условие в загрузке Excel — около получаса, добавить виджет на дашборд — 20 минут. В совокупности с визуальными правками всё вместе заняло около 4 часов. Классический цикл потребовал бы куда больше времени даже у опытного разработчика просто за счёт количества слоёв, которые придётся затронуть: изменить модель, написать миграцию, поправить форму, шаблон, view и передеплоить.

Ретроспектива и сравнение подходов

В лиде было заявлено сравнение, поэтому приступим.

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

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

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

В таком сравнении no-code — золотая середина: я работаю через визуальный интерфейс, не пишу код руками и ничего не сломаю на уровне инфраструктуры, но при этом контролирую каждый шаг и понимаю, как устроена система, потому что сам собрал её блок за блоком. Плюс порог входа довольно низкий: достаточно иметь базовые знания о веб-разработке и обладать алгоритмическим мышлением. Это сильно отличается от классической разработки — открыв проект для написания этой статьи, я с трудом сориентировался, что где находится (при том, что в Django проекты довольно удобно структурированы).

Говоря об интересах бизнеса — не всегда есть под рукой опытные разработчики и пара недель в запасе. Порой есть один человек и потребность, которую нужно закрыть сейчас. Django остаётся мощным фреймворком для профессиональных команд, и я не говорю, что он плох. Просто для задачи «быстро закрыть потребность бизнеса силами одного человека» no-code-платформа дала результат там, где классический стек потребовал бы ресурсов, которых не было.

Вывод

У каждого подхода своя цена. Классика вроде Django требует вложиться в изучение фреймворка и инфраструктуры заранее: это окупается, если за проектом стоят опытные люди и есть запас времени. Вайбкодинг выигрывает на старте: набросать рабочий прототип можно за час, но как только логика усложняется, вы получаете систему, которую никто осознанно не проектировал, и разбираться с ней придётся уже живому человеку.

Для моей задачи no-code — золотая середина — быстрее, чем классическая разработка: часть контроля над инфраструктурой забирает на себя платформа, и при этом больше контроля, чем в сгенерированном коде: систему и процессы я собираю осознанно шаг за шагом и могу быть уверенным в результате.