Рефакторинг легаси-модуля в Kimi: карта, план, код по шагам
Kimi читает файл целиком, рисует карту модуля, называет узкие места со строками и даёт план из 3–5 отдельных коммитов. Код пишет только после вашего «ок», к каждому шагу — что проверить руками.
Ты берёшь на поддержку чужой модуль. Работаем в два захода: сначала разбор текстом, потом код.
Модуль на [ЯЗЫК И ВЕРСИЯ: Python 3.11, Django 4.2], вставляю файл целиком: [КОД: вставь сюда содержимое файла от первого импорта до последней строки]. Что должно работать иначе: [ЗАДАЧА: повторный клик по кнопке «Оформить» не должен создавать второй заказ]. Рамки: [ОГРАНИЧЕНИЯ: публичный интерфейс менять нельзя, тестов в проекте нет, деплой раз в неделю].
Заход первый — без кода:
1. Карта модуля: какие сущности внутри, кто кого вызывает, где открывается и закрывается транзакция, какие функции дёргают снаружи.
2. Узкие места по одному: строка или диапазон строк — что именно ломается — при каком сценарии это замечает пользователь. Отдельно пометь те, из-за которых возникла моя задача.
3. План до 5 шагов. Каждый шаг — самостоятельный коммит, который можно выкатить отдельно: зачем он, что меняется, чем рискуем.
Дальше останавливаешься и ждёшь «ок».
Заход второй, после «ок» — по одному шагу за сообщение:
— полный код изменённых функций, без диффов и без «остальное без изменений»;
— публичные имена, сигнатуры и формат ответа сохраняешь; если шаг ломает их неизбежно — скажи прямо и предложи обходной путь;
— в конце шага строка «Проверить руками:» и 2–3 конкретные проверки: что запустить, что должно вернуться, как воспроизвести старый баг и убедиться, что он ушёл.
Если данных не хватает — кто ещё вызывает эти функции, есть ли миграции, какая версия библиотеки — останови разбор и спроси, не больше трёх вопросов за раз, — не угадывай.
Правила игры: стиль и форматирование ради красоты не меняешь; новые зависимости — только через отдельный вопрос; функции, которых нет в файле, не выдумываешь; весь модуль одним куском не переписываешь.
Разбор заканчивай строкой «Что я не трогал и почему» — до 3 пунктов.
Собрать под себя — поля заполнены рабочими значениями, меняйте их и промпт выше обновится сам
Кусок первого ответа Kimi на 400 строк Django-кода:
«Карта. Модуль держит три роли сразу: HTTP-вход (create_order), бизнес-правила (скидки, лимиты) и запись в БД. Транзакция открывается в строке 96 и закрывается в 154, но письмо клиенту уходит в 141 — внутри транзакции.
Узкое место 1, строки 96–120: заказ создаётся до проверки на дубль, уникального ключа нет. Пользователь кликает второй раз, пока крутится спиннер, и получает два заказа с разными id.
Узкое место 2, строка 141: при откате транзакции письмо уже отправлено — клиент видит письмо про заказ, которого нет.
План. Шаг 1: идемпотентный ключ из (user_id, cart_hash) плюс уникальный индекс. Шаг 2: вынести отправку письма за границу транзакции. Шаг 3: слой сервисов, вьюха только принимает и отдаёт.
Вопрос: create_order дёргают откуда-то ещё, кроме вьюхи, — из Celery, из админки?»
Что не сделает за вас Kimi. Миграцию под уникальный индекс накатывайте сначала на копии базы: на живых данных дубли уже есть и индекс не встанет, пока их не вычистите. Номера строк он иногда сдвигает на пару позиций — сверяйте по имени функции, а не по числу. И на файлах больше двух тысяч строк просите сперва только карту и план: код в том же сообщении получается заметно слабее.
