мини IDE

[sign]

Вот, я бы хотел запрограммировать текстовый редактор на драконе, да так, чтобы мне было легто и просто и без помощи профессиональных программистов - они лишнее звено:

А что бы вам не захотеть тоже самое на Коболе?

Чтобы избежать опасных для здоровья перегрузок, надо уменьшить интеллектуальную нагрузку на человеческий мозг. С другой стороны, развитие цивилизации приводит к усложнению интеллектуальных задач и непрерывному увеличению их количества, что предъявляет к мозгу постоянно растущие требования

Думать опасно для здоровья? Надо не думать!

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

Это по существу.

Нет, это просто навешивание на слова Параджанова своих мыслей, которых в его словах не было. А потом огонь из всех калибров.

Может-ли дегенерат от образования придумать что-то полезное?

Фу, как некрасиво.

Никто не говорит, что блок-схемы - это зло. Все знают, что блок-схемы имеют свою нишу.

Явно видно, что вы так ничего и не поняли.
Сказать что Дракон это просто блок-схемы, это равно сказать, что и UML не более чем блок-схемы.

Но, никто не имеет прав на Луну, тем более, дебилизм виден в разговорах о том, что програмисты не нужны и думать вредно. Это каждый решает для себя. Если ты полы моешь в офисе - это твой выбор, который не запрещает тебе думать и интересоваться, например, Мондельштамом, но это не значит, что все должны быть дебилами как ты, кто не интересуется ничем, и кому думать опасно для здоровья.

Неужели я разгадал ваш секрет?
Вы, верно, начали что-то делать на Драконе не думая, решив, по одной вам только известной причине, то таковое нужно делать непременно не думая?
И у вас ничего не получилось!!!
Подсказка - попробуйте при использовании Дракона думать.
Уверяю вас - всё получится.

[alexey38]

alexey38 писал(а):т.к. большинство программеров этого сайта пишут визуализацию БД, то с бизнес-логикой у них туго (нет опыта).

Обидеть хотите? БД, как правило, и занимается именно бизнес-логикой, потому, что это называется, если ВЫ не знали, автоматизацией бизнес-процессов. Хотя, подозреваю, что многие очень начинающие программеры это делают интуитивно, не изучая классиков - методом тыка, шишек и как получиться

Ни коем образом не хотел никого обидеть, если кого задел, то прошу извинить. Я имел в иду то, что большинство программеров, выполняющих эту работу, требуют от технологов (бухгалтеров, экономистов, юристов и т.п.), чтобы те не будучи программистами описали им алгоритм (принцип) работы программы, т.е. требуют ТЗ на программу. А это в корне не верный подход, т.к. технолог не являющийся программистом не может дать задание программисту, точно также как немузыкант не может дать композитору задание написать конкретную мелодию, он сам не знает что ему надо. Правильный подход, когда программист (в роли архитектора или дизайнера) изучает техпроцесс или бизнеспроцесс, разбирается в нем, уточняет некоторые детали, и уже сам предлагает некое решение в части программной реализации. От технолога в качестве требований можно получить характеристики его технологического процесса, а не характеристики программы. Важно понимать, что разработка серьезного продукта происходит не в одно лицо, тот который разбирается в технологии, тот обычно уже не кодит, а создает задания кодерам, дизайнерам и т.п.

Так вот понимая как работают технологи, для согласования решений программисты вынуждены делать представления бизнес-логики в виде понятном для технологов. Например, музыканты понимают ноты, а программный код синтезатора в принципе не содержит нот, он написан не на нотах, а на языке программирования, хотите согласовать с музыкантом некий звуковой эффект, показывайте его не в виде кода, а в виде нот (без эффекта и с эффектом).

Так вот, насколько я понял о чем Вы пытаетесь сказать, это совсем не так 100% UML описания классов идет в код, если есть генерация кода. Реализация - это отдельный вопрос, хотя, диагтаммы состояний могут пригодиться. Очень плохо с генерацией реализации, потому, что иначе диаграммы станут громоздскими.

Я знаю, что есть генерация кода на уровне генерации классов, модулей, БД. Иногда - это полезно, но в большинстве случаев - это никому не нужно.
В любой задаче, в т.ч. в программном проекте, есть цели, есть задачи, есть ключевые ограничения, свойства и требования - именно все это определяет конечную структуру программного проекта.
И все эти внешние к программе требования довольно удобно представлять в графическом виде, так нагляднее и понятнее.
Я не видел ни одной UML диаграммы или инструмента, где бы одновременно описывались и внешние требования и внутренняя структура.
Открываешь диаграммы классов, прочие диаграммы зависимостей, и не понимаешь почему именно так, а не иначе. Правильно это или не правильно. Соответствует ли это требованиям или не соответствует.

Поэтому при разработке проекта мне проще за 5 минут на бумажке что-то там почертить и получить решение для обдумывания, чем вырисовывать UML, что требует большего времени. При этом средства UML мне ни как не помогают в принятии решения. А когда решение уже разработано, то мне хватает средств обычной IDE, чтобы быстро увидеть структуру проекта, запомнить ее и работать без лишних бумажек (у меня нечто подобное UML строится в голове, после просмотра кода обычными IDE).

И в рефакторинге UML не особо-то помогает. Часто приходится сталкиваться с тем, что неучет неких внешних требований привел к изначально неправильной структуре. Возникает задача трансформации кода из старой структуры в новую (другая иерархия классов, изменены взаимозависимости и т.п.), и очень хотелось бы, что бы инструмент мне помог найти оптимальный способ последовательной трансформации проекта (порядок рефакторинга), но про такие функции тоже не особо слышно. И это приходится опять решать вручную на листочке бумаги.

[stikriz]

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

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

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

Обычно, это разные диаграммы. Одна из другой неочевидно преобразуется, если вообще такое возможно, что вряд-ли, потому, что объект реального мира мало похож на объект программы, так же как и объект программы мало похож на объект в БД. Есть какие-то общие свойства, да и только.

Поэтому при разработке проекта мне проще за 5 минут на бумажке что-то там почертить и получить решение для обдумывания, чем вырисовывать UML, что требует большего времени. При этом средства UML мне ни как не помогают в принятии решения.

Есть же решение как кодить, а есть решение как построить бизнес-процесс, точнее решение о том, что Вы правильно поняли как устроен бизнес-процесс у заказчика. Второе - это картинка для заказчика, и она нужна. Первое - это лично Ваши навыки и предпочтения. Здесь UML не виноват. Дольше времени - да. Например, роза неудобна интерфейсно тогезе лучше интерфейсно. А вообще, счастья нет пока.

Возникает задача трансформации кода из старой структуры в новую (другая иерархия классов, изменены взаимозависимости и т.п.),

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

[vada]

Например, роза неудобна интерфейсно тогезе лучше интерфейсно.

Из всех рабочих сред
Together лучше всех!
(почти стихи)

ЗЫ.Жаль только Борланд похерил замечательный продукт.

Ребята! Прекращайте сраться!

[alexey38]

Здесь UML не виноват

Я не ругаю UML. Я просто говорю, что хотел бы большего. Причем большего именно в самой сложной части, где пересекается разные сферы: программирование, технология, орг.вопросы и т.п.
Это очень важная часть, часто бывает вообще не задокументирована, и находится в головах отдельных исполнителей и руководителей. Если структуру классов, функционал классов всегда можно расшифровать по наличию кода программы. То расшифровать цели, задачи и прочее вообще невозможно. Это одна из самых сложных сфер, когда приходится поддерживать чужой код. Понять как он работает сложно, но можно, но как понять зачем он так делает практически невозможно (это фича или это баг?).

[vada]

Я не ругаю UML. Я просто говорю, что хотел бы большего. Причем большего именно в самой сложной части, где пересекается разные сферы: программирование, технология, орг.вопросы и т.п.
Это очень важная часть, часто бывает вообще не задокументирована, и находится в головах отдельных исполнителей и руководителей. Если структуру классов, функционал классов всегда можно расшифровать по наличию кода программы. То расшифровать цели, задачи и прочее вообще невозможно. Это одна из самых сложных сфер, когда приходится поддерживать чужой код. Понять как он работает сложно, но можно, но как понять зачем он так делает практически невозможно (это фича или это баг).

Эти вопросы быле решены в Together Ведя разработку все можно задокументировать. И бизнес-логику, и потоки данных, и структуры БД, и иерархию классов... Волшебная вещь!!!! Правда я работал в довольно старой версии 6.0.1 (больше 10 лет тому назад). Более свежие версии, которые предлагала Borland были уже совершенно невозможные, а что сейчас с этим продуктом даже и не знаю.

[Kemet]

ev, а где всё это можно скачать?

[ev]

а где всё это можно скачать?

еще ведется разработка
тема была создана чтобы собрать интересные идеи и узнать кому интересен проект (для последующего обсуждения)

[B4rr4cuda]

.. дракон.. UML.. *мечтательно* построитель UML диаграмм из кода бы.. маленький такой, удобненький..

[vada]

построитель UML диаграмм из кода бы.. маленький такой, удобненький..

Обычно делают наоборот

[Brainenjii]

у .net'чиков есть Entity с Code-First. При определённых правилах может генерировать UML из кода

[B4rr4cuda]

Обычно делают наоборот

Знаю, но мне чаще надо "окинуть взглядом" уже существующий код, чем генерить новый.. хотя это тоже требуется)

Brainenjii, ну их.. этих *нетчиков. Для джавы вон тоже тулз, хоть завались, но мне от этого ни горячо, ни холодно..

[mirk]

Можно взглянуть что получается?
Может макет уже есть или более подробное описание?

[ev]

если действительно хочется посмотреть на довольно сырой макет - пишите в лс или им

[mirk]

Немного покликал и возникло несколько вопросов:

• Как будут добавляться проекты?
• Сейчас панели две (слева и снизу). Можно добавить еще справа?
• В файловых фильтрах не совсем понятна логика. Табличка противоречит выпадающему списку. Что там имеется ввиду?
• Зачем два статусбара (они ведь дублируют информацию)?
• В разных местах разные названия (miniIDE, simpleIDE, IDE) - какое правильное?

Еще заметил глюк с нижней панелью - она иногда выскакивает на пол экрана заслоняя собой все.