DRAKON.SU

Прикольно!
Документация, в которой есть:
1. Структура вместо серых полей многа буков.
2. Ссылки на исходный код.

Приведенные выше графические решения, такие как mind maps, обладают существенным недостатком, являясь видом свертки, фолдинга, надежного упрятывания кода от своих собственных глаз.
Допустим, нам нужно ответить на простой вопрос, почему программа работает не так как надо в конкретном случае, что реально происходит, вот это или вот то, и как это поправить, и нужно ли?
Того, что мы увидим на mind map, будет совершенно недостаточно.
Придется 10 раз нажать в разные места mind map, чтобы открыть знакомое нам IDE и начать плодотворно работать возможностями текстового редактора, отыскивая кусок за куском кода.
Погрузиться в пучину кода, полагаясь на возможности своего ума соединить каким-то образом 10 обрывков кода отображемого IDE тут и там по одному с нескольких попыток, в уверенный ответ: "Да, программа в этом случае ведет себя так-то и так-то. Очевидно, проблема вот тут и вот там. Нужно поменять вот здесь и еще в паре мест, и все будет ОК".
Мind maps хороши лишь для вводной беседы, "high-level introduction" .
Но, как и IDE, они никак не помогают ответить на огромное количество простых вопросов, требующих детального знания кода.

+5! "Миссия невыполнима 2" состоялась значительно раньше.

А если серьезно, то возникает закономерный вопрос к Olegar: У Вас есть решение как победить растущую общую сложность проектов так сказать "кардинально"? Поделитесь пожалуйста..

вот в этом то и дело, что low level introduction в виде кода уже есть, а тот кто может сделать high level introduction обычно всегда уволился месяц назад и отключил телефон и никто уже не знает что где лежит и за что отвечает

У Олега есть такое решение — с помощью языка ДРАКОН.

Олег, я правильно Вас понял?
Вы действительно считаете, что трудности, которые испытывают 9 миллионов Java-программистов и 4 миллиона Си-шарп-программистов можно устранить или ослабить с помощью языка ДРАКОН?

Или нет?
viewtopic.php?p=99523#p99523

Именно. Это две разные вещи. Mind map для общего описания подходит хорошо. Но хотелось бы большего. А именно — понимать сам код.
Вот у Олега есть инструмент для этого. Он сделал мощный плагин для эклипса.
Я же стараюсь понять, имеет ли смысл сделать ещё один. Такой, что представит код в виде графа с входами и выходами. Чтоб видеть "откуда ноги растут" © и "куда деньги уходят". Для одного себя делать не хочу. Интересно узнать, надо ли это людям.

а что за плагин?

В целом для работы с кодом и данными проектов на любых языках я предлагаю визуальную программу Интегратор, описанную на http://integratorsoft.com/ . Эргономичное интегрированное отображение и контроль данных и алгоритмов проектов произвольной сложности без больших усилий.

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

Устраняя визуальные и эргономические помехи и препоны, воздвигаемые IDE, Дракон позволяет увидеть алгоритмы кода в прекрасной ясности при свете дня под безоблачным небом.
Внезапно то, что требовало часов скитаний по ползункам текстовых монстров, становится очевидным, и можно перестать стучать по клавиатуре и мыши.

Повернули глаза туда и сюда, показали пальцем туда и сюда, произнесли вслух пару-тройку замечаний там и тут.
А задача то и решена, вот такими смешными усилиями. И ни одна из проблем описанных выше не случилась. IDE, где твое жало?

Плагин к Eclipse, который делает это и многое другое, называется Integrator CodeView (Basic Edition) и находится на http://integratorsoft.com/codeview/

А вот это уже интересно.. смотреть детально видео - пока ещё не смотрел, слишком мелко на самом сайте. Да, и ещё не нашел кнопки "download" .. по какой ссылке можно скачать и установить в Эклипс чтобы попробовать.
Начиная с какой версии Эклипса плагин подключается?

Считаю, что это очень важный список.

Желательно по каждому из 12 пунктов дать подробное и убедительное разъяснение с примерами, кодами и пр. (примерно 5-10 страниц по каждому пункту).

Перед этим желательно упорядочить список по важности, начиная с наиболее важных пунктов и кончая наименее важными.

бОльшая часть проблем прочитать и понять программу сегодня, это всеж проблема не представления, а того, что часто пишут полные балбесы без стиля и опыта, на выходе мы имеем "работающую кашу" которая удовлетворяет бизнес потому что "быстро наклепали и работает", в свое время для крупного заказчика одна компания разработала важный продукт в котором внутри был полный хлам, на мой недоуменный вопрос к раработавшему "а почему так?" был ответ - "а что ты хочешь, мне на разработку работающего прототипа дали три дня!", потом этот продукт поддерживался и развивался компанией лет 10

В.Д., я не очень понимаю почему так важно описывать детали страданий разработчиков на 100 страниц?
Они сами это точно читать не будут.

Вы думаете это убедит кого-то к поиску новых средств, таких как http://integratorsoft.com/codeview чтобы решить их проблемы?
Невзирая на все предубеждения о том что "визуальные" средства - "было что-то в прошлом веке - а, Microsoft Visual Basic, да? там все всегда было ОК!"
Это как убеждать больных идти к врачу с помощью публикации статьи в медицинской энциклопедии.

Любой скриншот IDE - картина мучения и невозможности объять - далеко не необъятное, а всего-навсего 10 важных use-cases, вариантов использования проекта в режиме симультанности. При появлении 10 вызовов и связей в каждом из них, разумная беготня в маленьких окошках по 100 кускам кода в разной последовательности для поиска ответов на 10 простых вопросов в больших файлах возможна, но далеко не в режиме реального времени, так как это очень трудно, наступает усталость, а не желание и возможность решить еще больше проблем.

Иногда разработчики думают: "да, мы ежедневно мучаемся используя IDE, но нам за это платят деньги. Если отменить IDE, нас всех уволят". Это как в до-компьютерную эпоху думать, что "придут компьютеры - всех сократят, компьютеры будут сами все считать".

Иногда разработчики думают: "я хорошо знаю код проекта, и потому незаменим. Пусть все так и остается, IDE мне поможет - другим будет трудно разобраться, и меня не сразу уволят. Мне не нужны симультанные визуализаторы. "

Иногда разработчики думают: "да, не все так гладко конечно в IDE. Запарился на прошлой неделе, исправляя баги. Извини, старик, нужно бежать на митинг, давай, пока!"

Олег, вы правы. Нельзя писать то, что люди "точно читать не будут".
Надо писать то, что люди будут читать с интересом.

Олег, этот отрывок показывает, что вы прекрасно владеете словом и умеете использовать красивые метафоры.

Олег, вы задумали революцию. Разумеется, я вас полностью поддерживаю.

Каким же образом можно осуществить задуманную вами революцию на практике?

Мне кажется, надо написать книгу примерно 200 страниц. (В книгу можно вставить диск, но про диск я пока говорить не буду).

Итак, надо написать книгу в 200 страниц.
Первая половина (100 страниц) — постановка проблемы и объяснение: зачем это нужно? Зачем нужна задуманная вами революция.
Постановка проблемы должна быть величественной, смелой, острой и вместе с тем деликатной.

Вторая половина — решение задачи с помощью вашего плагина.

Ваш плагин еще не вполне готов? Пусть так. Для книги 100%-я готовность плагина не нужна.
А что нужно? Нужно показать скриншоты ваших дракон-схем и сопровождающие их примеры и коды.

Здесь есть тонкость. На Вашем сайте вы демонстрируете огромные дракон-схемы. Такие большие дракон-схемы для книги не годятся. Самая большая дракон-схема должна помещаться в книжный разворот (две смежных книжных страницы). В крайнем случае два смежных книжных разворота (то есть 4 страницы).

Отсюда следует, что гигантские дракон-схемы придется дробить на части и (в учебных целях!) показывать в книге по частям. В соответствии со стандартами книжного дела.

Вывод

Задуманную вами революцию я представляю в виде книги. Мне кажется, что систематически написанная книга, излагающая ваши идеи — это эффективный путь к достижению ваших целей.

https://www.youtube.com/watch?v=wlWO4F6iLe4

Что думают разработчики, давайте оставим на вашей совести. Как понимаю полноценного исследования Вы - не проводили.

Выделил ровно то, что относится к скриншоту ниже. Просто попытался в нормальном масштабе понять что на приведенной картинке. Что я сделал не так?

Да, код и IDE - это пол-беды, программная ее составляющая.
Существует и аппаратная проблема: все, что есть у разработчика для того чтобы смотреть на мир - это малюсенький экран перед которым он сидит.
Например 1400 на 800 пикселей. Ну максимум два таких экрана у супер-профессионалов.
Попытка смотреть на Дракон диаграммы через такую щелку на читаемом разрешении проваливается - всю диаграмму просто не видно, как показано на картинке выше.
Ай яй яй, а еще хуже придется владельцам модных телефонов, или таблетов, не говоря уж о наручных часах.
Что делать? (Кстати, только что перечитал эту книгу Чернышевского - рекомендую).

1) Перечитать книги В.Д.Паронджанова о распечатке алгоритмов на бумаге. Бумаги много, и печатать на ней дешево, CodeView легко делает распечатки 3 на 1.8 метра с разрешением 12000 на 7000, примерно в 78 раз больше пикселей чем на экране разработчика, т.е. можно легко увидеть то, для чего на маленьком экране как минимум 100 раз придется ткнуть и потерять все виденное прежде.

2) В CodeView eсть и несколько других вариантов решения этой проблемы, как описано в руководстве.
Работаeт на "Java 64 bit" в Eclipse Neon (4.6), Eclipse Mars (4.5), Eclipse Luna (4.4), Eclipse Kepler (4.3), Eclipse Juno (4.2) etc.

То есть, вы предлагаете каждому программисту приобрести широкоформатный плоттер не уже 1.8м, а дополнительно выделить ему "рабочий стол" не менее 3х1.8м рядом с имеющимся рабочим местом с каким-нибудь типовым 4-х ядерным компом о 8-ю гектарах оперативы и полутеррабайтным винтом с парой экранов 22" и разрешением 1920х1080, которые к примеру и так стоят на моем рабочем столе габаритом 1.4 х 0.8м?!?

Ну, не знаю .. я не против, если сосед отсядет от меня на 3 метра .. но вот бегать промеж столов как-то не готов. Да и постоянно пищащий плоттер надоест хуже горькой редьки, а если за распечаткой ещё и в соседнюю типографию ходить придется, то я точно буду против. Не, если к каждому программисту законодательно прикрепят "девочку за распечаткой" (а если она ещё и кофе с булками таскать будет..), то наверное стоит подумать..

Озадачили .. надо будет поднять вопрос на очередном совещании, тем более типография - "своя", широкоформатников аж 3шт., самый "тот" аж на 5 метров шириной, правда 1кв.м. баннера стоит что-то рублей 500 ... На Вас сослаться, как на "передний край науки" - можно?

Плоттера достаточно одного на компанию, его можно поставить в подвал, чтобы не слышно было.
А 10-минутная прогулка в типографию в обеденный перерыв даже полезна для здоровья.
5 метров - это круто, но в моих экспериментах диаграммы выше 2 метров трудно охватить взглядом, надо либо приседать, либо карабкаться на лесенку, либо летать.
Совещания часто проводят в местах, способных вместить диаграмму 3 на 1.5 метра, а использование точных визуализаций именно для коллективной работы мне кажется способно дать максимальный эффект.

Я сильно подозреваю, что даже 5м ширины плоттера будет недостаточно. Видел процесс проектирования у коллег ядра(!) SQL базы для CRM системы .. всего 52 таблицы и только диаграмма отношений с трудом влезала в формат А0. Сейчас, у других коллег, подобная CRM система содержит 1028 таблиц за 10 лет развития .. и программируется все эти 10 лет .. упс 1 бессменным и 1-3 периодически нанимаемыми программистами. И это ТОЛЬКО SQL-слой, в реализации вся логика сделана на "SQL-клиенте" - сервере приложения. Так что "сколько там потребуется" километров простыней, мне даже представить сложно. И это - практически средний объем ПО для предприятия. Так на sql.ru можно найти программистов от Алмаз-Антей для примера архитектуры их СУБД (само перестраиваемая СУБД от EAV к RM по мере актуализации наборов данных, как сам понял) .. очень познавательно.

"Миссия невыполнима", ибо Козьма Прутков - прав. Вот на все 146%.

P.S. Да, про каждому по плоттеру, я не зря написал. Это для совещаний промеж (не)коллег возможно и полезно собраться вместе "за рюмкой чаю" у большой доски и побегать по здоровенному баннеру глазами (кстати, как уместить больше 2-х человек возле одного места, отпечатанного даже 14-м кеглем?) и порассказывать всем что это влияет на то и тп.

Но, Вы высказывали недовольство сложным процессом поиска точек входа/выхода (и этого нет сейчас в ИДЕ, верно) для оперативного затыкания ноды багтреккера .. и? Предлагаете каждому, взявшему тикет на решение бежать в переговорку, где висит эта "портянка"? Или так: взял тикет, отпечатал нужный кусок схемы, ибо в экран лезет ЕЩЁ МЕНЬШЕ чем текста, и побежал в "подвальчик". К примеру, работаю на 1-м этаже, а наша типография стоит на 3-м .. и этажи - "промышленные", высота потолков 5м., считай 5-й этаж хрущевки .. Закрыл тикет за полчаса, взял следующий и .. снова "физкультура", так что ли? Не, "не согласная я" .. давайте тогда каждому по плоттеру ставить.
Да, и как быть нашему, удаленному отделу разработки? Один сидит в другом конце города Новосибирска, второй в Петербурге, третий где-то на Сахалине я даже и не знаю где .. а начальник отдела почти постоянно тусуется в Таиланде, приезжает на неделю каждые 3мес., чтобы визу обновить. Как им быть?

О! бедные разработчики, ладно бы дело ограничивалось одной Java с алгоритмами, но ведь есть еще и слой SQL. Сервер базы данных, 'визуальные' средства ER и UML, язык запросов SQL: Select, Insert, Update, Delete. И что, в чем проблема?



1) Диаграмма отношений, entity–relationship (ER) model diagram (она же в UML диаграмма классов плюс-минус загогулинки), содержит только имена колонок, полей, переменных. Она не содержит ни одного значения данных из записи в таблице, предполагается, что конечно же все значения взаимосвязанных записей в разных таблицах с легкостью возникают у нас в уме, просто при взгляде на прямоугольничек с именами колонок в абы каком порядке.
Но так ли это? Ведь для ответа на любой конкретный содержательный вопрос о данных, наличия ER или UML диаграммы будет совершенно недостаточно, потому что никаких данных на этой диаграмме не показано вообще!
Эксперт с такой диаграммой в руке или на стене или на компе, будет поставлен в тупик простым вопросом: "А что у нас не так в базе данных с пользователем user35?" - печально.

2) А для ответа потребуются многочисленные трудоемкие ручные SQL запросы, к 10, 100, 1000 таблиц, не запутаться в которых невозможно, а пропускная способность с созданию разработчиком длинных последовательностей безупречных отлаженных SQL запросов сильно ограничена.
Помощь в этом деле от ER или UML скорее пассивная - работающий SQL диаграмма не напишет и количество этих SQL не сократит.
По большей части (в смысле визуального объема), ER или UML Class диаграммы - просто списки таблиц с колонками - эту информацию легко увидеть в любом SQL клиенте ткнув в папку Tables.

Таким образом видим, что у разработчика очень фрагментарный, ограниченный, трудоемкий путь доступа к данным в SQL или No-SQL сервере.
А средства визуального представления баз данных, используемые профессионалами, такие как ER диаграммы и UML диаграммы классов, обладают роковым недостатком и совершенно бесполезны для реальной работы с данными.

Все это порождает легенды о нестерпимой сложности, невыполнимости и необъятности проектов с базами данных из 50 таблиц или 1000 таблиц.
На сайте http://integratorsoft.com есть примеры того, как такие задачи легко решаются.
Например в разделе об известной медицинской базе данных ClinVar (https://www.ncbi.nlm.nih.gov/clinvar/) продемонстрировано приложение базы данных с сотнями таблиц. Для неспешной разработки таких проектов в течение одного дня и создан Integrator.