Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
Видели noflojs.org?
Не видел. Сайт не открывается, посмотрел на гитхабе.
Да, похоже – во всяком случае, цели преследуются похожие.
У нас менее хипстерский получился вариант – посмотрим как пойдет!
Да, похоже – во всяком случае, цели преследуются похожие.
У нас менее хипстерский получился вариант – посмотрим как пойдет!
Хм, у меня открывается. Впрочем, это не совсем IDE, а фреймворк для построения приложений по архитектуре Dataflow, в любом случае это стоит посмотреть, как следующий логичный шаг.
Из IDE вспоминается Code Bubbles.
Из IDE вспоминается Code Bubbles.
- Если методы на полтора-два экрана – можно сделать их схлапываемыми или сделать карту масштабируемой. Как по мне – все равно это лучше чем бегать по строчкам. Работает память механическая, мозг не подключается для поиска слов по строчкам.
- Подключается на любой стадии. При первом запуске нода пробегается по всему src ища метки и генерирует файл aphs.json, на основании которого потом и идет работа.
- Примеров пока нет, не скоро будут – ставьте лайк, подписывайтесь, расскажите друзьям )
Ссылка правильная?
Визуальных языков программирования полно, такое решение удобно только на очень маленьких и простых задачах. Или речь только о навигации по готовому коду?
Вот демонстрационных примеров к статье бы побольше, а так, — интересно, спасибо.
почему за всю историю программирования не было придумано ничего подобного
Почему же не было… было. Если бы среди знакомых попались достаточно злые пользователи, например, дизассемблера IDA, они бы рассказали, что там используется имено такая визуализация.
(см. правую верхнюю часть картинки плюс флеш-анимацию в списке скринов, демонстрирующую использование фичи)
Примечательно в этом то, что речь идет о реверс-инжиниринге, т.е. анализе неизвестной, недокументированной системы на уровне исходного кода, т.е. о достаточно специфической области применения. А для разработки известных систем «больше 250 строк», для которой предназначены распространенные IDE, вроде WebStorm, укоренился несколько иной подход.
Есть такой чувак в проекте, называется архитектором. Вот он как раз и следит за соблюдением принципов SOLID и пр. хороших практик из CleanCode, приводящих к тому, что разработчику для внесения изменений в любую часть системы нет необходимости иметь пред глазами (или держать в голове) более 2-3 небольших кусков кода. А для этого возможностей этих IDE, включая рефакторинг, плюс, возможно, UML, более чем достаточно.
Так что, (мое сугубое IMHO), наличие подобного инструмента в IDE было бы, стратегически, скорее, контрпродуктивно, ибо только поощряло бы увеличение длинны спагетти. Я, конечно, преклонен перед проделанной работой и уверен, что это штука весьма полезная для расковыривания кривых недокументированных систем… просто пытаюсь сформулировать фидбек про актуальность: да, такой подход — последний джокер в рукаве, когда архитектора уже нельзя взять живьем и заставить как следует выполнить его работу.
Благодарю! Несколько проектов в которых я работал при всей величине (20-30 разработчиков) отчего-то не насчитывали архитектора, видимо, поэтому и сформировался такой запрос. А может быть и потому что в одном из них мне самому посчастливилось взять на себя эту функцию после 10 лет без такового. Широкий рынок довольно многообразен и, думаю, на нем больше игроков небольшого размера, без своего архитектора или на начальной стадии, когда как раз генерируется весь бардак, поэтому ниша найдется!
Уже со второго предложения идет очень субъективная подача: «логики — немцы, визуалы — русские».
Это ничего, что девелу иногда приходится представлять структуру кода не в 2- или 3-, а в X- (а то и Y-) мерном пространстве? Которое не то что нарисовать, а представить сложно.
И да — не стоит переоткрывать UML.
Это ничего, что девелу иногда приходится представлять структуру кода не в 2- или 3-, а в X- (а то и Y-) мерном пространстве? Которое не то что нарисовать, а представить сложно.
И да — не стоит переоткрывать UML.
Ну… Наверное. Наверное в пределах 1-3к строк оно полезно.
Т.е. немного больше одного модуля (200..500 строк) — и немного меньше более-менее развесистого клиент-серверного проекта от 5 килострок.
Своя ниша есть, согласен.
Примерно как с транспортом — пешком/ролики/самокат/велосипед/скутер/автомобиль/вертолет — почти не перекрывают друг друга.
Т.е. немного больше одного модуля (200..500 строк) — и немного меньше более-менее развесистого клиент-серверного проекта от 5 килострок.
Своя ниша есть, согласен.
Примерно как с транспортом — пешком/ролики/самокат/велосипед/скутер/автомобиль/вертолет — почти не перекрывают друг друга.
кажется, что они могут работать и с минифицированным кодом, пользуясь одной только функцией поиска
Справедливости ради — действительно можем. Да ещё и трассировать его в IE8.
andreiselin, можно Вас попросить сделать скрин связей aphs на примере… самого aphs?
Сослать визуалов в дизайнеры!
del
Интересная идея.
А кто может подсказать подобное для Python?
А кто может подсказать подобное для Python?
Спасибо — статья затрагивает очень интересную проблему блок-схем. Еще до ПК, когда в средних и высших учебных заведениях процветало так называемой «бумажное программирование», многие учебники настойчиво рекомендовали начинать написание даже простой учебной программы с блок-схемы. В какой-то книжке того времени (не учебник, издана в США) читал, что был произведен опрос среди профессиональных программистов об их отношении к блок-схемам. «За» и «против» разделились почти поровну. В современной литературе блок-схемы встречаются относительно редко, несмотря на то, что для их создания существует хорошо развитая инструментальная база (UML и т.д.).
Здесь не понял: разве современные IDE, основанные на технологии графического программирования GUI, не подобное? И появились эти среды разработки довольно давно: я, нпр., многие работы продолжаю делать на старом Delphi-7. В статье предложена нижняя планка проекта — 250 строк. Верхнюю планку предложу 10 тыс. строк. Для кода больших размеров может появиться дополнительная специфика. Программы с GUI, размер которых попадает в указанный интервал, зачастую начинают делать с формы главного окна, на которой размешают компоненты (кнопки, списки, ползунки и т.д.). Далее IDE помогает создавать обработчики событий мыши, клавиатуры и т.д. В результате возникает структура с классом формы главного окна. Куда обычно и добавляют вычислительные методы, т.к. их I/O завязан на компоненты формы. Вспомогательные функции, непосредственно не связанные с компонентами, бывает удобнее определять отдельно, не встраивая их в какой-либо класс в отдельном модуле или модулях. Если я правильно понял, то предлагаемый в статье инструмент будет полезен для работы именно с такими функциями вне ОО подхода?
Честно говоря, я удивлен и недоумеваю, почему за всю историю программирования не было придумано ничего подобного
Здесь не понял: разве современные IDE, основанные на технологии графического программирования GUI, не подобное? И появились эти среды разработки довольно давно: я, нпр., многие работы продолжаю делать на старом Delphi-7. В статье предложена нижняя планка проекта — 250 строк. Верхнюю планку предложу 10 тыс. строк. Для кода больших размеров может появиться дополнительная специфика. Программы с GUI, размер которых попадает в указанный интервал, зачастую начинают делать с формы главного окна, на которой размешают компоненты (кнопки, списки, ползунки и т.д.). Далее IDE помогает создавать обработчики событий мыши, клавиатуры и т.д. В результате возникает структура с классом формы главного окна. Куда обычно и добавляют вычислительные методы, т.к. их I/O завязан на компоненты формы. Вспомогательные функции, непосредственно не связанные с компонентами, бывает удобнее определять отдельно, не встраивая их в какой-либо класс в отдельном модуле или модулях. Если я правильно понял, то предлагаемый в статье инструмент будет полезен для работы именно с такими функциями вне ОО подхода?
Это несколько не то. раскидывание компонентов по форме — это не графическое программирование.
Графическое программирование — это когда ты алгоритм рисуешь а не набираешь текстом.
В делфи от графического только расположение компонентов на форме, а где связи между сущностями, где графическое представление алгоритма взаимодействия этих компонент и обработчиков событий? Вот это всё программист должен самостоятельно держать в голове и связывать с текстом программы и обработчиков. В этом есть большой недостаток. Даже чуть более сложная программа на одну форму — и разобраться в коде уже непросто. Вот эта вереница обработчиков нажатий на кнопки с длинными похожими друг на друга именами… что там от чего?
Графическое программирование — это когда ты алгоритм рисуешь а не набираешь текстом.
В делфи от графического только расположение компонентов на форме, а где связи между сущностями, где графическое представление алгоритма взаимодействия этих компонент и обработчиков событий? Вот это всё программист должен самостоятельно держать в голове и связывать с текстом программы и обработчиков. В этом есть большой недостаток. Даже чуть более сложная программа на одну форму — и разобраться в коде уже непросто. Вот эта вереница обработчиков нажатий на кнопки с длинными похожими друг на друга именами… что там от чего?
Графическое программирование — это когда ты алгоритм рисуешь а не набираешь текстом.Согласен. Но совсем без текста на таком рисунке не обойтись.
В делфи от графического только расположение компонентов на форме, а где связи между сущностями, где графическое представление алгоритма взаимодействия этих компонент и обработчиков событий?С этим не согласен. Вот пример кода игрового бота, о котором недавно рассказывал:
Нажав на шаблоне формы кнопку Открыть, в инспекторе объектов вижу список событий и их обработчиков, нажимаю на нужный мне обработчик и оказываюсь в нужном месте исходного текста, навожу курсор мыши на используемый метод (на снимке курсор не виден) и перехожу к этому методу по гиперссылке. ИМХО четкие и удобные связи, ничего в голове держать не надо. Имена могу давать любые.
Возможно, Вам покажется интересным следующий инструмент, который из исходного текста строит блок-схемы — он скорее для анализа кода:
Нет, это конечно связи но НЕ ГРАФИЧЕСКИЕ. И их всеравно нужно держать в голове т.к. IDE хоть и позволяет не ошибиться и перейти к нужному обработчику но когда их становится много и с ними надо работать настаёт момент когда срабатывает эффект дверного проёма — пока дойдёшь через форму(попробуй ещё найди нужный компонент среди нагромождения других) до обработчика(ага, ещё выбрать нужный из множества присоединённых к компоненту) забываешь что тебе там надо было сделать!
Второй пример это именно то что можно было бы назвать визуальным программированием, но увы построение диаграммы по коду это не программирование.
Самое что ни на есть визуальное программирование — это к примеру программирование на LAD и ему подобных языках. Туда же FLPROG, ArduBloсk и им подобное…
А делфи всё-таки не визуальное программирование, разве что на 10%...20%.
Второй пример это именно то что можно было бы назвать визуальным программированием, но увы построение диаграммы по коду это не программирование.
Самое что ни на есть визуальное программирование — это к примеру программирование на LAD и ему подобных языках. Туда же FLPROG, ArduBloсk и им подобное…
А делфи всё-таки не визуальное программирование, разве что на 10%...20%.
пока дойдёшь через форму(попробуй ещё найди нужный компонент среди нагромождения других)Ходить можно не только через форму, но и через Object Tree View. Представление в виде дерева самое удобное. Если в блок-схеме не предусмотреть скрытие не интересующих ветвей, то в сложной программе возникнет нагромождение, в котором трудно разобраться. Но блок-схема м.б. графом, который не является деревом — прятать лишние цепи в таком графе не очень наглядно. Еще для сложных программ блок-схемы приобретают катастрофические размеры. Конечно, экран можно сделать безграничным, но распечатка или отрисовка такой блок-схемы на бумаге потребует листа размером с Красную площадь.
Оно ещё менее наглядно чем визуальное представление. Немного лучше обычного линейного представления, но всё ещё нагромождение в котором надо рыться глазами.
Связи в графе прятать не надо, его надо правильно разделить на уровни, на каждом из которых информации не так много. Именно это и представляет главную трудность.
Связи в графе прятать не надо, его надо правильно разделить на уровни, на каждом из которых информации не так много. Именно это и представляет главную трудность.
Давайте уточним на примере с моей первой картинки. Уровень основной формы, далее уровень закладок на этой форме (Основная, Настройка, Тест, Роджерия и т.д.), далее компоненты управления на закладках — на основной это Дроид, ОМП и т.д., к ним относится инструментальная панель с кнопками Открыть, Справка, Выход. Для некоторых закладок кнопка Открыть не имеет смысла и прячется. Тут мы танцевали от «печки» GUI. На следующем уровне идут обработчики событий, а на следующем всякие вспомогательные функции, с GUI непосредственно не связанные. На мой взгляд, такое деление очевидно. Вы его имели в виду?
И говорится причем тут программирование? Оно визуальное, только расположение компонентов, а программирование по прежнему в сплошном плоском тексте. И связи компонентов с кодом тоже виртуальные и отнюдь не визуальные. Закрой Object Inspector и даже минимальной визуальной связи кнопочек с кодом не будет, в делфи это костыль без которого вообще нет жизни и от которого отказаться очень сложно. Как пример визуальности — если бы навёл на кнопочку на форме курсор а рядом всплыли визуально оформленные связи с кодом обработчиков, главными свойствами и т.д. которыми можно воспользоваться не отходя от кассы. Но увы, это тоже не совсем удобно становится при увеличении количества свойств и связей но это уже наглядней чем отдельная форма Object Inspector-а непонятно где обитающая в отрыве от объектов и кода. Её хочется просто выкинуть и не пользоваться, но по-другому пока нельзя.
Что-то Rational Rose вспомнилась.
Тоже идея показалась интересной. Данную проблему правда решаю расстановкой меток по коду. Они подсвечивались с боку на полосе прокрутке, по сему помогают ориентироваться. А вот в плане инструментария для меток, тут что только не заходит. В основном — это todo'шки и отключённые брейкпоинты.
Но всё же есть отались вопросы по инструменту:
Но всё же есть отались вопросы по инструменту:
- Он только для js? Реально ли его настроить под C++?
- Инструмент только под клиент-серверную архитектуру заточен? Его потенциально можно адаптировать например под плагин к IDE?
- Сейчас можно применить к любому синтаксису в котором не зарезервировано использование комментариев-меток вида /*-метка-*/ – что можно будет вскоре настроить.
Второе что можно будет настроить – это как раз файловая структура проекта. Сейчас заточено под стандартную схему фрнтендного проекта:
- корневая папка
- src (здесь — исходники, в которых aphs ищет разметку блоков)
- node_modules (сюда устанавливается aphs и отсюда работает по относительному пути с src)
- корневая папка
- Можно сделать плагин, мы делали с таким заделом. Когда node.js проходится по src, он сохраняет (или обновляет) в корень файл aphs.json — там находятся ссылки на файлы откуда брать и куда сохранять редактируемые в клиенте блоки кода и там же находится информация о контекстах, координатах блоков в них и тд. Надо продолжать использовать aphs.json, чтобы формировался единый стандарт – а в остальном смотреть серверный функционал в node_modules/aphs/aphs.js – там все односложно
Давно пользуюсь UML визуализатором под Eclipse. Устанавливаем этот плагин. Потом в существующем проекте создаем *.umls файл, перетаскиваем на его пустое поле все наши файлы из проекта — автоматом создаются UML блок схемы со связями. Щелкая на тот или иной блок нам открывается тот или иной класс из проекта. Т.к это Eclipse думаю поддерживается не только Java… Да если были внесены какие то изменения блок схема динамический меняется.
Java — типизированный язык. А вот как быть с нестрогой типизацией...
А в чем собственно вопрос? Разве в php к примеру нет классов\интерфейсов которые не изображаются в UML?
Не понял ваш вопрос. Меня интересует, удаётся ли автоматизировать построение UML по слабо типизированному языку?
Я думаю можно…
www.objectplayground.com
www.objectplayground.com
Это не блок-схема, это диаграмма классов. Такие штуки только ленивые не делают, в линейке IDE JetBrains это тоже есть. Кстати, code bubbles тоже как плагин к эклипсу идёт. И ещё кстати, на большом проекте они бесполезны, а на маленьком — не нужны. Поэтому мало кто ими пользуется, я думаю. Лучше уж вручную сделать диаграммы с нужными классами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускоряем разработку с помощью интерактивных блоксхем