Я давно разрабатываю GUI-софт на Delphi/C#. И время от времени думаю о том, как снизить частоту перекомпиляции всего проекта из-за неправильно настроенных контролов, обработки их действий на формах. Прорабатывать логику действий контролов в уме успеха пока не приносит, обязательно что-то упускаю. Последнее, что сделал, чтобы свести к минимуму перекомпиляцию всего проекта — свел точки соприкосновения между формами к минимуму, т.е. создаю объекты-посредники между ними и я могу тестировать формы и логику поведения контролов на ней отдельно от всего проекта. Но тем не менее все равно приходится делать частую перекомпиляцию, теперь на уровне мини-проектов (тестирование форм). А также большой
вклад в частую перекомпиляцию вносят контролы, к которым либо мало документации, либо сумбурно написанные. Например, и в Delphi, и в С# использую контролы от DevExpress. Фичей и возможностей очень много, а разбираться в них приходится и методом "научного тыка".
Уважаемые, кто из вас знает более действенную методику и предложите мне не забивать голову ерундой?
Здравствуйте, Balax, Вы писали:
B>Я давно разрабатываю GUI-софт на Delphi/C#. И время от времени думаю о том, как снизить частоту перекомпиляции всего проекта из-за неправильно настроенных контролов, обработки их действий на формах.
А это вопрос риторический или как? Дело в том, что Delphi/C# — это не C++, скорость компиляции очень высокая. А учитывая, что тот же Delphi обычно компилит только те юниты, в которых происходили изменения, то суть проблемы не очень понятна. Сколько приходилось работать на Delphi — проект приблизительно 100К строк, вносил необходимые изменения, нажимал F9 — все компилилось и запускалось влёт.
B> А также большойвклад в частую перекомпиляцию вносят контролы, к которым либо мало документации, либо сумбурно написанные. Например, и в Delphi, и в С# использую контролы от DevExpress. Фичей и возможностей очень много, а разбираться в них приходится и методом "научного тыка".
А какая зависимость от этих контролов? Один раз компилируешь в пакеты, dcu-файлы, убираешь все ссылки на исходники, и необходимость в их перекомпиляции отпадает.
Мне приходилось поддерживать библиотеку компонентов (несколько десятков тысяч строк кода), написанную собственноручно, которой пользовалось одновременно человек 10. У всех были общие dcu, и никто ничего не перекомпилировал...
Да, вопрос скорее риторический, чем практический. Хотя, думаю, на него есть ответ.
С>А это вопрос риторический или как? Дело в том, что Delphi/C# — это не C++, скорость компиляции очень высокая. А учитывая, что тот же Delphi обычно компилит только те юниты, в которых происходили изменения, то суть проблемы не очень понятна. Сколько приходилось работать на Delphi — проект приблизительно 100К строк, вносил необходимые изменения, нажимал F9 — все компилилось и запускалось влёт.
Суть в том, как часто вы нажимаете на F9? Я вот не хочу так часто делать, только потому что неправильно
настроил свойства контролов, их положение и логику поведения. Неверное поведение контролов вижу только при работе
программы.
Здравствуйте, Balax, Вы писали:
B>Суть в том, как часто вы нажимаете на F9?
Ну, я встречал людей, которые могут пол дня писать код, прежде чем проверят, что он хотя бы компилируется. Я же предпочитаю делегировать компилятору проверку того, что после внесенного мною изменения, хотя бы синтаксически и грамматически все осталось корректным. Т.е. довольно часто, но как-то меня это не напрягает...
B>Я вот не хочу так часто делать, только потому что неправильно настроил свойства контролов, их положение и логику поведения.
Мое мнение, в данном случае, заключается в том, что если мы хотим остаться в рамках Delphi/C#, то это просто неизбежно — они так устроены.
Как вариант можно рассмотреть ситуацию, когда описание свойств контролов не компилируется вместе с exe, а хранится в отдельном файле, который читается только во время запуска программы. Эдакий config... На сколько это удобно, необходимо — вопрос отдельный, и общий ответ на него вряд ли существует, все зависит от конкретной ситуации, от конкретных задач, стоящих перед вами...
А еще можно каждую форму в отдельную dll запихнуть... Тоже необходимость перекомпиляции всего резко снизится, но что-то мне подсказывает, что оно того не стоит...
Здравствуйте, Стэн, Вы писали:
С>А еще можно каждую форму в отдельную dll запихнуть... Тоже необходимость перекомпиляции всего резко снизится, но что-то мне подсказывает, что оно того не стоит...
Еще можно на Java перейти — там каждый класс является автомноной еденицей, так что инкрементальная компиляция в IDEA работает мгновенно на любых проектах.
Здравствуйте, Cyberax, Вы писали:
C>Еще можно на Java перейти — там каждый класс является автомноной еденицей, так что инкрементальная компиляция в IDEA работает мгновенно на любых проектах.
Как вариант...
А если перекомпиляция проекта — это большая проблема, то можно и на динамические языки перейти. Smalltalk, например. Там понятие перекомпиляции проекта вообще отсутствует...
Здравствуйте, Стэн, Вы писали:
С>А если перекомпиляция проекта — это большая проблема, то можно и на динамические языки перейти. Smalltalk, например. Там понятие перекомпиляции проекта вообще отсутствует...
Понятие быстрой работы там тоже отсутствует.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
С>>А если перекомпиляция проекта — это большая проблема, то можно и на динамические языки перейти. Smalltalk, например. Там понятие перекомпиляции проекта вообще отсутствует... WH>Понятие быстрой работы там тоже отсутствует.
Кто бы спорил?!.. За все необходимо платить...
Но эту ситуацию можно рассмотреть и с другой стороны — какова цель написания конкретной программы? Если это какой-то прототип, то черт с этой производительностью. А если это сетевой сервер 24/7 — другое дело...
Здравствуйте, WolfHound, Вы писали:
WH>Понятие быстрой работы там тоже отсутствует.
Если под работой понимать постоянную (пере)компиляцию, то — да, отсутсвует.
B>Уважаемые, кто из вас знает более действенную методику и предложите мне не забивать голову ерундой?
Можно редактировать интерфейс без перекомпиляции и даже без перезапуска программы. Для этого интерфейс описывается, к примеру, на HTML. Посмотри на MS-технологию HTA или на HTMLayout/Scitter от c-smile. Правда, перевести уже существующий проект на новые рельсы тяжеловато — это нужно проектировать с самого начала.
Здравствуйте, Balax, Вы писали:
B>Здравствуйте все.
B>Я давно разрабатываю GUI-софт на Delphi/C#. И время от времени думаю о том, как снизить частоту перекомпиляции всего проекта из-за неправильно настроенных контролов, обработки их действий на формах. Прорабатывать логику действий контролов в уме успеха пока не приносит, обязательно что-то упускаю. Последнее, что сделал, чтобы свести к минимуму перекомпиляцию всего проекта — свел точки соприкосновения между формами к минимуму, т.е. создаю объекты-посредники между ними и я могу тестировать формы и логику поведения контролов на ней отдельно от всего проекта. Но тем не менее все равно приходится делать частую перекомпиляцию, теперь на уровне мини-проектов (тестирование форм). А также большой B>вклад в частую перекомпиляцию вносят контролы, к которым либо мало документации, либо сумбурно написанные. Например, и в Delphi, и в С# использую контролы от DevExpress. Фичей и возможностей очень много, а разбираться в них приходится и методом "научного тыка".
B>Уважаемые, кто из вас знает более действенную методику и предложите мне не забивать голову ерундой?
Я допустим часто в дебаге пишу код(C#), так с утра вошол в дебаг к обеду еще раз перезапустил...
Ну а вечером все перепроверил и залился, а сохранится забыл, на утро коллеги и доброе утро скажут, и здоровя пожелают...
к обеду еще раз перезапустил...
