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

«Давайте всё перепишем»

В первой статье я писал, что программа создаётся на бумаге. Теперь — о том, что происходит, когда бумагу пропускают, но очень хотят сделать «по-новому».

Сценарий знаком любому, кто проработал в разработке дольше пары лет. В проект приходит новая команда, знакомится с системой, и вскоре звучит фраза: «Давайте всё перепишем».

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

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

Тренд — да, гонка — нет

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

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

Красивая оболочка без начинки

Без понимания предметной области максимум, на что хватит сил, — красивая оболочка на новых технологиях: быстрые экраны, современная сборка, аккуратные компоненты.

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

Тыква по расписанию

Есть и вторая проблема, менее заметная. Через пару лет новая технология перестанет быть новой, и код на ней превратится в тыкву — в легаси. Ровно как текущий код, который пару лет назад тоже был на пике популярности.

Получается цикл: сегодня переписываем старое на новое, через пару лет новое становится старым, приходит следующая команда — и снова звучит: «Давайте всё перепишем».

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

Модель остаётся

А вот что никуда не денется — это модель. Математическая модель предметной области, грамотно заложенная в фундамент приложения. Сущности, связи, правила, ограничения. Она может кардинально не меняться десятилетиями.

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

Об этом в 1981 году говорил академик Андрей Петрович Ершов в докладе «Программирование — вторая грамотность». Он писал, что и книги, и вычислительные машины являются носителями информационной модели внешнего мира, а необходимость актуализировать эту модель в виде программ требует и одновременно позволяет существенно повысить интеллектуальную силу человечества (А. П. Ершов, Виртуальный компьютерный музей). Ключевое слово здесь — модель. Программа лишь её актуализирует.

Что предлагает ИИ

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

И здесь важная развилка.

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

Если модели нет, ИИ с таким же удовольствием перенесёт все концептуальные погрешности во все современные технологии. Быстро, уверенно и без единого вопроса. Ошибка, которая раньше жила в одной системе, теперь будет жить в новой — и выглядеть современно.

ИИ не отменяет журнал изменений

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

Первый — журнал изменений (changelog). Что изменилось, в какой версии, зачем. Когда код пишет ИИ, объём изменений растёт в разы. Без журнала через месяц никто — ни человек, ни сам ИИ — не скажет, почему система устроена именно так.

Второй — паспорт проекта (project summary). Коротко: что это за система, какая у неё модель, где границы, какие решения приняты и почему. Это то, что новый разработчик читает в первый день. И это то, что нужно дать ИИ, прежде чем просить его что-то менять. Без такого описания он будет додумывать — и додумывать по шаблонам, а не по вашей предметной области.

Ничего революционного здесь нет. Советская Единая система программной документации, которая действует до сих пор, ещё с 1980 года требует вносить изменения в программные документы только на основании извещения об изменении (ГОСТ 19.603-78, Росстандарт). А документ «Описание программы» по той же системе включает назначение, функциональные ограничения и описание логической структуры (ГОСТ 19.402-78, Росстандарт). Те же журнал изменений и паспорт проекта, только на бумаге и с печатью. Инструменты сменились. Смысл — нет.

Изучите модель

В первой статье я вспоминал логику студента: дайте мне инструмент — и я переверну мир.

Инструментов сегодня больше, чем когда-либо. ИИ сделает переписывание почти бесплатным. Поэтому вопрос уже не в том, на чём писать. Вопрос в том, что именно вы пишете.

Изучите модель. А дальше — переворачивайте мир.