สารบัญ

เวลาในการอ่าน: 12 minutes

Codebase ของคุณกำลังเติบโตขึ้น ความสัมพันธ์ระหว่างโมดูลเพิ่มมากขึ้น เอกสารทางสถาปัตยกรรมกลายเป็นสิ่งที่ล้าสมัยก่อนที่จะเขียนเสร็จเสียอีก จะดีกว่าไหมถ้า build Gradle ของคุณสามารถสร้างไดอะแกรมที่ทันสมัยได้ โดยอัตโนมัติ จากโครงสร้างจริงของโค้ด? และนี่คือสิ่งที่ pipeline Graphify + PlantUML Gradle Plugin ทำได้:`graphify . --no-viz`สกัด Knowledge Graph,`./gradlew generateKnowledgeGraphDiagram`เปลี่ยนให้เป็นไดอะแกรม PlantUML ไม่ใช้ LLM ไม่ใช้การทำด้วยมือ และมีความแน่นอน 100%

ปัญหาคือ: ไดอะแกรมล้าหลังกว่าโค้ดเสมอ

ทุกโปรเจกต์ที่มีจำนวนบรรทัดเกินกว่าไม่กี่พันบรรทัดมักจะประสบกับอาการนี้:

  1. เราวาดแผนผังโครงสร้างสถาปัตยกรรมในช่วงเริ่มต้นของโครงการ

  2. โค้ดมีการพัฒนา สิ่งที่ต้องพึ่งพามีการเปลี่ยนแปลง

  3. แผนภาพกลายเป็นคำลวงที่ถูกตกแต่งให้สวยงาม

  4. ไม่มีใครอัปเดตมันเพราะว่ามันน่าเบื่อ

  5. ผู้มาใหม่ใช้สิ่งนี้เป็นเกณฑ์และทำผิดพลาด

@startuml
skinparam backgroundColor #FEFEFE
skinparam ActivityBackgroundColor #FDEDEC
skinparam ActivityDiamondBackgroundColor #FFF3CD

start

:Diagramme d'architecture créé\n(manuellement, à la main);

:Le code évolue\n(nouvelles classes, nouvelles dépendances);

:Diagramme obsolète\n(ne reflète plus le code);

if (Qui met à jour ?) then (Personne)
    :Documentation mensongère;
    note right: Les nouveaux développeurs\nse basent dessus... et font des erreurs
else (Quelqu'un)
    :Mise à jour manuelle\n(2-3 heures de travail);
    note right: Déjà obsolète\nà la prochaine PR
endif

stop

@enduml

คำถามไม่ใช่ว่า ต้องมีแผนภูมิหรือไม่? — เพราะทุกคนรู้ดีว่าต้องมี คำถามคือ:ใครเป็นผู้ดูแลให้ข้อมูลเหล่านี้เป็นปัจจุบัน?

คำตอบคือ: ไม่มีใครเลย นอกจากว่าจะเป็นระบบอัตโนมัติ

โซลูชัน: ไปป์ไลน์แบบดีเทอร์มินิสติก (deterministic pipeline) จาก Knowledge Graph → PlantUML

หลักการนั้นง่ายมาก: แทนที่จะวาดไดอะแกรมด้วยมือ เราจะ…​สร้างขึ้นจากโครงสร้างจริงของโค้ดโปรดระบุข้อความที่ต้องการให้แปลครับ

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

actor Développeur
component "Graphify\n(pip install graphifyy)" as Graphify
collections "graphify-out/graph.json\n(Knowledge Graph)" as KGJSON
component "PlantUML Gradle Plugin\n(generateKnowledgeGraphDiagram)" as Plugin
component "KnowledgeGraphParser" as Parser
component "KnowledgeGraphRenderer" as Renderer
component "PlantumlService\n(validation + rendu PNG)" as PS
collections "diagrams/knowledge-graph/\n(.puml + .png)" as Output

Développeur --> Graphify : graphify . --no-viz
Graphify --> KGJSON : extrait la structure\ndu code source
Développeur --> Plugin : ./gradlew generateKnowledgeGraphDiagram
Plugin --> Parser : parse(graph.json)
Parser --> Plugin : KnowledgeGraph\n(noeuds + arêtes + communautés)
Plugin --> Renderer : render(graph, filters)
Renderer --> Plugin : code PlantUML\ndéterministe
Plugin --> PS : validateSyntax + generateImage
PS --> Output : .puml + .png

note bottom of Plugin
  Pipeline DÉTERMINISTE
  Aucun appel LLM
  Résultat reproductible
end note

@enduml

คำสั่งสองคำสั่ง เท่านั้นเอง

# Étape 1 : extraire le Knowledge Graph
graphify . --no-viz

# Étape 2 : générer les diagrammes PlantUML
./gradlew generateKnowledgeGraphDiagram

ผลลัพธ์ที่ได้คืออะไร? ไฟล์ต่างๆ`.puml` et .png`ใน`diagrams/knowledge-graph/, ซึ่งมีการควบคุมเวอร์ชันด้วย Git และเป็นปัจจุบันตามโค้ดเสมอ

ขั้นตอนที่ 1: ติดตั้ง Graphify และดึง Knowledge Graph ออกมา

การติดตั้ง

Graphify คือเครื่องมือ Python ที่วิเคราะห์ codebase ของคุณและสร้างกราฟความรู้ที่มีโครงสร้าง:

# Méthode recommandée
uv tool install graphifyy && graphify install --platform opencode

# Alternative avec pip
pip install graphifyy && graphify install --platform opencode

ตั้งค่าการยกเว้น

สร้างไฟล์`.graphifyignore`ที่รากของโปรเจกต์ เพื่อยกเว้นไฟล์ที่ไม่ได้เป็นส่วนหนึ่งของ business logic:

# Secrets — JAMAIS dans le graphe
*-context.yml
*.env

# Fichiers générés
build/
.gradle/

# Tests fonctionnels
src/functionalTest/

ดึง Knowledge Graph ออกมา

graphify . --no-viz

แฟล็ก`--no-viz`ข้ามการสร้าง HTML (ไม่จำเป็นใน pipeline ของ Gradle) ผลลัพธ์ที่ได้คือไฟล์`graphify-out/graph.json`ซึ่งประกอบด้วย :

  • โหนด: คลาส, ฟังก์ชัน, ไฟล์ — พร้อมด้วยประเภทและคอมมูนิตี้

  • ขอบ: ความสัมพันธ์ระหว่างโหนด (EXTRACTED จากโค้ด, INFERRED โดย LLM)

  • ชุมชน: การจัดกลุ่มโหนดที่เชื่อมโยงกันโดยอัตโนมัติ

ตัวอย่างโครงสร้าง`graph.json`
{
  "nodes": [
    {"id": "0", "label": "LlmService", "file_type": "code", "community": 0},
    {"id": "1", "label": "ApiKeyPool", "file_type": "code", "community": 0},
    {"id": "2", "label": "PlantumlService", "file_type": "code", "community": 1}
  ],
  "links": [
    {"source": "1", "target": "0", "relation": "uses", "confidence": "EXTRACTED", "weight": 0.9},
    {"source": "0", "target": "2", "relation": "calls", "confidence": "INFERRED", "weight": 0.7}
  ]
}

ซอร์สโค้ด (.kt, .java) ถูกวิเคราะห์ในระดับท้องถิ่นโดย tree-sitter,LLM แบบเบ็ดเสร็จเด็ดขาด. เฉพาะไฟล์เอกสาร (.adoc, .md) จำเป็นต้องมีการเรียกใช้ LLM เพื่อการสกัดความหมายทางภาษา (semantic extraction) ดังนั้น`--update`บนโค้ด Kotlin นั้นแทบจะทันทีทันใด

ขั้นตอนที่ 2: Gradle plugin จะแปลง Knowledge Graph ให้เป็น PlantUML

สถาปัตยกรรมของ pipeline

ปลั๊กอิน`com.cheroliv.plantuml`รวมงานหนึ่งงาน`generateKnowledgeGraphDiagram`ซึ่งแปลง`graph.json`เป็นไดอะแกรม PlantUML ในรูปแบบกำหนดการแบบเด็ดขาดโดยสมบูรณ์โปรดระบุข้อความที่คุณต้องการให้แปลครับ

@startuml
skinparam backgroundColor #FEFEFE

participant "Gradle" as G
participant "GenerateKnowledgeGraphDiagramTask" as Task
participant "KnowledgeGraphParser" as Parser
participant "KnowledgeGraphRenderer" as Renderer
participant "PlantumlService" as PS

collections "graphify-out/graph.json" as JSON

G -> Task : execute
Task -> JSON : read
Task -> Parser : parse(graph.json)
Parser --> Task : KnowledgeGraph\n(noeuds + arêtes + communautés)
Task -> Renderer : render(graph, filters)
Renderer --> Task : code PlantUML\n(déterministe)
Task -> PS : validateSyntax(plantumlCode)
alt syntaxe valide
    Task -> PS : generateImage → .png
else syntaxe invalide
    Task -> Task : save .puml avec warning
end

@enduml

ส่วนประกอบภายใน

ส่วนประกอบ บทบาท

KnowledgeGraphParser

วิเคราะห์ (Parse)graph.json— รองรับ 3 รูปแบบ: graphify แบบเนทีฟ (nodes+links), legacy (communities), flat แปลง ID ตัวเลขเป็นเลเบล

KnowledgeGraphRenderer

แปลง…​อย่างกำหนดได้หนึ่ง`KnowledgeGraph`เป็นโค้ด PlantUML กลุ่มตามประเภท, ชุมชนใน packages, คำอธิบายสัญลักษณ์อัตโนมัติ

GenerateKnowledgeGraphDiagramTask

Gradle Task ที่ทำหน้าที่ประสานงาน: parse → render → validate → PNG สามารถกำหนดค่าได้ผ่าน Gradle properties

kgmodels.kt

โมเดลข้อมูล:`KnowledgeGraph`, KnowledgeGraphNode, KnowledgeGraphEdge, KnowledgeGraphCommunity, `EdgeType`โปรดระบุข้อความที่ต้องการให้แปลครับ

PlantumlService

การตรวจสอบไวยากรณ์ + การเรนเดอร์ PNG (นำกลับมาใช้ใหม่โดยทุกงานของปลั๊กอิน)

กฎการแสดงผล

ตัวเรนเดอร์ใช้ข้อกำหนดทางทัศนศิลป์แบบดีเทอร์มินิสติก (deterministic visual conventions):

ประเภทของขอบ สัญลักษณ์ PlantUML ความหมาย

สกัดแล้ว

-→(เส้นทึบ, สีดำ)

ความสัมพันธ์ที่สกัดจากซอร์สโค้ด (ความมั่นใจ)

อนุมานได้

..>(เส้นประ)

ความสัมพันธ์ที่อนุมานโดย LLM (คะแนนความเชื่อมั่น)

กำกวม

--x(เส้นประสีแดง)

ความสัมพันธ์คลุมเครือ (ต้องตรวจสอบ)

คอมมูนิตี้จะถูกแสดงผลเป็นแพ็กเกจ PlantUML พร้อมจานสีอัตโนมัติ

ขั้นตอนที่ 3: การใช้งานในชีวิตประจำวัน

แผนภาพฉบับสมบูรณ์

# Générer le diagramme du Knowledge Graph complet
./gradlew generateKnowledgeGraphDiagram

เอาต์พุต:`diagrams/knowledge-graph/knowledge-graph-full.puml`+.png

กรองตามชุมชน

# Une seule communauté
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.community=community_0

# Limiter le nombre de noeuds (lisibilité)
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.community=community_0 \
  -Pplantuml.kg.maxNodes=15

กรองตามประเภทของขอบ

# Uniquement les relations certaines (EXTRACTED)
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.edgeTypes=EXTRACTED

# Relations certaines + inférées
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.edgeTypes=EXTRACTED,INFERRED

กรองตามประเภทโหนดและความเชื่อมั่น

# Uniquement les classes de code
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.nodeTypes=code

# Seuil de confiance minimum (pour les INFERRED)
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.minConfidence=0.7

ไดเรกทอรีเอาต์พุตที่กำหนดเอง

./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.outputDir=docs/architecture

ข้อมูลอ้างอิงคุณสมบัติแบบสมบูรณ์

คุณสมบัติ ค่าเริ่มต้น คำอธิบาย

plantuml.kg.community

(ทั้งหมด)

กรองชุมชนตามชื่อ (การจับคู่ส่วนย่อยของข้อความ)

plantuml.kg.edgeTypes

(ทั้งหมด)

ประเภทของขอบที่คั่นด้วยเครื่องหมายจุลภาค:`EXTRACTED`, INFERRED, AMBIGUOUS

plantuml.kg.minConfidence

0.0

เกณฑ์ความเชื่อมั่นขั้นต่ำสำหรับเส้นเชื่อม (edges)

plantuml.kg.maxNodes

(ไม่จำกัด)

จำนวนโหนดสูงสุดที่จะแสดง

plantuml.kg.nodeTypes

(ทั้งหมด)

ประเภทของโหนดคั่นด้วยเครื่องหมายจุลภาค (เช่น`class`, code)

plantuml.kg.outputDir

diagrams/knowledge-graph

ไดเรกทอรีเอาต์พุตสำหรับไฟล์`.puml` et .png

ไพป์ไลน์ที่สมบูรณ์ในเวิร์กโฟลว์ Gradle

ประเภทเวิร์กโฟลว์

@startuml
skinparam backgroundColor #FEFEFE
skinparam ActivityBackgroundColor #E8F4FD
skinparam ActivityDiamondBackgroundColor #FFF3CD
skinparam ActivityBorderColor #2C3E50

start

partition "EXTRACTION" {
    :graphify . --no-viz;
    note right: Analyse le code source\ntree-sitter (local, pas de LLM)

    :graphify-out/graph.json;
    note right: Noeuds + arêtes\n+ communautés
}

partition "GÉNÉRATION" {
    :./gradlew generateKnowledgeGraphDiagram;
    note right: Pipeline déterministe\nparse → render → validate → PNG

    if (Filtres actifs ?) then (Oui)
        :Appliquer filtres\n(community, edgeTypes,\nmaxNodes, nodeTypes);
    else (Non)
        :Diagramme complet;
    endif

    :diagrams/knowledge-graph/\nknowledge-graph-full.puml\nknowledge-graph-full.png;
}

partition "INTÉGRATION" {
    :git add diagrams/knowledge-graph/;
    :git commit;
    note right: Diagrammes versionnés\ntoujours à jour avec le code
}

stop

@enduml

การบูรณาการเข้ากับวงจรการพัฒนา

Pipeline นี้ผสมผสานเข้ากับขั้นตอนหลักของการพัฒนาได้อย่างลงตัว:

@startuml
skinparam backgroundColor #FEFEFE

state "Développement" as dev
state "Extraction\ngraphify . --no-viz" as extract
state "Génération\n./gradlew generateKnowledgeGraphDiagram" as generate
state "Commit\ndiagrammes versionnés" as commit

[*] --> dev
dev --> extract : Code modifié
extract --> generate : graph.json à jour
generate --> commit : .puml + .png générés
commit --> dev : Diagrammes dans le repo

note right of extract
  Quasi instantané sur du code Kotlin
  (tree-sitter, pas de LLM)
end note

note right of generate
  Déterministe
  Pas de LLM
  Résultat reproductible
end note

@enduml

การอัปเดตแบบส่วนเพิ่ม

เมื่อโค้ดเปลี่ยน เราจะไม่สร้างกราฟทั้งหมดขึ้นมาใหม่ตั้งแต่ศูนย์:

# Mise à jour incrémentale (fichiers modifiés uniquement)
graphify . --update

# Puis régénérer les diagrammes
./gradlew generateKnowledgeGraphDiagram

--update`สกัดเฉพาะไฟล์ที่ถูกแก้ไขอีกครั้ง (ตรวจพบโดย SHA256 ใน`graphify-out/cache/). สำหรับโค้ด Kotlin จะเกือบจะทันทีทันใดเพราะ tree-sitter ทำงานในเครื่องโดยไม่มีการเรียกใช้ LLM

Dogfooding: ปลั๊กอินที่สร้างเอกสารอธิบายการใช้งานด้วยตัวมันเอง

มีปลั๊กอิน PlantUML สำหรับเปลี่ยนพรอมต์ให้เป็นไดอะแกรม นอกจากนี้ยังสามารถเปลี่ยน Knowledge Graph ของ codebase ของ ตัวมันเอง ให้เป็นไดอะแกรมสำหรับเอกสารประกอบได้ ซึ่งถือเป็นการ dogfooding : ตัวปลั๊กอินใช้งานบริการของตัวเอง

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "Pipeline ปกติ\n(ผู้ใช้ → ไดอะแกรม)" as normal {
    [Fichier .prompt] as prompt
    [LlmService\n+ ApiKeyPool] as llm1
    [ProcessPlantumlPromptsTask] as task1
    [Diagramme PNG] as out1

    prompt --> task1
    task1 --> llm1
    llm1 --> out1
}

package "Pipeline Knowledge Graph\n(แบบกำหนดแน่นอน, ไม่มี LLM)" as kg {
    [graphify-out/graph.json] as kgjson
    [KnowledgeGraphParser] as parser
    [KnowledgeGraphRenderer] as renderer
    [PlantumlService] as ps
    [Diagramme PNG\n(documentation du plugin)] as out2

    kgjson --> parser
    parser --> renderer
    renderer --> ps
    ps --> out2
}

package "Pipeline Dogfooding\n(LLM → เอกสารประกอบปลั๊กอิน)" as dogfood {
    [GraphifyPromptAdapter] as gpa
    [Fichiers .prompt\nauto-générés] as auto_prompt
    [LlmService\n+ ApiKeyPool] as llm2
    [ProcessPlantumlPromptsTask] as task2
    [Diagramme PNG\n(documentation LLM)] as out3

    kgjson --> gpa
    gpa --> auto_prompt
    auto_prompt --> task2
    task2 --> llm2
    llm2 --> out3
}

note "LlmService เดียวกัน, ApiKeyPool เดียวกัน,\nPlantumlService เดียวกัน\n— ไม่มีการทำซ้ำ (ZERO duplication)" as N

@enduml

งาน Gradle ที่เกี่ยวข้อง:

งาน LLM ? คำอธิบาย

generateKnowledgeGraphDiagram

ไม่ใช่

แปลงค่า`graph.json`ใน PlantUML (แบบกำหนดผลลัพธ์ได้)

generateDiagramDocs

ใช่

สร้าง`.prompt`จากกราฟ แล้วนำไปประมวลผลผ่าน LLM (dogfooding)

# Documentation déterministe (rapide, pas de LLM)
./gradlew generateKnowledgeGraphDiagram

# Documentation LLM (plus riche, consomme des tokens)
./gradlew generateDiagramDocs

ทำไมสิ่งนี้ถึงเป็นแบบกำหนดได้ (และทำไมมันถึงสำคัญ)

จุดสำคัญของ pipeline`generateKnowledgeGraphDiagram`โปรดระบุข้อความที่ต้องการแปลครับมันไม่ได้เรียกใช้ LLM ใดๆ. การแปลงสภาพ`graph.json`→ PlantUML เป็นฟังก์ชันบริสุทธิ์ (pure function)

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

rectangle "Pipeline แบบดีเทอร์มินิสติก (DÉTERMINISTE)\n(`generateKnowledgeGraphDiagram`)" as det {
    [graph.json] as json
    [KnowledgeGraphParser] as parser
    [KnowledgeGraphRenderer] as renderer
    [PlantUML code] as puml

    json --> parser : parse
    parser --> renderer : KnowledgeGraph
    renderer --> puml : render (fonction pure)
}

rectangle "Pipeline LLM\n(`processPlantumlPrompts`)" as llm {
    [.prompt] as prompt
    [LlmService] as llmSvc
    [ChatModel] as model
    [PlantUML code] as puml2

    prompt --> llmSvc
    llmSvc --> model : API call
    model --> puml2 : réponse non-déterministe
}

note bottom of det
อินพุตเดิม → เอาต์พุตเดิม
ไม่มีความหน่วงของเครือข่าย
ไม่มีค่าใช้จ่ายในส่วนของ tokens
ทำซ้ำได้ใน CI
end note

note bottom of llm
อินพุตเดียวกัน → เอาต์พุตแปรผัน
ความหน่วงของเครือข่าย (1-5 วินาที)
ค่าใช้จ่ายโทเคน
ต้องมี API key
end note

@enduml

ประโยชน์ที่เป็นรูปธรรม:

ข้อได้เปรียบ ผลกระทบ

ความสามารถในการทำซ้ำได้

แม้แต่`graph.json`→ ไดอะแกรมเดียวกัน เป๊ะเลย ทุกครั้ง

ไม่มีค่าใช้จ่าย

ไม่มีการเรียก LLM = ไม่มีโทเคน = ไม่มีใบแจ้งหนี้ API

ความหน่วงเป็นศูนย์

Parse + render ใช้เวลาประมาณ ~100ms ไม่ใช่ 1-5 วินาที

CI ที่เข้ากันได้

ไม่ต้องใช้ API key ไม่เกิด flaky test จากการตอบสนองของ LLM ที่ไม่แน่นอน

สามารถกำหนดเวอร์ชันได้

Le .puml`ที่ถูกสร้างขึ้นคือข้อความ เราสามารถนำมันไป`diff, ผู้รีวิวใน PR, และการทำเวอร์ชันใน Git

แผนภูมิของตัว pipeline เอง

เพื่อให้ครบถ้วนสมบูรณ์ นี่คือแผนภาพของ pipeline ตามที่ปลั๊กอินจะสร้างขึ้น:

@startuml
skinparam backgroundColor #FEFEFE

participant "Développeur" as Dev
participant "Gradle" as G
participant "GenerateKnowledgeGraphDiagramTask" as Task
participant "KnowledgeGraphParser" as Parser
participant "KnowledgeGraphRenderer" as Renderer
participant "PlantumlService" as PS
collections "graphify-out/graph.json" as JSON
collections "diagrams/knowledge-graph/" as Out

Dev -> G : ./gradlew generateKnowledgeGraphDiagram
G -> Task : execute
Task -> JSON : read
Task -> Parser : parse(graph.json)
Parser --> Task : KnowledgeGraph

alt filtres actifs
    Task -> Task : appliquer filtres\n(community, edgeTypes, maxNodes…)
end

Task -> Renderer : render(graph, filters)
Renderer --> Task : code PlantUML

Task -> PS : validateSyntax()
alt valide
    Task -> PS : generateImage()
    PS --> Out : .puml + .png
else invalide
    Task -> Out : .puml (avec warning)
end

@enduml

การบูรณาการเข้ากับการกำกับดูแลโครงการ

ในโปรเจกต์ของเรา pipeline นี้จะรวมเข้ากับกลยุทธ์การจัดการบริบทแบบ EAGER/LAZY สำหรับเอเจนท์ AI โดย Knowledge Graph จะเข้ามาแทนที่เอกสารสถาปัตยกรรมแบบเขียนมือด้วยกราฟที่มีโครงสร้าง สามารถ query ได้ และอัปเดตตัวเองโดยอัตโนมัติ

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "EAGER\n(toujours chargé)" as eager {
    [PROMPT_REPRISE.adoc\n(contexte session)] as pr
    [INDEX.adoc\n(vue d'ensemble)] as idx
    [GRAPH_REPORT.adoc\n(~50 lignes)] as gr
}

package "LAZY — Stratégie\n(sur demande)" as lazy_strat {
    [Méthodologies] as meth
    [Archives sessions] as sessions
}

package "LAZY — Graphify\n(requêtes ciblées)" as lazy_graph {
    [graph.json] as gj
    [Queries\n(query/path/explain)] as queries
}

package "Pipeline PlantUML\n(auto-généré)" as puml {
    [generateKnowledgeGraphDiagram] as kgTask
    [generateDiagramDocs] as ddTask
    [Diagrammes PNG] as diagrams
}

Agent --> eager : Lit en début de session
Agent ..> lazy_strat : Charge si type détecté
Agent ..> lazy_graph : Query si besoin structurel
kgTask --> diagrams : Déterministe
ddTask --> diagrams : Via LLM

note right of gr
  Condensé du Knowledge Graph
  God nodes + communautés
  Remplace ECOSYSTEM_OVERVIEW
  (225 lignes → 50 lignes)
end note

@enduml

การผสานกันของทั้งสองระบบนั้นส่งเสริมกันและกัน:

  • กลยุทธ์จัดการเรื่อง เมื่อไหร่ และ อย่างไร— ธรรมาภิบาล, เวิร์กโฟลว์, การจัดเก็บเอกสาร

  • Graphify จัดการสิ่งที่ว่าคือ QUOI และอยู่ที่ `OÙ— โครงสร้างของโค้ด, ความสัมพันธ์, คำสั่งคิวรีที่เจาะจง

โปรดระบุข้อความภาษาฝรั่งเศสที่คุณต้องการให้แปลครับ กลยุทธ์ของเซสชันจะจัดการกับเมื่อใด et le ความคิดเห็น(ธรรมาภิบาล, เวิร์กโฟลว์, เกณฑ์), Graphify จัดการการอะไร et le ที่ไหน(โครงสร้างของโค้ด, ความสัมพันธ์, คำสั่งคิวรีที่เจาะจง) โดยที่ PlantUML pipeline จะจัดการกับด้วยอะไร(ไดอะแกรมแบบ deterministic, มีการกำหนดเวอร์ชัน และเป็นปัจจุบันเสมอ) โปรดระบุข้อความที่ต้องการให้แปลครับ

การเตรียมการ (Mise en place): รายการตรวจสอบใน 5 นาที

# ขั้นตอน คำสั่ง

1

ติดตั้ง Graphify

uv tool install graphifyy

2

กำหนดค่าการยกเว้น

สร้าง`.graphifyignore`

3

ดึงข้อมูล Knowledge Graph

graphify . --no-viz

4

สร้างไดอะแกรม

./gradlew generateKnowledgeGraphDiagram

5

Commit ผลลัพธ์

git add diagrams/knowledge-graph/

# Script complet en 5 commandes
uv tool install graphifyy
cat > .graphifyignore << 'EOF'
*-context.yml
*.env
build/
.gradle/
EOF
graphify . --no-viz
./gradlew generateKnowledgeGraphDiagram
git add graphify-out/GRAPH_REPORT.adoc graphify-out/graph.json diagrams/knowledge-graph/

กับดักและการบรรเทาผลกระทบ

กับดัก คำอธิบาย การบรรเทาผลกระทบ

กราฟหนาแน่นเกินไป

โปรเจกต์ขนาดใหญ่สร้างโหนดที่อ่านไม่ออกจำนวนหลายร้อยโหนด

ใช้งาน`-Pplantuml.kg.maxNodes=30`และกรองตามชุมชน

การยกเว้นที่กว้างเกินไป

มีไฟล์มากเกินไปใน`.graphifyignore`ลดค่าของกราฟ

เริ่มต้นด้วยการยกเว้นเฉพาะ credentials และ build เท่านั้น

ทิศทางของลูกศร

ขอบ INFERRED อาจมีทิศทางที่กำกวม

กรองโดย`-Pplantuml.kg.edgeTypes=EXTRACTED`สำหรับความสัมพันธ์ที่แน่นอนเท่านั้น

ตัวอักขระที่เลิกใช้แล้ว

โค้ดเปลี่ยนแต่กราฟไม่ได้ถูกสร้างใหม่

ใช้งาน`graphify . --update`เป็นประจำ หรือ git hook`graphify hook install`

ราคาที่อัปเดตแล้ว

การอัปเดตแบบเพิ่มส่วน (incremental updates) แทบจะไม่มีค่าใช้จ่าย (tree-sitter local)

เฉพาะเอกสาร (.adoc) ใช้โทเคน LLM

สิ่งที่เราได้รับในท้ายที่สุด

@startuml
skinparam backgroundColor #FEFEFE

rectangle "ก่อน" as avant {
    card "ไดอะแกรมที่วาดด้วยมือ\nล้าสมัยเสมอ\nไม่มีใครอัปเดต" as av1 #FDEDEC
}

rectangle "หลัง" as apres {
    card "ไดอะแกรมที่สร้างโดยอัตโนมัติ\nทันสมัยตามโค้ดเสมอ\nมีเวอร์ชันใน Git\nแน่นอนและทำซ้ำได้" as ap1 #E8F8E8
}

avant --> apres : graphify . --no-viz\n+ ./gradlew generateKnowledgeGraphDiagram

@enduml

ประโยชน์ที่เป็นรูปธรรม:

กำไร รายละเอียด

เอกสารที่ทันสมัยอยู่เสมอ

ไดอะแกรมสะท้อนถึงโค้ดปัจจุบัน ไม่ใช่ snapshot ด้วยตนเอง

ไม่ต้องดูแลรักษาเลย

ไดอะแกรมจะถูกสร้างใหม่ทุกครั้งที่มีการ build

การลดหนี้ทางเทคนิค

ไม่ต้องคอยดูแลรักษาไดอะแกรมด้วยตนเองอีกต่อไป

บริบททางภาพสำหรับผู้เริ่มต้น

นักพัฒนาคนใหม่ทำความเข้าใจสถาปัตยกรรมได้โดยการดูไดอะแกรม

ศักยภาพในการทำ Fine-tuning

คู่ (sub-graph → diagram) คือตัวอย่างสำหรับการฝึกสอน AI

การตรวจสอบความถูกต้องอัตโนมัติ

`PlantumlService.validateSyntax()`ตรวจสอบทุกไดอะแกรมที่สร้างขึ้น

การเริ่มต้นใช้งานอย่างรวดเร็ว

5 ไดอะแกรม = มุมมองสถาปัตยกรรมแบบครบถ้วน

โปรดระบุข้อความภาษาฝรั่งเศสที่คุณต้องการให้แปลครับ ผู้ที่มี เหตุผลว่าทำไม ย่อมสามารถทนต่อ วิธีการอย่างไร ได้ทุกรูปแบบ โปรดระบุข้อความที่คุณต้องการให้แปลครับ

เหตุผล (le pourquoi) : เพื่อให้ไดอะแกรมเป็นปัจจุบันอยู่เสมอ วิธีการ (le comment) : คำสั่งสองคำสั่งใน Gradle pipeline

ลิงก์

บทความที่เกี่ยวข้อง