|
Сообщение от Gozar
|
|
А по моему вполне реально такой парсер написать.
|
Основываясь только на именах - реально. Но всплывает много кейсов. Например, откуда парсер будет знать, что возвращает require? Конечно, можно ограничиваться именами, но как-то мало от этого пользы получается.
Если бы ты развил мысль на наглядном абстрактном примере... Т.е. код и полученная схема.
Ещё для такого парсера нужно брать какой-нибудь готовый статический анализатор. Ну и без поддержки JSDoc толку будет мало.
Цены бы не было такому парсеру, если бы он генерировал алгоритм наподобие этого:
Есть ещё один важный момент. Что бы диаграмма была более читабельной, необходимо иметь возможность управлять логикой её генерации. Например
здесь описана такая возможность, в разделе "Changing arrow direction". По опыту могу сказать, что без этого будет получаться, скажем так, не то. Например:
/*
@startuml
title The architecture of the site
skinparam componentStyle uml2
skinparam component {
BorderColor<<P>> #FF6655
}
component "Template Engine" as TEN <<P>>
component "Builder" as Builder <<P>>
component "Router" as Router <<P>>
component "Web Server" as Server
component "Data Base,\nCache" as DB
interface "HTTP(S)" as HTTP
Server -r- HTTP
HTTP .r.> Router: Proxy
package "Project" {
component "Static" as Stat
component "Templates" as TMPL
component "Applications" as Apps
interface "Data\naccess" as API
TMPL .r.> API
TMPL .d.> Builder: Configure
Apps -l- API
Apps .r.> DB
}
Router -r-> TEN
TEN -d-> TMPL: Rendering
Builder --> Stat: Build
HTTP .d.> Stat: Proxy
TMPL -u-> HTTP
note right of Builder: It works once at initialization
@enduml
*/
Результат:
Здесь практически для каждой связи используются указания направления (.d. - down, -r- - right и т.д.). Вот, что будет без них:
/*
@startuml
title The architecture of the site
skinparam componentStyle uml2
skinparam component {
BorderColor<<P>> #FF6655
}
component "Template Engine" as TEN <<P>>
component "Builder" as Builder <<P>>
component "Router" as Router <<P>>
component "Web Server" as Server
component "Data Base,\nCache" as DB
interface "HTTP(S)" as HTTP
Server -- HTTP
HTTP ..> Router: Proxy
package "Project" {
component "Static" as Stat
component "Templates" as TMPL
component "Applications" as Apps
interface "Data\naccess" as API
TMPL ..> API
TMPL ..> Builder: Configure
Apps -- API
Apps ..> DB
}
Router --> TEN
TEN --> TMPL: Rendering
Builder --> Stat: Build
HTTP ..> Stat: Proxy
TMPL --> HTTP
note right of Builder: It works once at initialization
@enduml
*/
Результат:
Читабельность явно пострадала.
Ну и ещё один момент. PlantUML может генерировать схемы разного типа. Парсер же кода - одного.
Но всё вышесказанное никак не должно восприниматься как попытка отговорить от этой затеи. Я лишь хочу показать подводные камни, которые могут возникнуть. Их скорей всего будет больше, я лишь привел те, что первыми пришли в голову.
В любом случае мысль интересная, я бы понаблюдал как минимум.
Главное чтобы мне было понятно. Мне особо без разницы, будут они красивые или просто шарик со стрелками в разные стороны. Мне нужно, чтобы я путь мог отследить. А для этого красота не очень важна. Но если получатся красивые, я буду только рад.
