🧩 Memory bank для существующих проектов :: Реверс-проектирование и реверс-документирование в brownfield
1/2

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

Но что делать, если хочется использовать меморибанк с существующим проектом, для которого нет меморибанка? Это - территория brownfield, и она значительно сложнее greenfiled.

Ситуация внедрения меморибанка в существующий проект требует творческого подхода. О чем необходимо подумать при старте такого начинания:

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

- наличие существующей документации: если она есть, структурировать её для ИИ агентов будет технической задачей; хуже когда документации нет, или она не точная, причём, согласно исследованиям, неточная документация вреднее её отсутсвия;

- документирование кода: jsdoc/docstrings в проекте уже составляют неплохую базу для ИИ агента;

- степень понимания проекта участниками: иногда есть реально работающие системы, которые НИКТО из сотрудников/подрядчиков не понимает полностью, потому что они долго эволюционно развивались, пережили ротации разработчиков, эволюцию бизнеса, меняющиеся требования, интеграцию с внешними системами - и все это в реальной жизни, без особой документации (которой иногда и не делали), со схемой работы в головах сотрудников (которые потом увольнялись без полной качественной передачи знаний). Такое и приводит к ситуации: система работает, но ПОЧЕМУ ИМЕННО ТАК - не известно достоверно никому; 

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

Совсем готовых рецептов нет, но я поделюсь практическими подходами, которые использовал сам в ряде проектов.

▶️ Базовый принцип: мы "строим" в меморибанке усровень абстракции "выше" кода, потому что именно этих уровней не хватает агентам для эффективной работы

▶️ Что за уровни? Тут на помощь приходят классические архитектурные паттерны (да, теперь мы говорим о ренессансе традиционного SWE, прости, agile!) - например, простым и практически удобным для применения будет паттерн C4, подробнее - https://t.me/deksden_notes/55

▶️ Верхний уровень L1 документировать просто - описываем что у нас за система, кто и зачем ей пользуется; концептуальная информация скорее, пректически - задаёт домент рассуждениям агентов;

▶️ L2 уровень очень важен: тут мы описываем крупные блоки вашей системы - назовём их подсистемами: databse, ui, api server, processing engine, - все что имеем; важно правильно выбрать "нарезку", чтобы это имело практический смысл. Например, если у вас огромный Api сервер, имеет смысл выделять в нем свои структурные блоки вроде аутентификации/авторизации, CRUD по модулям. "Крупность" нарезки блоков определяется так: фиче приложения желательно взаимодействовать с одним блоком - то есть, если "пользователь вносит заказ", то он взаимодействует с одним блоком базы данных. Так мы сможем в контекст агента положить всего один документ про подсистему БД "Заказы".

▶️ L3 Уровень - это фичи приложения, это "элементарные" блоки функциональности вашей системы. Делятся аналогично, по автономии: например, вы можете реализовать фичу "пользователь создаёт заказ в системе" отдельно от "пользователь редактирует заказ в системе". Самый многочисленный уровень для документирования. Про его сбор чуть далее.

▶️ L4: у вас уже есть, мы как раз строили мостик между L1 -> L4.

(... продолжение тут: https://t.me/deksden_notes/67)

#post
@deksden_notes