Комментарии 45
Очень интересно, пишите!
Вряд ли быстрее будет разработка, скорее наоборот.
Но пишите, интересно.
Но пишите, интересно.
Мне думается, что тут акцента надо не на быстроту ставить, а на то, что проект имеет явную структуру, а потому легче привлекать новых членов в команду разработчиков, передавать проект, выкладывать как open source.
если для проекта делается аналитика в виде UML-диаграмм, то для большого проекта генерация исходного кода по ним может быть неплохим стартом для работы кодера.
возможные бонусы:
— сокращается время на то, чтоб проект начал собираться (имеется ввиду первая сборка проекта);
— наличие визуального представления структуры будущего проекта и документация интерфейсов (главное при отклонении реализации от модели, своевременно ее обновлять), важно когда вы пишите код и используете чужой модуль которого еще нет :-)
возможные бонусы:
— сокращается время на то, чтоб проект начал собираться (имеется ввиду первая сборка проекта);
— наличие визуального представления структуры будущего проекта и документация интерфейсов (главное при отклонении реализации от модели, своевременно ее обновлять), важно когда вы пишите код и используете чужой модуль которого еще нет :-)
Только классы исходя из диаграмм классов можно генерить?
Да, было бы интересно почитать ещё
Вы бы в самом начале указали ценник на PowerDesigner, у многих желание кодогенерацией заниматься надолго пропадёт. Кстати я смотрю на скриншотах у вас 12 версия :).
Не проняло.
Типовые повторяющиеся куски кода можно устранять средствами языка программирования. То же самое и с легкостью модернизации, хороший код легко модернизировать. Ну и хороший код легко читается. Питон достаточно высокоуровневый язык, чтоб писать на нем простой и читаемый код.
А тут мы имеем какую-то сгенерированную жуть.
Наверное, это все какие-то стандартные и ожидаемые доводы против таких штук) В любом случае, для себя лично практической пользы не увидел.
Типовые повторяющиеся куски кода можно устранять средствами языка программирования. То же самое и с легкостью модернизации, хороший код легко модернизировать. Ну и хороший код легко читается. Питон достаточно высокоуровневый язык, чтоб писать на нем простой и читаемый код.
А тут мы имеем какую-то сгенерированную жуть.
Наверное, это все какие-то стандартные и ожидаемые доводы против таких штук) В любом случае, для себя лично практической пользы не увидел.
На мой взгляд UML диаграммы «читаются» проще чем любой код.
Ну а про фломастеры и вкус я думаю все знают.
Вы, наверное, руководитель, а не рядовой разработчик? Да, UML-диаграммы делают Python более «ынтерпрайзным». Но при этом код, который получается после генерации, становится похожим на написанный на Java, на которой без IDEA (по отзывам несчастных) очень муторно писать.
У Вас кодогенерация демонстрируется на каком-то оторванном от жизни абстрактном примере. Какой-то Foo, CheckHelper, PrintHelper — что обозначают все эти названия? Давайте в следующей статье про Django какой-то более жизненный пример. Например, систему регистрации-авторизации пользователей. Стандартный компонент registration мне показался не лишенным недостатков, когда работал c Django.
У Вас кодогенерация демонстрируется на каком-то оторванном от жизни абстрактном примере. Какой-то Foo, CheckHelper, PrintHelper — что обозначают все эти названия? Давайте в следующей статье про Django какой-то более жизненный пример. Например, систему регистрации-авторизации пользователей. Стандартный компонент registration мне показался не лишенным недостатков, когда работал c Django.
Ну так читайте UML-диаграммы, раз хотите. Вопрос генерации кода из них — это совсем другой вопрос, который ведет к другому способу разработки, имеющему (на мой взгляд) значительные недостатки.
Кстати, не совсем по делу, но картинки, чтоб посмотреть структуру моделей, можно сгенерить из этих самых моделей:
code.google.com/p/django-command-extensions/wiki/GraphModels
code.djangoproject.com/wiki/DjangoGraphviz
Кстати, не совсем по делу, но картинки, чтоб посмотреть структуру моделей, можно сгенерить из этих самых моделей:
code.google.com/p/django-command-extensions/wiki/GraphModels
code.djangoproject.com/wiki/DjangoGraphviz
UML — очень полезная штука, но генерировать повторяющийся код — серьезная ошибка. UML следует рисовать отдельно (лучше всего на бумажке:) или получать путем анализа существующего кода. Хорошо, если вручную: лучше разберетесь в коде и заодно поймете, что в нем надо изменить. Если же вручную разбираться в коде мучительно — значит, код ужасен и, вероятно, сгенерирован кем-то из UML.
У меня вопрос к автору как человеку осведомленному в области UML.
Есть какие то достойные бесплатные аналоги Sybase Power Designer?
Есть какие то достойные бесплатные аналоги Sybase Power Designer?
бесплатных достойных нет :) из платных, но очень достойных могу посоветовать Enterprise Architect, к тому же он вполне подъемный: Desktop — ~4500р, Pro — ~6700р, Corp — ~8100р.
Вопрос ко всем поклонникам UML. Есть ли что-то приятное и бесплатное/имеющее кряк для Linux? BoUML и Umbrello, как мне кажется, имеют маловато возможностей по кодогенерации. В плагинах к NetBeans/Eclipse, она тоже отсутствует.
Есть TopCoder UML Tool. Написано на Java. Я лично не пробовал, но эта штука активно используется в разработке на topcoder.com.
интересно будет посмотреть про джанго. на самом деле, мне кажется, что кодогенерация для джанго несколько излишние предприятние.
В области встроенного ПО автогенеренный код применяется с большим успехом и очень давно. Дело все именно в удобстве документирования и разработке, основанной на примитивах (model-based development, например).
А если разработка ведется по какому-либо отраслевому стандарту. то время экономится еще и за счет квалификации программного обеспечения для разработки и, как следствие, удешевлению верификации и сертификации.
А если разработка ведется по какому-либо отраслевому стандарту. то время экономится еще и за счет квалификации программного обеспечения для разработки и, как следствие, удешевлению верификации и сертификации.
Может у меня что-то с глазами, но я не вижу никакой связи с Джанго в посте.
Или это такой способ привлечь внимание?
Или это такой способ привлечь внимание?
Описанный пример — пример неграмотного и глупого решения задачи. Какой смысл плодить сгенерированный дублирующийся код? Все ради того, чтобы рисовать стрелочки в ГУИ?
А уж такую задачу, как связь и создание объектов по требованию можно решить легко без автогененированной каши.
А уж такую задачу, как связь и создание объектов по требованию можно решить легко без автогененированной каши.
ну вы не правы, дорогой, вспомните долгие рассуждения о том, как правильно писать инклуды на спп, или как муторно искать нужный файл с классом в котором надо поправить 76 строчку, или подумайте какой-это геморрой делать апгрейд проекта в котором 150 файлов со странными названиями.
Долгие рассуждения фиксятся документом под названием code convention. Нет времени его придумывать — возьмите Google Code Convention или Lockheed-Martin.
>>Геморрой делать апгрейд проекта
А это, извините, специфика разработки — чтобы что-то поменять, надо что-то поменять. В случае с UML у вас даже юнит-тестов на сгенерированный не будет.
>> 150 файлов со странными названиями
Такое будет как раз после использования кодогенератора.
Кроме того, сравните возможности этого notepad-кодогенератора и нормального редактора кода — с подсветкой, ассистом и браузером кода.
>>Геморрой делать апгрейд проекта
А это, извините, специфика разработки — чтобы что-то поменять, надо что-то поменять. В случае с UML у вас даже юнит-тестов на сгенерированный не будет.
>> 150 файлов со странными названиями
Такое будет как раз после использования кодогенератора.
Кроме того, сравните возможности этого notepad-кодогенератора и нормального редактора кода — с подсветкой, ассистом и браузером кода.
1. я о code-convension не знал, видимо в ближайшее время не узнаю,
2. речь не о том, что бы сделать так, чтобы работало и сверять юнит-тестом, а быстро вспомнить что почем, и не рисовать картинки на столе
3.прикольно а у вас проект все в одном файле лежат?)
Не знаю, как вам, я тоже давно прирос к кодогенератору, и если вы не имеете проблем с синтаксисом языка и соглашениями о его оформлении, то проблем с кодогенератором у вас не будет. Я же стараюсь любой громоздкий проект перевести в него, потому как с картинками работать удобнее, чем с текстом.
2. речь не о том, что бы сделать так, чтобы работало и сверять юнит-тестом, а быстро вспомнить что почем, и не рисовать картинки на столе
3.прикольно а у вас проект все в одном файле лежат?)
Не знаю, как вам, я тоже давно прирос к кодогенератору, и если вы не имеете проблем с синтаксисом языка и соглашениями о его оформлении, то проблем с кодогенератором у вас не будет. Я же стараюсь любой громоздкий проект перевести в него, потому как с картинками работать удобнее, чем с текстом.
2. Ну так чтобы вспомнить, что почем, необязательно иметь кодогенератор, достаточно wiki c UML-схемой. Если конечно, у вас не директива «сначала UML, потом код по нему»
3. Нет, у меня все выстроено иерархически, по папкам и проектам, так что вопросы к проекту на предмет «что-где» не появляются )
Кодогенератор нужно использовать там, где нужен кодогенератор.
Иначе code-generation превращается в co-degeneraton, со связанными руками, наколенными хаками и все такое. Тот же RUP, несмотря на всю формальность, со стороны архитекторов предусматривает только генерацию протоколов/интерфейсов, а код пишут люди.
3. Нет, у меня все выстроено иерархически, по папкам и проектам, так что вопросы к проекту на предмет «что-где» не появляются )
Кодогенератор нужно использовать там, где нужен кодогенератор.
Иначе code-generation превращается в co-degeneraton, со связанными руками, наколенными хаками и все такое. Тот же RUP, несмотря на всю формальность, со стороны архитекторов предусматривает только генерацию протоколов/интерфейсов, а код пишут люди.
а зачем unit-тесты для кода, который из генератора вылезает?
> вспомните долгие рассуждения о том, как правильно писать инклуды на спп
Претензии к авторам C++ за отсутсвие модулей.
> или как муторно искать нужный файл с классом в котором надо поправить 76 строчку
Не знаю, у меня в php классы в строгом порядке по папкам, я всегда знаю где какой искать (и имена файлов соотвествуют классам).
> или подумайте какой-это геморрой делать апгрейд проекта в котором 150 файлов со странными названиями
Бросайте курить всякую дурь и называйте файлы нормально :)
p.s. Вы про code convention не слышали, наверно и про inline documentation и системы типа javadoc/cppdoc не слышали? Теорию учите тогда и учитесь оформлять код правильно.
Претензии к авторам C++ за отсутсвие модулей.
> или как муторно искать нужный файл с классом в котором надо поправить 76 строчку
Не знаю, у меня в php классы в строгом порядке по папкам, я всегда знаю где какой искать (и имена файлов соотвествуют классам).
> или подумайте какой-это геморрой делать апгрейд проекта в котором 150 файлов со странными названиями
Бросайте курить всякую дурь и называйте файлы нормально :)
p.s. Вы про code convention не слышали, наверно и про inline documentation и системы типа javadoc/cppdoc не слышали? Теорию учите тогда и учитесь оформлять код правильно.
UML в Django — это в первую очередь создание ORM-моделей.
Не увидел пути к этому в посте:( А очень-очень хотел, правда.
Не увидел пути к этому в посте:( А очень-очень хотел, правда.
Да, я тоже этого ожидал.
У самого была (давным давно, когда был юн и холост) идея сделать на PyQt подобную генерилку, но руки так и не дошли.
У самого была (давным давно, когда был юн и холост) идея сделать на PyQt подобную генерилку, но руки так и не дошли.
А не проще ли:
а) придумать хорошие названия моделям,
б) разбить модели по модулям
и спокойно обозревать всё это добро без каких-либо доп. инструментов?
Пункт «а», наверно, самый важный. Иногда название ну никак не придумывается. Это явный признак плохого дизайна. Когда названия ясны и точны, вопросов о структуре и связях не возникает и схемы практически не нужны.
а) придумать хорошие названия моделям,
б) разбить модели по модулям
и спокойно обозревать всё это добро без каких-либо доп. инструментов?
Пункт «а», наверно, самый важный. Иногда название ну никак не придумывается. Это явный признак плохого дизайна. Когда названия ясны и точны, вопросов о структуре и связях не возникает и схемы практически не нужны.
Так вот об архитектуре и речь. UML позволяет создать архитектуру, «подвигать» её в разные стороны, не написав ни единой строки кода. Вообще говоря, UML-модель — это нечто еще обльшее, что еще шире охватывает архитектуру вашего приложения, чем простое проектирование структуры объектной модели.
Мы здесь не пытаемся отказаться от UML. Задача в том, чтобы не писать одно и то же сто, а иногда и тысячу раз. Не знаю как вам, а мне достаточно трудно обозревать в коде проект состоящий из 6-8 app-ов, в каждом из которых не меннее 10-12 моделей.
Задача автоматической генерации Django-моделей из диаграммы классов UML выглядит достаточно тривиальной. Интереснее было бы генерировать код для view из Sequence-диаграммы, автотесты из Use Case диаграмм и т.п.
Согласитесь, что при наличии подробного ТЗ, формальной формой которого является UML-модель, создание проектов с использованием Django сводится к однообразному механическому кодированию. Так почему бы не отдать однообразную бездумную работу инструменту, которые для этого создан?
Мы здесь не пытаемся отказаться от UML. Задача в том, чтобы не писать одно и то же сто, а иногда и тысячу раз. Не знаю как вам, а мне достаточно трудно обозревать в коде проект состоящий из 6-8 app-ов, в каждом из которых не меннее 10-12 моделей.
Задача автоматической генерации Django-моделей из диаграммы классов UML выглядит достаточно тривиальной. Интереснее было бы генерировать код для view из Sequence-диаграммы, автотесты из Use Case диаграмм и т.п.
Согласитесь, что при наличии подробного ТЗ, формальной формой которого является UML-модель, создание проектов с использованием Django сводится к однообразному механическому кодированию. Так почему бы не отдать однообразную бездумную работу инструменту, которые для этого создан?
Мне для диплома надо написать кодогенератор UML -> САА; хорошо, что прочитал эту статью, спасибо.
Сильно рекомендую посмотреть на Active Record для Ruby
Лет 5-6 назад я участвовал в проекте, для которого мы написали ядро для кодогенерации кода python из PowerDesigner, и кстати тоже использовали wxWidgets и MSSQL (может это тот же проект? Тогда привет Марселю и Вите. :) )
Но основная фишка того проекта — это генерация типизированных форм из диаграмм объектов. Это позволило 3 разработчикам за 1.5 года практически полностью автоматизировать одну из крупнейших оптовых контор в Казани, занимающейся алкоголем.
Ну и других плюсов не мало. :)
Но основная фишка того проекта — это генерация типизированных форм из диаграмм объектов. Это позволило 3 разработчикам за 1.5 года практически полностью автоматизировать одну из крупнейших оптовых контор в Казани, занимающейся алкоголем.
Ну и других плюсов не мало. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кодогенерация UML->Python (Django)