Цитата:
Но какая система генерации проектов! Полностью работоспособная.
Зато шаг вправо - шаг влево считается побег!
не буду расписывать своими словами, только недавно переводил текст прямо в тему:
Пфистер - Компонентное ПО писал(а):
К сожалению, любой вид настройки, включая сборку компонентов, в некоторой степени требует программирования. Многие производители инструментария обещают, что вы сможете настроить существующее ПО "без написания ни единой строчки кода".
Не верьте этому. Компьютеры настолько немые, что вы должны точно сообщить им, что вы от них хотите. Называть это программированием или нет, это все же требует необходимых навыков, таких как точность и ясность.
Например, есть некоторые инструменты для сборки компонентов, которые позволяют задавать поведение графически, или хуже, смешивая графику и текст. Картинка стоит тысячи слов. Это верно описания специфических ситуаций, но редко подходит для описания поведения или общих правил. Инструменты графического программирование оказаться полезными лишь в некоторых обстоятельствах, когда проблема очень ограничена в размерах и тематике. Небольшие конечные автоматы (finite state machines) - хороший пример. Для более сложных проблем, разработка становится более громоздкой - и эксплуатация более громоздкой - чем в случае с полноценным языком программирования.
В идеале, средство разработки компонентного ПО должно строиться на компонентно-ориентированном языке. Инструментарий не может полностью компенсировать слабости языка программирования. Например, безопасный язык предотвращает целые классы ошибок, что проще и дешевле, чем заставлять программистов потом их устранять, используя причудливые и дорогие инструменты для отладки. ... Проверка возможных условий ошибок, таких как нарушение предусловий процедур, называется защитным (defensive) стилем программирования. Такой стиль желателен для любого промышленного ПО.
Для сборки компонентов от средства разработки требуются базовые функции RAD (Rapid Application Development), известные по таким средам, как Borland Delphi или Microsoft Visual Basic. ... Инструмент не должен генерировать из формы исходный код, так как это делает последующее редактирование невозможным без доступа к среде разработки, или даже без исходных кодов. "Мастера" генерирования исходного кода - модная часть многих RAD-сред. Однако это должно лишь освободить вас от очевидной и повторяюзщейся работы. При этом не должно происходить никакой "магии", которую вы не понимаете; в противном случае инструмент становится вашим мастером, в то время как должно быть наоборот. В общем, можно сказать, что чем лучше язык программирования, тем меньше надобности в инструментах генерации кода, поскольку язык позволяет поместить повторяющийся код в библиотеки, вместо того, чтобы повторять его снова и снова с незначительными изменениями.
Генерация из формы исходного кода - одна из крайностей. Но берегитесь также и другой. Другая крайность - это исходный код, внедренный в элементы пользовательского интерфейса. Должна быть возможность рассматривать полный исходный код вашего компонента или компонентной сборки без доступа к элементам пользовательского интерфейса, то есть, код должен быть изолирован от кнопок и других "крысиных нор" ("rat holes"). Если части вашего кода разнесены по сотням крысиных нор, эксплуатация становится неряшливым занятием, что лишает программу потенциала развития. А такой потенциал необходим, поскольку успешные компонентные сборки обычно приспосабливаются к новым нуждам и потому растут со временем. Поэтому хорошо подумайте, прежде чем выбрать простой сценарный инструмент, который может только собирать компоненты. Вы сможете решить очень быстро 80% ваших сиюминутных проблем, но оставшиеся 20% могут отнять больше, чем первые 80%.
Вход
FAQ
Поиск
