Чем? Тут прикол в том, что сама диаграмма лежит в коде.

Да, но есть разные типы диаграмм:
Sequence Diagram - хорошо подходит для описания последовательности действий между некоторыми сущностями. Например, общение клиента и сервера.

Use Case Diagram - хорошо описывает взаимодействие пользователя(ей) с интерфейсом, сервисом и т.п.

Class Diagram - описывает структуру и отношение классов (конструкторов) между собой. Например, в Java такие диаграммы генерятся налету.

Activity Diagram - Component Diagram - показывает отношение компонентов и интерфейсов. Например, для описания архитектуры фреймворка или целого проекта.

State Diagram - описывает состояние некой сущности, например, конечного автомата или алгоритма.

Object Diagram - описывает объекты (списки, хеши) и отношение между ними.

Вроде припоминаю, но не уверен.
Ну не знаю... Может схема не удалась? Может не со всеми типами схем так?

Да, как и документация и тесты. Не нужно описывать каждую сущность в диаграмме. Программист сам должен понимать, где диаграмма будет полезна, а где нет. В каждом конкретном случае.

Для JS? Пруф?

:blink: Пидорг?!

Все диаграммы лежат в коде. Но суть в том, что это ещё один язык для изучения.

Это выражение нужны, я бы очень хотел получить такой пруф. Другими словами мне хотелось бы. Если осилю, то сам сделаю. Если нет, кто знает? ...

Я написал 3 диаграммы и уже чувствую себя уверенно. Каждая следующая пишется уже проще. Хотя тут на вкус, да. Но что-то лучше для создания UML я не нашел (в идеале - плагин для IDEA).
Могу завтра скинуть скрины, если интересно.

Какая ещё софтина позволяет читать диаграммы в коде?!

А, ну и мне хотелось бы, но такое невозможно для JS :)
Вот я и предложил вариант. Если немного поднапречься и потратить времени - в дальнейшем писать схемы будет уже не так сложно. Зато коллегам - неоценимая помощь :)

Я никого не принуждаю, если что :)

Кстати, при хорошем скилле, написать приличную схему можно за пол часа.
В визуальном редакторе получается не меньше.

Потратить 30-60 мин в неделю/месяц - не много.

И так появился UML... точнее в то время было много разных нотаций, а UML предполагался как "язык", который решит эту проблему, типа "одна универсальная нотация для всех".

Не могу похвастаться большим опытом в рисований диаграмм, как-то не было особой необходимости. Но когда возникала, я приходил к тому, что Enterprise Architect - лучший из имеющихся инструментов. Я пробовал использовать программы с более простым интерфейсом. Но это заканчивалось тем, что я сталкивался с невозможностью изобразить то, что мне нужно. PlantUML похож на один из таких вариантов. К тому же не уверен, что наличие диаграммы в коде - это плюс.

Это и не удивительно, пока не попробуешь - не узнаешь.

Почему?

Потому что в JS, в большинстве случаев, не возможно построить связь между объектами, так как нельзя с идентифицировать объект на 100%, как например в Java.

Gozar, почему ты просишь объяснять тебе очевидные вещи? Ты и сам должен был это знать...

В IDEA стандартная панель Structure может показать структуру объектов, описанных в файле, включая то, что есть в JSDoc. Но она не показывает связей между ними.

И вот так нельзя сделать?:

TSN.load = function (path, name, config) {
config = new Config(config);

var fullPath = LIB.path.join(config.templateRoot, path);

if (config.cache === true && TSN.cache.hasOwnProperty(fullPath)) {
return TSN.cache[fullPath];
}

config.path = LIB.path.dirname(fullPath);
return TSN.compile(LIB.fileSystem.readFileSync(fullPath, config.encoding), name || fullPath, config);
};

Могло бы превратиться в нечто подобное:

TSN.load = function {
LIB.path.join
TSN.cache
LIB.path.dirname
TSN.compile
LIB.fileSystem.readFileSync
};

А по моему вполне реально такой парсер написать.

По сути ты же переписываешь то же самое, только другими словами. А я ой как не люблю делать двойную работу.