You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The `codebase_investigator` identified several critical areas for improvement in the current codebase:
5
+
1.**Performance Bottlenecks:**`N+1` queries exist in the GORM store (`UpsertNodes`) and BFS logic (`ImpactRadius`), which will degrade performance on larger code graphs.
6
+
2.**Architectural Coupling:**`internal/cli/build.go` handles file walking, parsing orchestration, and database syncing, violating the Single Responsibility Principle (SRP).
7
+
3.**Parser Maintainability (God Object):**`internal/parse/treesitter/walker.go` contains hard-coded language-specific logic across its methods, making it difficult to maintain or add new languages.
8
+
4.**Robustness:** Database operations during the file build process lack proper transaction boundaries, risking orphaned data on errors.
9
+
10
+
## Scope & Impact
11
+
This refactoring effort aims to systematically eliminate these technical debts. It touches core components (`gormstore`, `impact`, `build`, `treesitter`) without altering the expected external behavior of the CLI.
12
+
13
+
## Proposed Solution: Phased Refactoring Approach
14
+
15
+
We will tackle the refactoring in 3 distinct phases to ensure safe integration and review:
-**Batch Upserts (via GORM):** Replace individual node `SELECT` and `UPDATE/CREATE` calls in `gormstore.UpsertNodes` with GORM's native batching and conflict resolution:
-**Transaction Blocks:** Enforce `db.Transaction(func(tx *gorm.DB) error { ... })` across all file-level mutations to ensure atomicity. If a file fails to index completely, it will automatically roll back.
26
+
-**BFS Optimization:** Refactor `ImpactRadius` in `impact.go` to query outgoing and incoming edges for the entire `frontier` in a single `IN (?)` query per depth iteration.
27
+
28
+
### Phase 2: CLI Decoupling & Service Layer (Orchestration)
29
+
-**Create `GraphService`:** Extract the orchestration logic from `cli/build.go` into a new `internal/service/indexer.go`. This service will handle file walking, parsing delegation, and DB upserts within transaction blocks.
30
+
-**Isolate CLI:** Simplify `build.go` to only handle argument parsing, flag binding, and invoking the new `GraphService`.
31
+
32
+
### Phase 3: Walker Refactoring (Parser Layer via Tree-sitter Queries)
33
+
-**Migrate to Query-based Pattern Matching:** Instead of maintaining a God Object (`Walker`) with hard-coded AST traversal and language-specific `if/else` logic, we will utilize **Tree-sitter's Query System (S-expressions)**.
34
+
-**Language Definitions (.scm):** Create `queries/<language>/tags.scm` files defining language-specific patterns for functions, classes, calls, and imports (e.g., `(function_declaration name: (identifier) @name)`).
35
+
-**Generic Query Executor:** Refactor `walker.go` to compile these queries via `sitter.NewQuery` and execute them using `sitter.NewQueryCursor`. This makes the Go code 100% language-agnostic and data-driven.
36
+
37
+
## Alternatives Considered
38
+
-**Strategy Pattern for Parser:** Creating `LanguageHandler` interfaces for 15+ languages in Go. Rejected because Context7 documentation shows that Tree-sitter's native Query API is the industry standard for cross-language AST pattern matching, requiring far less Go boilerplate.
39
+
-**Big Bang Refactoring:** Doing all of this in a single pass. Rejected because it introduces too much risk and makes bug isolation extremely difficult.
40
+
41
+
## Verification & Testing
42
+
- Ensure the existing test suite (especially `gormstore_test.go`, `impact_test.go`, `walker_test.go`, and `build_test.go`) continues to pass.
43
+
- Write new benchmark tests for `UpsertNodes` and `ImpactRadius` to empirically prove the elimination of N+1 overhead.
44
+
45
+
## Migration & Rollback
46
+
- No database schema migrations are necessary for this refactor. The graph and vectors will be recreated using the new optimized logic.
47
+
- Rollback can be performed via standard `git revert` since this does not fundamentally alter the storage schema or external API signatures.
0 commit comments