[видео] Code Bubbles концепция
интересно, спасибо.
Такая очевидная вещь, сто раз уже обдумывал. Неужели ни в одной mainstream среде нет?
Нарушение принципа KISS мне в этом видится.
Если бы это оформили как плагин к Идее, то обязательно бы пользовался, а так, думаю, будет очень не хватать фичей нормальной IDE. Но попробовать, конечно, интересно....
Update:
Прочитал, что сделано на базе Эклипса
Жаль, конечно, что не Идея, но уже стало интересней.
Update:
Прочитал, что сделано на базе Эклипса
Жаль, конечно, что не Идея, но уже стало интересней.да нет. Я давно уже о такой штуке мечтаю. Сейчас все IDE текст-based, максимум что есть - это folding.
Всё это от того, что проекты компилируются в текстовом виде. Но кто сказал, что внутреннее представление должно быть текстовым.
Простыня в тему. Когда-то меня один знакомый спросил, какого рода IDE я хотел бы иметь (у него есть глупый проект по созданию IDE на базе гуглоапсов). Тогда я расстарался написать побольше требований, но переполнить его буфер памяти не удалось, а текст остался.
IDE нового поколения.
Сначала проанализируем сложившуюся технологию разработки ПО, рассмотрим автоматизируемые и сугубо творческие фазы разработки и выделим требования к IDE, позволяющие максимально упростить и автоматизировать процесс создания приложений.
Если рассмотреть в общем, то есть несколько крупных фаз цикла разработки ПО, возможно циклически повторяемых. Сначала идёт, оценка коммерческой рентабельности, поиск ниши, составление бизнес плана. Потом следует изучение пожеланий клиентов, составление их требований. Затем требования клиентов превращаются в ТЗ и согласуются с заказчиком и исполнителями. После того идёт этап собственно разработки: многократно повторяемые моделирование, программирование, отладка, тестирование. После чего идёт этап тестирования. На этом цикл завершается и начинается новый виток разработки и анализ уже завершённого.
Меня как программиста более всего интересует этап разработки. Рассмотрим подробнее какие процессы протекают в этот момент.
1) Моделирование, создаются различные UML модели.
2) Создание программного кода
3) Создание технической документации
4) Проведение модульного тестирования
5) Поиск идей реализации
Последний пункт наиболее творческий, и его редко рассматривают, полагая слишком расплывчатым, чтобы быть определённым в какой-либо стандартной модели разработки. Всякий программист, прежде чем начать писать код набрасывает для себя какие-то заметки на бумажке, структурируя своё решение столь неформальным методом. Но зачем переводить бумагу, когда есть компьютер? Не будет ли более верным оставлять эти записки в нём?
Кроме перечисленных аспектов процесса разработки, IDE должна также автоматизировать работу с системой контроля версий для локального хранения всей истории разработки и для взаимодействия между несколькими участниками процесса разработки.
Всё это в той или иной мере современные универсальные IDE умеют делать. Но не умеют они делать главного: объединять все аспекты разработки в одном проекте.
Что умеют современные IDE:
1) UML моделирование
2) Упрощают набор кода
3) Поддерживают систему контроля версий
4) Иногда поддерживают автоматизацию тестирования
Всю остальную функциональность поддерживают либо внешние средства, либо система костылей и подпорок, либо вовсе ничего. И разумеется никакой связи и интеграции между этими средствами не наблюдается.
Что именно в нынешнем цикле разработки приходится выносить за пределы IDE:
1) Документацию: для неё используются комментарии специального вида и программы-генераторы документации по этим комментариям
2) Модульное тестирование: специальные наборы для тестирования, состоящие из внешних программ и внутренних библиотек. Иногда их вызов включают в общий makefile для сборки проекта, иногда запускают вручную.
3) Связь документации и программного кода, в том числе в системе контроля версий, благодаря генерируемой природе документации.
Чего принципиально нет вообще:
1) Создания связи между программным кодом и UML схемами. Сейчас программа соответствует своей модели только несколько первых недель разработки
2) Реализации MindMap для использования при мозговом штурме вместо листочков бумаги.
3) Связи UML и модульной проверки кода (из UML нужно извлекать ограничения, которые имеет смысл вносить в соответствующие модули проверки)
4) Связи между кодом и MindMap.
Итого, рассмотрим получившийся список требований к IDE:
Работа с кодом.
Стандартный набор полезного функционала:
0)Модули для подгрузки правил определённого языка. В проекте может быть несколько разных языков, значит IDE должно быть универсальным. При этом функции должны оставаться одними и теми же, а реализации быть разными. А не то, что в eclipse - каждый плагин имеет разные фичи.
1)Подсветка синтаксиса
2)Автодополнение (с выбором вариантов дополнения)
3)Шаблоны (парные скобки, оператор for со всеми необходимыми знаками препинания и тому подобное)
4)Фолдинг (представление кода в дерявнной структуре и соответствующие операции по скрытию и раскрытию ветвей)
5)Поиск определений функций, классов, переменных, модулей, быстрый переход к ним.
6)Возможность показывать результаты предыдущего пункта в отдельном маленьком окне автоматически по мере фокусировке в главном окне на той или иной лексеме.
7)Подсветка текущих структур кода, например простых или операторных скобок и выражения, в них заключённого.
8)Демонстрация в отдельном окошечке (возможно всплывающем) документации по вызываемой функции, если она есть, и заголовка функции в противном случае
Расширенный набор (уникальные ненужные фичи, стукнувшие мне в голову)
1)выборочная подсветка синтаксиса (высвечивать все объявления переменных, заголовки циклов, etc) с возможностью перехода между ними и ограничения области поиска
2)возможность оставлять пометки в определённом месте кода и быстро к ним переходить
3)возможность сохранять определённые конфигурации дерева fold и быстрой смены контекста отображения
Работа с отладкой:
1)Возможность исполнения по шагам (пауза после каждого шага)
2)Возможность выставления брейкпонтов на определённое место в коде, обращение к переменной, запись в переменную с возможность добавить срабатывание по проверке условия либо по счётчику.
3)Возможность просматривать набор переменных в отдельном окне и в всплывающих подсказках
4)стек вызовов для случая однотердового приложения, дерево вызовов для многотредового.
5)Счётчики профилировщика: выделенная память и потреблённое процессорное время. Отображение как в отдельном окне, так и во всплывающих окнах при наведение на функции.
6)Другие полезные индивидуальные фичи дебагера.
Интеграция
1)Интеграция с системой контроля версий, которая сохраняет в локальном репозитории автоматически каждую успешно компилируемую версию программы. (обычно программист завершив написание функции запускает её компиляцию с тем, чтобы обрабатывать свои опечатки небольшими порциями). Понятное дело, таким образом будет сгенерировано множество промежуточных малополезных версий, которые со временем можно будет слить в одну.
2)Работа с локальным и глобальным репозиторием. Возможность организации code review для глобального репозитория.
3)Документацию и код должен создавать один и тот же человек в один и тот же интервал времени. Поэтому при апдейте глобального репозитория следует следить за целостностью этой пары, не давая их апдейтить независимо друг от друга. UML модели бывают проектные (изначальные) и фактические (после обработки программистами). Так что апдейтить UML схемы нужно в связке с кодом, и создавать соответствующие ветви репозитория, которые на перво
Всё это от того, что проекты компилируются в текстовом виде. Но кто сказал, что внутреннее представление должно быть текстовым.
Простыня в тему. Когда-то меня один знакомый спросил, какого рода IDE я хотел бы иметь (у него есть глупый проект по созданию IDE на базе гуглоапсов). Тогда я расстарался написать побольше требований, но переполнить его буфер памяти не удалось, а текст остался.
IDE нового поколения.
Сначала проанализируем сложившуюся технологию разработки ПО, рассмотрим автоматизируемые и сугубо творческие фазы разработки и выделим требования к IDE, позволяющие максимально упростить и автоматизировать процесс создания приложений.
Если рассмотреть в общем, то есть несколько крупных фаз цикла разработки ПО, возможно циклически повторяемых. Сначала идёт, оценка коммерческой рентабельности, поиск ниши, составление бизнес плана. Потом следует изучение пожеланий клиентов, составление их требований. Затем требования клиентов превращаются в ТЗ и согласуются с заказчиком и исполнителями. После того идёт этап собственно разработки: многократно повторяемые моделирование, программирование, отладка, тестирование. После чего идёт этап тестирования. На этом цикл завершается и начинается новый виток разработки и анализ уже завершённого.
Меня как программиста более всего интересует этап разработки. Рассмотрим подробнее какие процессы протекают в этот момент.
1) Моделирование, создаются различные UML модели.
2) Создание программного кода
3) Создание технической документации
4) Проведение модульного тестирования
5) Поиск идей реализации
Последний пункт наиболее творческий, и его редко рассматривают, полагая слишком расплывчатым, чтобы быть определённым в какой-либо стандартной модели разработки. Всякий программист, прежде чем начать писать код набрасывает для себя какие-то заметки на бумажке, структурируя своё решение столь неформальным методом. Но зачем переводить бумагу, когда есть компьютер? Не будет ли более верным оставлять эти записки в нём?
Кроме перечисленных аспектов процесса разработки, IDE должна также автоматизировать работу с системой контроля версий для локального хранения всей истории разработки и для взаимодействия между несколькими участниками процесса разработки.
Всё это в той или иной мере современные универсальные IDE умеют делать. Но не умеют они делать главного: объединять все аспекты разработки в одном проекте.
Что умеют современные IDE:
1) UML моделирование
2) Упрощают набор кода
3) Поддерживают систему контроля версий
4) Иногда поддерживают автоматизацию тестирования
Всю остальную функциональность поддерживают либо внешние средства, либо система костылей и подпорок, либо вовсе ничего. И разумеется никакой связи и интеграции между этими средствами не наблюдается.
Что именно в нынешнем цикле разработки приходится выносить за пределы IDE:
1) Документацию: для неё используются комментарии специального вида и программы-генераторы документации по этим комментариям
2) Модульное тестирование: специальные наборы для тестирования, состоящие из внешних программ и внутренних библиотек. Иногда их вызов включают в общий makefile для сборки проекта, иногда запускают вручную.
3) Связь документации и программного кода, в том числе в системе контроля версий, благодаря генерируемой природе документации.
Чего принципиально нет вообще:
1) Создания связи между программным кодом и UML схемами. Сейчас программа соответствует своей модели только несколько первых недель разработки
2) Реализации MindMap для использования при мозговом штурме вместо листочков бумаги.
3) Связи UML и модульной проверки кода (из UML нужно извлекать ограничения, которые имеет смысл вносить в соответствующие модули проверки)
4) Связи между кодом и MindMap.
Итого, рассмотрим получившийся список требований к IDE:
Работа с кодом.
Стандартный набор полезного функционала:
0)Модули для подгрузки правил определённого языка. В проекте может быть несколько разных языков, значит IDE должно быть универсальным. При этом функции должны оставаться одними и теми же, а реализации быть разными. А не то, что в eclipse - каждый плагин имеет разные фичи.
1)Подсветка синтаксиса
2)Автодополнение (с выбором вариантов дополнения)
3)Шаблоны (парные скобки, оператор for со всеми необходимыми знаками препинания и тому подобное)
4)Фолдинг (представление кода в дерявнной структуре и соответствующие операции по скрытию и раскрытию ветвей)
5)Поиск определений функций, классов, переменных, модулей, быстрый переход к ним.
6)Возможность показывать результаты предыдущего пункта в отдельном маленьком окне автоматически по мере фокусировке в главном окне на той или иной лексеме.
7)Подсветка текущих структур кода, например простых или операторных скобок и выражения, в них заключённого.
8)Демонстрация в отдельном окошечке (возможно всплывающем) документации по вызываемой функции, если она есть, и заголовка функции в противном случае
Расширенный набор (уникальные ненужные фичи, стукнувшие мне в голову)
1)выборочная подсветка синтаксиса (высвечивать все объявления переменных, заголовки циклов, etc) с возможностью перехода между ними и ограничения области поиска
2)возможность оставлять пометки в определённом месте кода и быстро к ним переходить
3)возможность сохранять определённые конфигурации дерева fold и быстрой смены контекста отображения
Работа с отладкой:
1)Возможность исполнения по шагам (пауза после каждого шага)
2)Возможность выставления брейкпонтов на определённое место в коде, обращение к переменной, запись в переменную с возможность добавить срабатывание по проверке условия либо по счётчику.
3)Возможность просматривать набор переменных в отдельном окне и в всплывающих подсказках
4)стек вызовов для случая однотердового приложения, дерево вызовов для многотредового.
5)Счётчики профилировщика: выделенная память и потреблённое процессорное время. Отображение как в отдельном окне, так и во всплывающих окнах при наведение на функции.
6)Другие полезные индивидуальные фичи дебагера.
Интеграция
1)Интеграция с системой контроля версий, которая сохраняет в локальном репозитории автоматически каждую успешно компилируемую версию программы. (обычно программист завершив написание функции запускает её компиляцию с тем, чтобы обрабатывать свои опечатки небольшими порциями). Понятное дело, таким образом будет сгенерировано множество промежуточных малополезных версий, которые со временем можно будет слить в одну.
2)Работа с локальным и глобальным репозиторием. Возможность организации code review для глобального репозитория.
3)Документацию и код должен создавать один и тот же человек в один и тот же интервал времени. Поэтому при апдейте глобального репозитория следует следить за целостностью этой пары, не давая их апдейтить независимо друг от друга. UML модели бывают проектные (изначальные) и фактические (после обработки программистами). Так что апдейтить UML схемы нужно в связке с кодом, и создавать соответствующие ветви репозитория, которые на перво
Читаешь мои мысли, сцуко! Ну, кроме длинного перечисления фишек, которые в современных ИДЕ тоже в общем-то есть. И не очень интересующей меня фигни про интеграцию с UML, которая, к слову, в самой современной из всех IDE тоже есть.
Я бы ещё вот что добавил: вообще эта штука нечеловечески напоминает IDE для Smalltalk. Сейчас уже не найду то видео на ютубе, но суть такова: смаллталк хоть и динамический, но prototype based. Поэтому то, что они сейчас делают для жавы, делалось там легко: все классы на самом деле являются самыми обычными объектами, так что скомпилированная жава эквивалентна живому набору смаллталковских объектов, которые мы хотим считать классами типа. Причём, насколько я понимаю, у них там изначально всё было GUI-based, экспорт в текст прикручивали сильно после, а так — вот есть у тебя Image с живыми классами, можно в нём добавлять и редактировать методы, можно порождать из них инстансы, редактировать что угодно етс. Вот есть объект "меню", вот ты из него порождаешь объект "моё меню" и добавляешь туда конкретные айтемы, причём если кликаешь в айтем левой кнопкой, то он выполняет соответствующее действие, а если правой, то выскакивает менюшка с мета-действиями, типа изменить текст, перейти к редактированию кода, всё такое.
Оно всё как бы умерло в силу двух причин, с одной стороны, все IDE/интерпретаторы (там же невозможно было отделить одно от другого!) стоили диких денег, с другой — подобный подход означал, что невозможно было просто дать другому чуваку сурцы куска своей программы, потому что она существовала в IDE, и передать можно было только целый Image. Ну вот здесь подобных проблем вроде нет.
Я бы ещё вот что добавил: вообще эта штука нечеловечески напоминает IDE для Smalltalk. Сейчас уже не найду то видео на ютубе, но суть такова: смаллталк хоть и динамический, но prototype based. Поэтому то, что они сейчас делают для жавы, делалось там легко: все классы на самом деле являются самыми обычными объектами, так что скомпилированная жава эквивалентна живому набору смаллталковских объектов, которые мы хотим считать классами типа. Причём, насколько я понимаю, у них там изначально всё было GUI-based, экспорт в текст прикручивали сильно после, а так — вот есть у тебя Image с живыми классами, можно в нём добавлять и редактировать методы, можно порождать из них инстансы, редактировать что угодно етс. Вот есть объект "меню", вот ты из него порождаешь объект "моё меню" и добавляешь туда конкретные айтемы, причём если кликаешь в айтем левой кнопкой, то он выполняет соответствующее действие, а если правой, то выскакивает менюшка с мета-действиями, типа изменить текст, перейти к редактированию кода, всё такое.
Оно всё как бы умерло в силу двух причин, с одной стороны, все IDE/интерпретаторы (там же невозможно было отделить одно от другого!) стоили диких денег, с другой — подобный подход означал, что невозможно было просто дать другому чуваку сурцы куска своей программы, потому что она существовала в IDE, и передать можно было только целый Image. Ну вот здесь подобных проблем вроде нет.
В текстовом виде есть инфа?
pgdn не работает?
Note: The full Code Bubbles paper PDFs will be put online shortly after the CHI and ICSE conferences.
В IDA есть представление дизассемблированного кода в виде автоматически сгенерированной блок-схемы. Кое-что становится понятнее, но все равно тяжело понимать код с множеством ветвлений.
Оставить комментарий
pitrik2
http://www.cs.brown.edu/people/acb/codebubbles_site.htm