12 авг. 2010 г.

Беда визуальных средств разработки

Много лет назад - в то время, когда в средах разработки появились визуальные средства - я обещал, что не буду учить программированию посредством предложений наподобие "Теперь перетащите кнопку с панели инструментов в окно". С гордостью могу сказать, что сдержал свое обещание.

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

Недавно я получил наглядный пример по электронной почте. Программисту, пишущему приложение Windows Forms, нужно было создать и выполнить строки кода на C# во время работы программы. Мне стало любопытно, зачем это нужно, поскольку обычно при написании программ такие задачи встречаются редко. Оказалось, что у него на форме размещена группа меток (Label) с разными именами, и он не может найти способ обратиться к одной из них. Но он смог склеить несколько строк вида "label800.Text = \"xyz\";", и ему нужно было выполнить их во время работы программы.

Через некоторое время я подумал, что существование элементов управления с именами типа label800 является результатом утомительной работы - перетаскивания 800 меток с панели инструментов Visual Studio на форму и последующего упорядочения по строкам и столбцам.

Несмотря на то, что есть много правильных способов решения конкретной задачи программирования, существует и множество неверных решений. Использовать визуальный дизайнер для создания более чем полдюжины элементов управления одного типа и расположения их по строкам и столбцам - это неправильно, неправильно, неправильно, неправильно. Это работа для программного кода. Создавать элементы управления, вычислять их координаты (при необходимости) и сохранять их в массиве для упрощения доступа следует в цикле for. Сейчас я не буду обращаться к вопросу, не слишком ли много 800 меток для одного окна.

Но почему кто-то думает, что создавать элементы управления надо с помощью визуального дизайнера? Запустите Visual Studio и создайте новый проект Windows Forms. Перед вами конструктор , который побуждает вас перетаскивать элементы управления на поверхность окна. Visual Studio говорит нам, что это правильный способ разработки интерфейса программы.

Не только Visual Studio, но и многие книги и презентации поощряют использование визуальных средств разработки. Полагаю, что это делается с целью показать, насколько "легко" создать новую программу. Но это, безусловно, мошенничество и откровенная демонстрация лени со стороны преподавателя. Гораздо полезнее было бы привести различные решения в программном коде. Когда вы в последний раз видели презентацию, автор которой показывал, как создать и сохранить в массиве элементы управления с использованием цикла for?

Конечно, положение дел ухудшилось с появлением WPF и Silverlight. Мое первоначальное опасение о том, что многие программисты не будут изучать, как сделать в коде то, что может быть сделано посредством разметки, оправдалось, но теперь многие программисты даже не пишут свою разметку! Expression Blend убедил многих программистов в том, что не нужно знать, как самому написать градиентные кисти, анимации и шаблоны, или познакомиться с Visual State Manager, потому что Expression Blend берет все эти заботы на себя.

Возможно, я не единственный консультант, который видел ужасающие XAML-анимации, сгенерированные Expression Blend, в то время как простое решение в коде (такое как пользовательская панель) работало бы лучше, было бы понятнее и проще в поддержке.

Наши средства программирования отчасти определяют качество программ, которые мы пишем. Именно поэтому оператор GOTO считается вредным и был изгнан из современных языков программирования. Сам по себе оператор GOTO безобиден, тем не менее, он побуждает программистов создавать в коде огромные кучи дымящихся спагетти, разобрать и понять которые невозможно никому.

Теперь мы получили кучи безобразного кода разметки, который даже не отформатирован для чтения. Предполагается, что мы не будем читать его, так как мы доверяем Expression Blend. Но Expression Blend не расскажет нам о том, что есть лучший способ выполнения работы.

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

И, конечно, авторам книг и презентаций о программировании с использованием WPF и Silverlight не следует начинать обучение с работы в Expression Blend. Это совершенно безответственно.

Автор: Чарльз Петцольд.
Оригинал статьи на английском: The Disasters of Visual Design Tools.

Комментариев нет:

Отправить комментарий