Tovább a tartalomhoz

Kód keresése a kódgráffal

Ez az útmutató megmutatja, hogyan vigyen be egy repót a kódgráfba, majd hogyan használja arra a kérdésre válaszolva, amely egy refaktorálás előtt valójában foglalkoztatja: mitől függ ez?

A kódgráf egy szimbólumokból és élekből álló adatbázis, amely a regisztrált checkoutok tree-sitterrel történő feldolgozásával épül fel. Az eszközei az ügynököknek szólnak — úgy érheti el őket, hogy megkér egy ügynököt.

A gráf a következő nyelveket indexeli: Dart, JavaScript, TypeScript, TSX, PHP, Python, Rust, Zig, C, C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB és Ada. A más nyelveken írt fájlokat nem dolgozza fel, így azok nem jelennek meg a search_code, code_symbol, code_callers, code_callees és code_impact eredményében.

Két további tényező alakítja azt, hogy mi kerül be az indexbe:

  • Egy git work tree esetén a felsorolás a git ls-files --cached --others --exclude-standard parancsra hagyatkozik, így minden .gitignore, beágyazott ignore-fájl, .git/info/exclude és a globális kizárásfájl érvényesül. Ez tartja távol a gráftól a node_modules-t és a build kimenetét.
  • A generált Dartot ettől függetlenül kihagyja. A generált fájlokat általában verziókövetésbe teszik, így a git önmagában nem zárná ki őket, és minden kódgenerálási futásnál változnak.

Egy checkout regisztrálása kiváltja a RepoAdded eseményt, amely automatikusan elindítja az index_code pipeline-t ehhez a repóhoz. Lásd: Repók hozzáadása munkaterülethez.

Kézi újraindexeléshez:

  1. Nyissa meg a Beállítások → Munkaterület → Tárolók helyet.
  2. Kattintson a repó sorában a Kód indexelése gombra.
  3. Amíg fut, a gomb a kész fájlok és az összes fájl arányát mutatja, egy megszakítás vezérlőelemmel együtt. Amikor befejeződik, egy pipává alakul a szimbólumok számával.

A gráf munkaterület, repó és checkout szerint particionálódik: a csatolt checkout egy partíció, és minden tér worktree-je sajátot kap (amelynek kulcsa a saját izolált repó azonosítója).

Két fékező mechanizmusról érdemes tudni, mert megmagyaráznak egy olyan várakozást, amely lefagyásnak tűnik:

  • A fájlfelügyelő a hoszton egyszerre csak egy indexelési menetet enged be — a második checkout várakozik. Az index_code pipeline külön korlátja munkaterületenként egy futás, így az ugyanabban a munkaterületben lévő két repó sorba áll; a különböző munkaterületek párhuzamosan indexelhetnek. Maga az indexelő az ugyanazon checkout két futását sorosítja, így egy pipeline-indítás és egy felügyelői bejárás nem dolgozhatja fel kétszer.
  • A tétlen terekhez (az elmúlt egy hétben nincs üzenet) tartozó worktree-ket sem figyeli, sem indexeli. A csatolt checkoutok figyelése megmarad. A kihagyásról szóló döntést öt perc után újraellenőrzi, így az újra aktívvá váló tér ismét bekerül.

Kérjen meg egy ügynököt a keresésre. Az eszköz neve search_code, és egyszerre igényel munkaterületet és repót:

search_code(workspace_id: "...", repo_id: "...", query: "authentication middleware")

A repóazonosítók a list_repos parancsból származnak. Az opcionális mode argumentum keyword, semantic vagy hybrid lehet, alapértéke a hybrid — BM25 a nevek, szignatúrák és dokumentációs megjegyzések fölött, vektoros hasonlósággal összevonva.

Minden találat tartalmazza a szimbólum azonosítóját, nevét, minősített nevét, fajtáját, fájlútvonalát, kezdő és záró sorát, valamint a szignatúráját, ha van neki. Az id az a fogantyú, amelyet az oldalon szereplő összes többi eszköznek átad.

Ha ismeri a pontos nevet, keresse meg közvetlenül:

code_symbol(workspace_id: "...", repo_id: "...", name: "MyClass")

Mindkettő egy keresési találatból származó symbol_id-t vesz fel, valamint egy opcionális limit értéket (alapérték: 50):

code_callers(workspace_id: "...", symbol_id: "...")
code_callees(workspace_id: "...", symbol_id: "...")

A code_callers azokat a szimbólumokat adja vissza, amelyekből bejövő él mutat erre; a code_callees azokat, amelyektől ez függ.

Nézze meg, mit törne el egy módosítás

Szekció neve “Nézze meg, mit törne el egy módosítás”

Ez az az eszköz, amelyért az egész oldal készült:

code_impact(workspace_id: "...", symbol_id: "...", depth: 3)

A fordított függőségi sugarat számítja ki: mindent, ami közvetlenül vagy tranzitívan függ a szimbólumtól calls, extends és implements éleken keresztül (az importokat, a mixin-besorolásokat és az általános hivatkozásokat a gráf tárolja, de itt nem járja be). A depth a maximális ugrásszám 1 és 6 között, alapértéke 2.

Az eredmény három mező:

  • root — a szimbólum, amelyre kérdezett
  • impacted — az elérhető halmaz, benne a gyökér 0 mélységben, mindegyik a gyökértől számított depth értékével
  • edgeCount — hány élen haladt át a bejárás, darabszámként és nem magukként az élekként

Futtassa átnevezés vagy szignatúramódosítás előtt, és adja meg az ügynöknek az érintett listát hatókörként.

Az eredmények ellenőrzése a hívó saját munkapéldányán

Szekció neve “Az eredmények ellenőrzése a hívó saját munkapéldányán”

Ügynök hívó esetén a tér azonosítója automatikusan bekerül, és az eredményeket annak a térnek a munkapéldányán ellenőrzi. Az olyan szimbólum, amelynek fájlja már nincs meg a hívó munkapéldányában, kimarad, és a válasz egy staleOmitted darabszámot, valamint egy megjegyzést tartalmaz, amely szerint az index elavult ezeknél a szimbólumoknál.

Ezért kaphat ön és egy ügynök ugyanarra a lekérdezésre eltérő választ, és ezért kaphat az egyik térben lévő ügynök más választ, mint egy másikban lévő. Egy tér minden beszélgetése ugyanazt az egy worktree-t használja. Az ellenőrzés nyitottan hibázik: az elavult választ előnyben részesíti az üres helyett.

Kérjen meg egy ügynököt a code_impact (vagy a review_studio.blastRadius) futtatására, ha egy módosítás hatássugarára kíváncsi. Lásd: Átnézési számítás.

A szemantikus kereséshez beágyazási modell kell

Szekció neve “A szemantikus kereséshez beágyazási modell kell”

A szimbólumok és a tények íráskor kapnak beágyazást, méghozzá csak akkor, ha az eszközön futó beágyazási modell telepítve van. Addig a mode: "semantic" és a hibrid keresés szemantikus fele nem tud mihez illeszkedni, így a keresés gyakorlatilag kulcsszavas marad.

Az indexelés előtt telepítse a modellt a Beállítások → Szerver → Diagnosztika és adatvédelem → Szemantikus keresés helyen. A szimbólumok akkor kapnak vektort, amikor a fájljuk bekerül az indexbe.

Vegye figyelembe azt is, hogy a szerverbineráris bármilyen újraépítése újra előkészíti a nyelvtan-dylibeket, és megváltoztatja az mtime-jüket, ami érvényteleníti az összes index-ellenőrzőpontot, és a következő futáskor minden checkout teljes újrabejárására kényszerít. Újraszámolja a hash-eket, a változatlan fájlokat azonban nem dolgozza fel újra.

Szimbólumfajták: function, method, class, field, enum, constructor, getter, setter, typedef, extension, mixin, variable.

Élfajták: calls, imports, extends, implements, mixes in, references.

Ezeknek az eszközöknek a hivatalos szignatúrái az MCP-eszközök oldalon találhatók.