У нас в проекте есть кодген openAPI схемы, который генерирует нам типобезопасный код для работы с API. Т.е. мы теперь вместо написания
fetch(...) можем напрямую писать getUser() в коде и не заморачиваться над тем как корректно отсылать запросы.Всё было хорошо пока не пришла эра ИИ. Наш кодген генерировал по 1 файлу на сервис. И этот файл мог достигать монструозных размеров: до 100-150к токенов на файл. И никакой клиент просто не вытягивал подобное: CLine вылетал с превышением контекста, а всякие курсоры просто забивали на его контент. В общем, решение нашлось - можно разбить файл на кучу файлов, каждый из которых будет содержать ровно по 1 функции.
Есть ещё один важный нюанс: мы используем Bazel для того чтобы поддерживать нашу монорепу. И у него есть один нюанс: все его задачи обязаны явно описывать output-файлы. Причём поддержки директорий тупо нет в нормальном исполнении. А в плане выше невозможно предугадать какие файлы будут созданы из-за того, что у каждого сервиса бекенда разное количество эндпоинтов. Или же можно, но тогда пришлось бы тупо дублировать логику в базере и в кодгене.
И тут пришло в голову отвратительнейшее решение: создать 100500 файлов 1.ts, 2.ts, ..., N.ts и руками подобрать N. Тогда мы точно будем знать какие файлы будут сгенерены и сможем указать их в параметрах задачи базеля.
Для сервисов, у которых эндпоинтов меньше N просто оставляем лишние файлы пустыми.
Решение максимально кривое и отвратительное, но оно работает. И я сэкономил наверно неделю времени, которое мог бы потратить на нормальное решение.
После этой задачи я чуток прикинул то что делал раньше и понимаю, что мог бы сэкономить кучу времени, если бы не работал над красотой и обходом костылей. Но если поправить костыль не так сложно(до 1 дня), то зачастую я просто не замечаю сколько времени я трачу на подобный рефакторинг.
Возможно, моё мнение сильно изменилось после того как я начал управлять ИИшкой и забивать на качество кода. Возможно, пора забивать и на качество своих решений, а не только на качество решений ИИшки.