Gegenereerd uit de code, niet met de hand getekend
Niemand houdt UML-diagrammen met de hand bij, dus kloppen ze een week na het tekenen al niet meer. CodeLynq leest je broncode met tree-sitter en brengt in kaart welke bestanden, packages en klassen van welke afhankelijk zijn. Het werkt voor Python, JavaScript, TypeScript, Go, Java, C# en PHP.
De kaart wordt opnieuw gemaakt aan het begin van elke run, na elke merge in de standaardbranch en elke nacht. Je ziet dus de code zoals hij vandaag is, inclusief wat je AI-agent vanochtend veranderde.
Inzoomen van componenten tot klassen
Begin bij de onderdelen van je architectuur, zoals API, Domein of Persistentie, en de afhankelijkheden daartussen. Dubbelklik om in te zoomen op mappen en bestanden, en op een bestand om de klassen, velden, methoden en overerving te zien. Klik op een pijl om de imports erachter te zien.
Eén UML-klassendiagram voor al je repositories
De UML-weergave brengt alle repositories van een project samen in één klassendiagram: packages per repository, klassen met hun leden, en UML-relaties voor overerving, interfaces, associaties en afhankelijkheden. Importeert de ene repository de andere, dan wordt ook dat getekend. Exporteer het als PlantUML of Mermaid om in je repository of documentatie te bewaren.
Architectuurregels waar elke run zich aan houdt
- Leg vast welke componenten niet van elkaar mogen afhangen, bijvoorbeeld: het domein mag niet importeren uit de databaselaag.
- Voordat een pull request opent, toetst CodeLynq de wijziging aan die regels en stuurt een overtreding terug naar de agent om te herstructureren.
- Alleen afhankelijkheden die de wijziging toevoegt tellen mee; bestaande overtredingen komen niet op rekening van de run.
- Elke pull request krijgt een sectie Structure changes: nieuwe afhankelijkheden, nieuwe klassen, nieuwe packages en eventueel gebroken regels.
Van plaatje naar werk
Selecteer de onderdelen van de kaart waar een wijziging over gaat, beschrijf hem, en CodeLynq maakt een refactortaak met een concept-spec met de feiten van je selectie: de bestanden, wat ze declareren en wat ervan afhangt. Koppel de regel die de wijziging moet waarmaken, en na de merge hoort die regel bij je architectuur.
Vragen over de architectuurkaart
- Welke talen worden ondersteund?
- Python, JavaScript, TypeScript, Go, Java, C# en PHP. Een repository met meerdere talen wordt als geheel in kaart gebracht.
- Ziet het dependency injection en dynamische aanroepen?
- Nee. De kaart wordt gemaakt uit imports en declaraties zoals ze in de code staan. Afhankelijkheden die pas tijdens het draaien ontstaan, zie je niet.
- Kan ik het diagram exporteren?
- Ja, het UML-diagram van het hele project exporteer je als PlantUML- of Mermaid-tekst.
- Werkt het met self-hosted runners?
- Ja. Een runner stuurt voor de architectuurcontrole alleen de bronbestanden die zijn agent wijzigde, nooit de hele repository.