Размышления о психологии и эстетике программирования
Чарльз Петцольд (Charles Petzold)
Речь, толкнутая перед нью-йоркской группой разработчиков .NET (NYC .NET Developer’s Group),
20 октября 2005 г.
Перевод: GSerg
Вкратце: Visual Studio может быть одним из лучших друзей программиста, но с годами она стала весьма бесцеремонной, властной и контролирующей всё и вся. Может просто сдаться её попыткам писать код за нас? А может, Visual Studio истощает наш программерский рассудок, а не укрепляет его? Здесь мы рассмотрим код, сгенерированный Visual Studio, проанализируем отвратительные приёмы программирования, насаждаемые ею, восхвалим сладость, горечь и удовлетворение от кодирования без подобных инструментов и прикинем радикальные изменения, которые несёт Avalon.
Я нечасто выступаю перед группами разработчиков, в основном из-за неприятного случая, произошедшего много лет назад. В 1991 году Бостонское компьютерное сообщество (Boston Computer Society) пригласило меня поговорить на тему программирования под Windows. Поскольку на тот момент я уже написал книгу по программированию под Windows — второе издание «Программирование под Windows» было опубликовано как раз за год до этого, — я решил, что, в общем, не стоит говорить на эту тему. Любой, кто хотел бы научиться программировать под Windows, мог просто купить книгу и прочитать её в спокойной домашней обстановке.
Вместо этого я решил поговорить о том, о чём люди не могли прочитать в моей книге. О теме, которая интересовала меня на тот момент, а именно, как Microsoft впервые разработала Windows, как Microsoft и IBM стали разрабатывать OS/2, как Microsoft убедила IBM встать на путь графики в оконной среде, как IBM решила, что хочет полностью новый API, и как потом успех Windows привёл к окончательному разрыву Microsoft и IBM.
Так вот люди не приняли. Думаю, они ожидали, что я за несколько часов расскажу им всё, что надо знать о программировании под Windows, а как раз этого мне делать не хотелось.
Для меня это был очень болезненный опыт, и с тех пор я был весьма осторожен в деле выступления на публику. Вы – разработчики .NET. Я написал четыре книги по программированию в .NET – четвёртая выходит 2 ноября – так что каждый, кто хочет прочитать их, может так и поступить. Сейчас я пишу книгу о Windows Presentation Foundation (ранее носившему кодовое название Avalon), но на данный момент не могу сказать ничего действительно полезного.
Так что когда Билл, Эндрю и Стефан попросили меня выступить здесь, я поначалу колебался, пока мне не было сказано – я цитирую email Эндрю — «мы с удовольствием обеспечим вам полную возможность свободного выбора темы, даже если темы не будет вообще». Сегодня у меня есть тема, и хотя она довольно странная, надеюсь, никто не разозлится.
Компьютеры в кино
Я недавно ещё раз смотрел фильм, который я считаю первым голливудским фильмом, серьёзно затронувшим компьютеры. Это был «Desk Set». 1957 год, три женщины под началом Кэтрин Хепберн в отделе исследований Федеральной радиовещательной компании. Когда всплывает вопрос, требующий исследований, им звонят, и Хепберн со своей командой приступают к работе.
Входит Спенсер Трейси, представляющийся Системным Инженером и изобретателем «электронного мозга», называемого Электромагнитной Памятью с Исследовательским Арифметическим Вычислителем, сокращённо «Эмми».
Само собой, каждый в отделе исследований предполагает, что его уволят, как это произошло в бухгалтерии, когда туда установили «электронный мозг». Хотя это выражается лишь несмелыми шутками, в то время такого варианта действительно опасались. Конечно, работники не думали, что им на замену придёт целый компьютер. Нет, они шутили в том плане, что будут заменены одной кнопкой.
Эмми, «электронный мозг», оказывается весьма сложным компьютером. Он понимает вопросы, вводимые с клавиатуры на естественном языке, и печатает ответы на телетайпе. Конечно, компьютеру далеко до спокойного профессионализма Кетрин Хепберн и её команды, так что на сложный вопрос тот реагирует так, как все мы привыкли видеть в кино: издаёт забавные звуки, дымится и разбрасывает перфокарты по всему офису.
Наверное, на то время это было смешно, даже для людей, которые знали, что таким образом компьютеры из строя не выходят. Я занимаюсь программированием уже 30 лет, и только раз я видел компьютер, который вышел из строя, я бы сказал, интересно (1).
Тем временем «электронный мозг», установленный в бухгалтерии, начинает печатать извещения об увольнении всем сотрудникам компании. Как все мы знаем, когда компьютеры захватывают власть, люди им становятся не нужны. После чего, как вы, конечно, догадываетесь, персонал приходит на помощь и демонстрирует своё превосходство над машиной.
Так как «Desk Set» был голливудской романтической комедией и, вероятно, так как IBM предоставила всё «железо» для неё, люди и машины в итоге помирились. Роль компьютера была прояснена. Он существует только чтобы помогать людям в их исследованиях.
С тех пор сюжет о компьютерах, порабощающих своих создателей, дал основу десяткам фильмов. Порой компьютеры поднимались на уровень сознания, который создатели не предвидели, порой страдали собственной версией нервного расстройства, а порой были просто тупо чересчур логичны. Порой компьютер настолько сходил с ума, что делал то, о чём здоровый человек не стал бы и думать, – например, начинал войну.
Всего несколько примеров (2): «2001: A Space Odyssey» (1968). Хороший компьютер, плохие решения. «Colossus: the Forbin Project» (1970). Американский суперкомпьютер требует соединить себя с русским суперкомпьютером, со всеми вытекающими. Как гласит ключевая реплика фильма, «Мы построили суперкомпьютер, обладающий разумом, и теперь должны сражаться за свой мир!» (3)
Роман Ira Levin’а «This Perfect Day» (1970) фильмом не был, а зря. Компьютер правит миром, и несколько храбрецов отваживаются восстать против него, чтобы узнать... ну, это роман Ira Levin’а, так что лучше пусть потом сюрприз будет. This Perfect Day. Рекомендую.
Многие вариации на ту же тему видны во WarGames (1983), да даже прошлым летом Голливуд исторг маленькую кинематографическую какашку под названием «Stealth», которую моя любимая газета The Onion провозгласила «самым гнетущим взглядом на сошедший с ума искусственный интеллект со времён Short Circuit 2». (4)
Сейчас-то легко говорить, как всё это смешно. Мы, к примеру, построили гигантскую компьютерную сеть по всему миру, и она пока что не продемонстрировала ни малейшего намёка на собственный интеллект. Можно представить, как всё это рухнет или заразится вирусом, но не как всё это пойдёт против нас. Что у Интернета, похоже, получается лучше всего, так это делать общедоступным необозримое количество дезинформации, о которой мы раньше понятия не имели.
Размышляя о том, как компьютеры взаимодействуют с человеком, я нахожу старые, докомпьютерные фильмы более адекватными – те, где занятые в автоматизированном производстве рабочие начинают подчиняться ритму машины. Вспоминается Metropolis Fritz Lang’а (1927), где необычная система обратной связи требует от людей управлять машиной, подчиняясь её командам. Начальные сцены из Modern Times (1936) Чарли Чаплина очень забавны до сих пор, и ещё эпизод из I Love Lucy под названием «Смена занятия» (1952), где Люси получает работу на кондитерской фабрике.
Хотя эти сцены часто призваны рассмешить, они всё же отражают нашу боязнь быть вовлечёнными в обезличенные взаимоотношения с машиной, которая навязывает свой нелепый цифровой ритм нашим в целом аналоговым душам. Отпечаток остаётся как на сознании, так и на теле. В I Am a Fugitive from a Slave Gang (1932) освобождённый из цепей заключённый уходит, передвигая ноги так, словно цепи всё ещё на нём. Так же, четырьмя годами позже в Modern Times Чаплин идёт домой после работы, а его руки подёргиваются в такт машины.
Пристрастие к технологии
С нашими компьютерами ситуация несколько иная. Конечно, можно заработать трясучку в руках от клавиатуры или мыши, но программное обеспечение влияет на тело совсем не в той степени, в которой на душу, причём влияет тонко и умело.
Иные из тех, кто смотрит, замечают, как некоторые приложения заставляют пользователя мыслить в жёстко заданных рамках, и ничего хорошего в этом нет. Один из самых продвинутых на этом поприще, конечно, PowerPoint. Стоит лишь начать помещать в его слайды то, что хочется донести до слушателей, как всё будет упорядочено в полудюжину пунктов маркированного списка.
Рецензии на тот или иной показ технологии в фильме часто прибегают к метафоре властности и порабощения. Я думаю, более уместно использовать иное сравнение для описания наших взаимоотношений с большинством современных потребительских технологий, назвав его пристрастием.
Мы легко можем сказать о некоей технологии: «мы и не знали, как сильно нуждались в ней, пока она не появилось», но большинство из них, похоже, нацелены не на то, чтобы удовлетворить некую потребность, а на то, чтобы подсадить нас на что-то, о чьей необходимости мы и не подозревали; не на то, чтобы сделать нашу жизнь лучше, а на то, чтобы прельстить нас очередным дизайнерским наркотиком. «Я жить не могу без моего ___________», нужное вписать. На этой неделе, думаю, там будет видео iPod.
Даже действительно полезные предметы вроде сотовых телефонов не избавлены от той же схемы. Был ли сотовый телефон придуман для удовлетворения конкретной потребности? Не уверен. Не думаю, что кто-то сидел в автобусе, думая: «Скукотища. Вот бы позвонить друзьям прямо из этого автобуса». Он был изобретён отчасти потому, что это было возможно, а также благодаря уверенности в том, что в конце концов люди жить без него не смогут. Стоит нам почувствовать вкус, и мы на крючке.
Мне часто хочется, чтобы электронной почты не существовало, но просто нет способа изобрести её обратно. Так что день за днём я старательно удаляю 99% полученных писем, а когда несколько дней не могу добраться до почты, оставляю домашний компьютер забирать её каждые 10 минут, чтобы не превысить предел какого-то объёма где-то там, и уже на следующий день ловлю себя на мысли о том, а кто же будет чистить мою папку входящих сообщений, когда я умру.
Мы видим, как компьютерные технологии проходят свой жизненный цикл, обращаясь из пользы во вред. Не так давно я устанавливал что-то с сайта Microsoft, и оно старательно давало мне инструкции по кликанью жёлтой полоски вверху Internet Explorer – той жёлтой полоски, которая теперь защищает нас от всплывающих сообщений и прочих нехороших вещей – так, чтобы я смог пройти сквозь обычную защиту против установки элементов управления ActiveX. Меня инструктировали игнорировать все предупреждения Windows на этот счёт, так как данный конкретный элемент управления, в отличие от всех остальных, и правда делает хорошие вещи.
Неудобства от Информации под рукой
Как-то в начале 1990-х Microsoft выступила со слоганом «Информация у вас под рукой». Звучит вроде бы хорошо, и сегодня у нас правда куча информации под рукой, вроде Google, Википедии, Internet Movie Database и других полезных сайтов.
Но информация сама стала пагубной привычкой. Я не знаю, как у вас, а мы даже не можем посмотреть простой повтор «Друзей», чтобы кто-нибудь не сказал: «Никак не могу вспомнить, кто эта актриса, играющая подружку Джо? Ну точно видел её где-то». Тогда мы нажимаем Info на пульте дистанционного управления, чтобы посмотреть название эпизода, и идём на tvtome.com или epguides.com, чтобы узнать, кто эта актриса, и потом, возможно, в Internet Movie Database, чтобы посмотреть список фильмов, шоу и просто появлений на экране с её участием, и тогда об одном из фильмов кто-то скажет «Всегда хотел его посмотреть», так что мы добавляем его в наш список NetFlix.
И всё это, разумеется, не сходя с дивана. А зачем ещё нам был бы нужен WiFi в студии 6 на 6 метров?
А через пять или десять лет мы сможем проделать всё это прямо пультом от кабельного телевидения, который может оказаться на самом деле пультом от компьютера, и потом ещё поставить «Друзей» на паузу, чтобы загрузить тот фильм, в котором снималась актриса, играющая роль подружки Джо, посмотреть его немного и снова вернуться к «Друзьям», если мы того пожелаем. И всё бы ничего, если бы в результате мы становились лучше, счастливее и приятнее во всех отношениях. Но сей вариант для меня неочевиден.
И я искренне надеюсь, что через пять или десять лет мы не будем всё ещё смотреть повторы «Друзей».
Все мы здесь компьютерные пользователи, сталкивающиеся с той же надоедливостью, тем же отвлечением внимания и теми же пристрастиями, что и все остальные пользователи, но мы также разработчики и программисты, и для нас опыт общения с компьютером должен быть по-настоящему иным. Программирование даёт нам огромные возможности, которыми мы и пользуемся. Мы пишем код, приводящий всех в восторг.
И поскольку все мы здесь разработчики .NET, мы, несомненно, пользователи Visual Studio. Уверен, кто-то уже смотрел беты Visual Studio 2005 и с нетерпением ждёт официального релиза на DevConnections в Лас-Вегасе через несколько недель.
Невозможно представить себе жизнь без Visual Studio, но, тем не менее, Visual Studio ничуть не меньше PowerPoint’а заставляет нас идти к цели предопределёнными путями, и мне, к примеру, было бы куда сподручнее, если бы она пыталась откусить куда меньше, чем пытается сейчас. Определённые возможности Visual Studio призваны повысить нашу продуктивность, но как по мне, они лишь порочат и принижают умения и опыт.
Разрастание API
Двадцать лет назад, в ноябре 1985, в Windows 1.0 было примерно 400 документированных функций. (5) Десятью годами позже, в Windows 95, их было далеко за 1000. (6) Сейчас мы ждём выхода .NET Framework 2.0. Если брать в расчёт только MSCORLIB.DLL и те сборки, которые начинаются со слова System, то там более 5000 публичных классов, в которых свыше 45000 публичных методов и 15000 публичных свойств, не считая тех, что унаследованы и не переопределены. Простое перечисление имён, возвращаемых значений и аргументов этих методов и свойств, по одному на строку, потребовало бы около тысячи страниц. Если написать каждый из этих методов и свойств на учётной карточке 3x5, снабдив кратким описанием его назначения, получится стопка высотой 12 метров. (7) Эти 60000 карточек, если их соединить в цепь – причём соединить длинными, а не короткими сторонами – могут опоясать Центральный Парк (почти), и ходят слухи, что следующим летом так собираются и поступить.
Может ли отдельно взятый программист в совершенстве овладеть 60000 методами и свойствами? Не думаю. Один из выходов – специализация. Я специализировался. Надеюсь, никто сегодня не будет задавать мне вопросы о веб-формах или SQL Server, потому что они в мою специализацию не входят. Я занимаюсь Windows.Forms и пишу на C#.
IntelliSense
Visual Studio пытается смягчить проблему разрастания классов, методов и свойств с помощью IntelliSense. IntelliSense и в самом деле обеспечивает информацию под рукой, если под рукой понимать то место экрана, где находится курсор.
Как и другие вызывающие привыкание технологии, IntelliSense у меня рождает чувства от любви до ненависти, и чем больше я презираю её, тем больше я её использую, и чем больше я её использую, тем большее отвращение у меня вызывает моё привыкание, и чем больше я привыкаю, тем больше я хочу, чтобы её не существовало.
На случай, если последнее время вы провели в танке: IntelliSense есть кульминация прошлых попыток создания технологии завершения кода. Напечатав, к примеру, имя объекта и поставив точку, вы получаете небольшой прокручиваемый список всех публичных методов, свойств и событий этого класса, и когда выбираете из него нужный и ставите открывающую скобку, появляется список перегрузок с их аргументами и с описанием назначения самого метода.
Некоторые считают IntelliSense самым важным нововведением в программировании после кофеина. Особенно хорошо она работает под .NET, потому что Visual Studio может через рефлексию получить всю нужную информацию прямо из указанной в ссылках DLL.
Собственно, IntelliSense стала первым звоночком о том, что вы не включили в проект ссылку на нужную DLL или не использовали ключевое слово using в начале своего кода. Вы начинаете печатать, а IntelliSense молчит. Вы тут же понимаете, что что-то не так.
Но IntelliSense также навязывает способ программирования.
К примеру, много лет программисты спорили, что лучше – писать код «сверху вниз», когда начинаешь с общей структуры программы и к концу программируешь наиболее частные процедуры, или «снизу вверх», когда идёшь от низкоуровневых процедур к общей структуре. Некоторые языки, такие как классический Pascal, в целом навязывали подход «снизу вверх», но другие языки нет.
Ну так споры окончены. Дабы IntelliSense работала правильно, нужен подход «снизу вверх». IntelliSense хочет, чтобы каждый класс, каждый метод, каждое свойство, каждое поле, каждый параметр, каждая локальная переменная была определена прежде, чем на неё можно будет сослаться. Если это не так, IntelliSense попытается заменить то, что печатаете вы, тем, что уже было определено, - и, что вероятнее всего, это совсем не то, что вы хотели.
Печатаете вы, к примеру, какой-то код и решаете, что неплохо бы ввести переменную по имени id, и вместо того, чтобы сначала определить её, сразу начинаете печатать выражение, начинающееся с id и пробела. Я всегда печатаю пробел между переменной и знаком равенства. Раз id не была определена, IntelliSense найдёт что-то, что начинается с этих двух букв, а также синтаксически подходит к контексту вашего кода, с учётом всех ссылок и пространств имён. В моём случае IntelliSense решила, что я собираюсь объявить переменную интерфейсного типа IDataGridColumnStyleEditingNotificationService, который я в жизни своей не использовал.
С одной стороны, если вы действительно собирались объявить объект типа IDataGridColumnStyleEditingNotificationService, всё что нужно сделать – напечатать id и пробел. Если же это не так, можно убрать внесённые IntelliSense изменения командой Undo (Ctrl-Z). Правда, я бы хотел стукнуть её по рукам и сказать «Нельзя», но увы, работает только Ctrl-Z. Кто бы мог подумать, что Ctrl-Z станет одним из самых важных сочетаний клавиш в современных приложениях Windows? Ctrl-Z работает и в Microsoft Word, когда тот чересчур активно исправляет написанное вами.
Но результат ошеломляет. Чтобы IntelliSense заработала, нужно не только писать код «снизу вверх», нужно ещё внутри каждого метода и свойства писать код от начала до конца – точно так же, как если бы вы использовали старый досовский редактор строк, EDLIN. Вы должны сначала объявить все переменные. Никаких пропущу-потом-вернусь в коде. Не то чтобы IntelliSense учила нас программировать как автомат, скорее, IntelliSense была бы счастлива, если бы оно было так.
И я думаю, это отупляет. Вместо того чтобы выяснять нужный метод или попытаться запомнить трудное имя свойства, я прокручиваю список вариантов, предложенных IntelliSense, ища схожее название или хотя бы что-то, что походит на правду.
Я больше не должен помнить всё. IntelliSense помнит всё за меня. Кроме того, если быть честным, я и правда не хочу засорять свою голову 60000 методами и свойствами. Моей психике, несомненно, пойдёт на пользу такое незнание, но в то же время я не смогу достичь свободного стиля программирования, потому что код не берётся целиком из моей головы. Он берётся в результате постоянного диалога с IntelliSense.
Так что я не думаю, что IntelliSense делает программиста лучше. Она делает программиста быстрее, что также означает удешевление нашего труда.
Конечно, её всегда можно отключить.
Что, вот так вот просто соскочить? Ну попробуйте!
IntelliSense – неотвратимая технология. Если бы не Microsoft, кто-нибудь другой воплотил бы её. Ещё никогда люди не отказывались от какой-то технологии лишь потому, что она может иметь печальные последствия.
Сгенерированный код
Visual Studio не только пытается завершить набираемый нами код, но вот уже много лет она хочет писать код за нас. Если выбрать новый проект, Windows Application, к примеру, дать ему имя и расположение на диске, Visual Studio сгенерирует достаточно кода, чтобы проект можно было немедленно скомпилировать и запустить.
Каким-то образом нас убедили, что именно это правильный способ программирования. Не знаю почему. Лично я нахожу массу удовольствия, начиная программу с чистого листа. Мне нравится печатать самое начало, и потом функцию или метод Main. Когда мне действительно нужна помощь, так это не когда я начинаю программу, а когда пытаюсь её закончить. И где же Visual Studio в этот момент?
Мысленно откроем Visual Studio 2005 и создадим программу Windows Forms с помощью C#, проект типа Windows Application, и проанализируем код.
Прежде всего, мы видим, что Visual Studio привязала нашу программу к набору библиотек, которые, как она думает, нам понадобятся. Она создала ссылки не только на сборки System, System.Drawing и System.Windows.Forms, которые нужны для любого нетривиального приложения Windows Forms, но также на System.Data, System.Deployment, и System.Xml, вне зависимости от того, надо вам это или нет. Эти дополнительные ссылки вреда не приносят, пока кто-то не начнёт просматривать программу – чтобы, скорее всего, внести какие-то изменения после ухода написавшего её программиста – и решит, что приложение действительно требует эти ссылки. Возникает неразбериха, потому что на самом-то деле ссылки есть, но программе они не нужны.
Среди других файлов Visual Studio создаёт файл по имени Form1.cs, который вам любезно разрешается редактировать. Это исходник с обработчиками событий главной формы. В начале куча using тех неймспейсов, которые нужны программе. Для программ Windows Forms это System, System.Drawing и System.Windows.Forms, но Visual Studio добавляет ещё System.Collections.Generic, System.ComponentModel, System.Data и System.Text, некоторые из которых, конечно, полезны, но если программа их не использует, они просто бессмысленно отвлекают внимание.
Visual Studio также заключает весь сгенерированный код в пространство имён, названное по имени приложения. Нет, я прекрасно понимаю пользу от пространств имён в библиотеках, но в приложениях? Я много думал, но причину постичь не смог.
Я тут говорю о коде, но когда вы создаёте новый проект Windows Forms, Visual Studio не являет вам никакого кода. Вместо этого вы видите форму, которую должны немедленно заполнять элементами управления.
Visual Studio создаёт также файл Form1.Designer.cs, и в бета-версиях Visual Studio 2005 этот файл не был даже перечислен по умолчанию среди файлов проекта. Туда Visual Studio вставляет сгенерированный код, когда вы дизайните форму. Visual Studio очень не хочет, чтобы вы копались в этом файле. Visual Studio хочет, чтобы этот файл был в определённом формате, а если вы там покопаетесь, она может не суметь его открыть в следующий раз.
Происхождение Дизайнера
Конечно, интерактивный дизайн форм – одна из главных возможностей Visual Studio. Сравните дизайнер Visual Studio с тем, как программировали под Windows 20 лет назад, когда вышла Windows 1.0 – 20 лет исполнится в следующем месяце, если быть точным.
Не хочу утомлять присутствующих страшными сказками о программировании под Windows 1.0, но в целом большую часть времени при этом вы проводили вне Windows, в командной строке DOS. Правишь код своим любимым редактором, – моим любимым был текстовый процессор эпохи под названием WordStar, – компилируешь и линкуешь его с командной строки, и потом запускаешь приложение в Windows, печатая Win и имя исполняемого файла. Тестируешь программу в Windows, выходишь из Windows в DOS и снова загружаешь исходный код в редактор.
Из-под Windows было нельзя заниматься разработкой, за исключением рисования иконок, курсоров и небольших картинок в Icon Editor.
Для определения структуры меню и диалоговых окон создаёшь текстовый ресурсный скрипт. В нём шаблоны для тех самых меню и диалоговых окон в определённом формате. Для диалоговых окон просто перечисляешь те элементы управления, которые должны в них появиться. Синтаксис не так уж плох, к примеру, ключевое слово BUTTON, вслед за которым надпись, которая должна быть на кнопке, координаты кнопки и её размеры. Поскольку Windows может быть запущена на системах с разными разрешениями экрана, эти размеры и координаты задаются в особой координатной системе диалогового окна, где горизонтальные единицы равны ¼ ширины системного шрифта по умолчанию, а вертикальные – 1/8 высоты того же шрифта.
В то время считалось, что эти скрипты экономят уйму времени. Если бы скрипта не было, пришлось бы создавать меню и элементы управления в коде, а это задачка та ещё. А синтаксис был таким простым и понятным, что до сих пор остаётся самым лаконичным способом описания меню и диалоговых окон из всех, что я видел.
Была только одна небольшая проблема: все элементы управления нужно было разместить в соответствии с числами, которые ещё предстояло вычислить. Порой было весьма полезно взяться за бумагу и карандаш и набросать эскиз окна. В противном случае приходилось идти методом проб и ошибок, туда и обратно, загрузить Windows, вызвать диалог, оценить его корявость, выйти из Windows, загрузить ресурсный скрипт – и таким вот способом в конце концов разместить всё так, как должно быть.
Как-то около 1986 года из глубин Microsoft появилась бета-версия редактора диалогов. Я узнал о ней, следя за доской объявлений Windows Developers Roundtable на информационном сервисе GEnie, General Electric Network for Information Exchange. Это была программа под Windows, позволявшая интерактивно разрабатывать диалоговые окна, двигая по ним элементы управления, на выходе же был шаблон диалога в правильном формате. В конце концов, я написал статью о ней, опубликованную в самом первом номере Microsoft Systems Journal в октябре 1986 г. Статья называлась «Новейший редактор диалогов ускоряет разработку приложений Windows». Но в Windows-программах, написанных мною позже для MSJ и для первого издания Programming Windows, этот редактор я не использовал. Не использовал потому, что выдаваемый им результат был безобразным.
Позвольте объяснить, что я имею в виду и почему.
Те, кто пишут код для публикации, сталкиваются с дополнительными ограничениями, до которых большинству программистов нет дела. Код, который мы пишем, должен быть кратким, но оставаться ясным. Он должен быть хорошо отформатирован и легко читаем. Он должен содержать достаточно пробелов. Он должен быть воздушным. В нём не может быть ненужных переменных или неиспользуемых функций. Он должен компилироваться без выдачи предупреждений.
Более того, публикуемый в книгах код ограничен по ширине строки 80 символами, плюс-минус. У журналов порой требования серьёзнее, в зависимости от политического веса верстальщиков среди сотрудников журнала. Microsoft Systems Journal – случай интересный. Хотя MSJ изначально должен был быть непосредственно о программировании под Windows, – потом, правда, пошёл на попятный и стал освещать программирование и под DOS, – верстался он исключительно на Маках, и отдел вёрстки рулил всеми. В почёте были узкие колонки текста, и я помню, как MSJ собирался сделать их ещё уже как раз в то время, когда в OS/2 Presentation Manager появились вызовы функций типа GpiQueryModelTransformMatrix.
С учётом этих критериев, редактор диалогов генерировал безобразный и бесполезный вывод. Он даже не использовал BUTTON, LABEL и LISTBOX, как сделал бы нормальный человек. Нет, всё было загажено универсальным CONTROL, за которым следовало имя класса. В его строках было полно излишней информации. Были перечислены все параметры, пусть даже они повторяли значения по умолчанию. Эти строки были далеко за 80 символов.
Людям приходилось бы это читать, но вывод редактора диалогов был нечитаем. Если же кто-то попытался бы воспроизвести диалоговое окно вручную, не было вообще никакого смысла показывать им вывод редактора диалогов.
Когда я работал над первым изданием Programming Windows в 1987, я иногда использовал редактор диалогов, после чего вручную исправлял его вывод на что-то человеческое. Более всего я при этом навострился разрабатывать диалоги вручную.
Конечно, редактор диалогов тоже «неизбежная технология». Необходимость его создания была чересчур очевидна, и в целом, я не могу назвать ни одного аргумента против него. Что меня и правда раздражает, так это во что он вылился.
Интерактивный дизайн
Большинство действительно новаторских приёмов интерактивного дизайна впервые встречается в Windows-версии Visual Basic, и вот здесь я и начал беспокоиться о том, куда движется программирование под Windows. Вы могли не только поместить кнопку туда, куда вам хотелось, вы также могли кликнуть её, и Visual Basic помещал обработчик этого события в ваш код.
Это меня обеспокоило, поскольку Visual Basic рассматривал программу не как слитный текст, а как маленькие кусочки кода, присоединённые к визуальным объектам. Программа таковой не является. Компилятор видит совсем другое. Как можно в этом случае ощутить целостность программы? Я был озадачен.
В итоге, интерактивный дизайн пробил себе дорогу в разработку на C++, и в Microsoft Foundation Classes, и там, как мне кажется, сгенерированный код активно использовался, чтобы скрыть собой корявые корни MFC, о которых никто не хотел говорить.
У автора, пишущего книги по программированию, всё это вызывает недоумение. Как написать пособие? Делать акцент на использовании Visual Studio при разработке приложений? Не скрою, мне весьма непросто писать предложения типа «Теперь перетащите кнопку с панели инструментов на вашу форму» и при этом думать, что я учу программировать. Я никогда не писал о C++ и MFC, отчасти потому, что MFC походит на тонкую обёртку вокруг Windows API и лишь слегка объектно-ориентированна. Я продолжал работать над следующими изданиями Programming Windows, предполагая, что их читатели, как и я, программисты, предпочитающие писать собственный код от начала до конца.
Прощай, ресурсный скрипт
Впервые я стал разбираться с бетой .NET 1.0 и Windows Forms летом 2000 года, и они были куда более объектно-ориентированными, чем когда-либо могла быть MFC. Мне понравилось. Меня заинтересовало, что ресурсный скрипт вообще исчез. Вы создаёте и комбинируете элементы управления на диалоговом окне – теперь отнесённом к более общему понятию «форма» – прямо из кода. Конечно, даже в Windows 1.0 вы могли создавать элементы управления из кода, и примеры тому есть в первом издании Programming Windows. Но как-то это было не очень приятно, потому что создание каждого из них требовало вызова функции CreateWindow с 11 аргументами. В то время как создание их же в Windows Forms было моментальным.
Что мне нравится в создании и управлении контролов из кода, так это то, что они создаются и управляются из кода. Предположим, вы хотите колонку из 10 кнопок одного размера с равными промежутками между ними для вывода названий цветов. В программе можно хранить эти 10 значений цвета в одном месте. Это называется массив. Есть также замечательный способ создать и расположить эти 10 кнопок. Он называется цикл for. Вот программирование.
Но Visual Studio не хочет, чтобы вы создавали массивы или циклы для создания и размещения кнопок. Она хочет, чтобы вы использовали дизайнер, и сгенерированный им код она прячет туда, где вы его не видите.
Двадцать лет прошло со времён первого редактора диалогов, и теперь тем же самым занимается Visual Studio – генерирует безобразный код и предупреждает, чтобы вы его не испортили ненароком.
Если вы попытаетесь читать этот код, вам будет трудно, потому что каждый класс и структура уточнена полным именем пространства имён:
- Код: Выделить всё
System.Windows.Forms.Button button1 = new System.Windows.Forms.Button();
Конечно, мы понимаем, почему Visual Studio приходится поступать именно так. Вы можете добавить на панель инструментов другой элемент управления по имени Button, из другой DLL и другого пространства имён, и нужен способ различать их.
Генерируя код по следам ваших действий, Visual Studio даёт элементам управления стандартные имена вроде button1, button2, button3, label1, label2, label3, textBox1, textBox2, textBox3.
Конечно, имя можно изменить. Вы меняете свойство Name элемента управления, тем самым меняя не только само свойство, но и имя переменной, связанной с кнопкой.
А программисты вообще этим пользуются? Некоторые, безусловно, да, но многие, безусловно, нет. Откуда я знаю? Посмотрите на примеры кода от Microsoft. Там вы увидите button1, button2, button3, label1, label2, label3 и т.д. А между тем любой согласится, что один из важнейших элементов самодокументируемого кода – осмысленные имена переменных и объектов.
Если бы Visual Studio действительно хотела, чтобы код писался хорошо, при каждом перетаскивании элемента управления на форму она просила бы «Введите осмысленное имя для этого элемента управления». Но Visual Studio не хочет, чтобы код писался хорошо. Она хочет, чтобы он писался быстро.
Всё же в плане присвоения имён переменным следует отдать должное Visual Studio. В Visual Studio 2005 есть великолепнейший инструментарий для переименования. Знаете как бывает, когда очень хочется переименовать переменную, чтобы она более точно отражала своё окончательное назначение, но вы боитесь побочных эффектов поиска и замены? Новая переименовывалка позволяет избежать их, и подскажет, если новое имя совпадёт с существующим. Надеюсь, люди воспользуются этим средством, чтобы изменить имена своих элементов управления на отличные от присвоенных по умолчанию.
Злоупотребление полями
Другая проблема кода, сгенерированного Visual Studio, в том, что каждый элемент управления создаёт поле в классе, в котором описан. Это отвратительная практика, и меня особенно беспокоит, что люди будут смотреть в код, сгенерированный Visual Studio, чтобы научиться программировать правильно, и научатся этому.
В дообъектно-ориентированные времена программирования на C были локальные переменные и глобальные, внутри функций и снаружи. Одной из целей хорошего программирования на C было сведение количества глобальных переменных к минимуму. Поскольку глобальная переменная могла быть изменена внутри любой функции, становилось проще понять программу, в которой таких переменных было немного – а функции общались между собой исключительно через аргументы и возвращаемые значения.
Со временем, однако, C-программисты несколько, скажем так, расслабились, и наплодили массу глобальных переменных, в которых не было необходимости, просто потому, что так было проще всего. Зачем добавлять ещё один аргумент в функцию, если можно хранить его глобально?
Глобальные переменные практически исчезли в объектно-ориентированном программировании, за исключением полей, которые стали новыми глобальными переменными, и допускали точно такое же неумелое обращение.
Базовый принцип объектно-ориентированного программирования – спрятать данные. Чаще всего имеется в виду – между классами. Классы не должны предоставлять всё, чем владеют. Публичный интерфейс следует сократить насколько это возможно, и остальные классы должны знать только то, что им действительно нужно. Но тот же принцип имеет ничуть не меньшее значение внутри класса. Методы должны иметь ограниченный доступ к данным, используемым другими методами. Переменные, в общем случае, должны быть локальными для метода, если только нет реальной причины сделать их доступными другим методам.
Когда вы создаёте объект с использованием оператора new, количество памяти, выделенной из кучи для одного объекта, должно быть достаточным, чтобы уместить все поля, определённые в его классе и всех его предках. Поля в основном и определяют размер объекта в памяти. Я знаю, что уже давно позади те времена, когда каждый байт был на счету, но когда вы смотрите на поля, определённые вами в классе, спросите себя – а мне правда надо хранить всю эту фигню в куче для каждого объекта? И действительно ли я ограничился только набором полей, достаточных для поддержания объекта?
Кто-то рассказал мне, что хранит объекты как поля, потому что боится, что сборщик мусора .NET сдует всё, что не прибито к соответствующему описанию поля. После нескольких лет описания самого минимума полей в .NET могу сказать, что это не проблема. Сборщик мусора .NET удаляет только то, на что больше нет ссылок нигде в программе. Если вы каким-то образом можете обратиться к объекту, он не попадает в сборку мусора.
Теоретически, никакой элемент управления, созданный как часть формы, не требует хранения в поле, потому что родитель – обычно форма – хранит все дочерние элементы управления в коллекции Controls, и можно обратиться к любому через эту коллекцию, используя номер или текст свойства Name, присвоенного при создании. Ещё одно место, где приятно иметь осмысленные имена, а не button1, button2, button3, label1, label2, label3...
Объявлять ли конкретный объект как поле или как локальную переменную – это то, над чем мы, программисты, должны думать при создании каждого нового объекта. Метка с фиксированным текстом запросто может быть локальной. Метку с текстом, устанавливаемым из обработчика событий другого элемента управления, удобнее хранить как поле.
Всё очень просто. Но Visual Studio не хочет, чтобы вы думали об этом. Visual Studio хочет, чтобы всё хранилось как поле.
Демистификация Visual Studio
Даже если бы Visual Studio генерировала чистейший код, оставалась бы одна проблема. Генерируя код, Visual Studio возводит барьер между ним и программистом. Visual Studio, опираясь на некие известные только ей аспекты современного программирования, намекает, что это единственный путь писать приложения под Windows или веб. И усиливает эффект, добавляя шаблонный код, содержимое которого не освещено сколь бы то ни было подробно в руководствах и документации от Microsoft.
Для меня, как для преподавателя программирования под Windows Forms и Avalon, становится очевидной необходимость двигаться в прямо противоположном направлении. Я чувствую, что должен сорвать покров таинственности с того, что делает Visual Studio, и показать вам, как разрабатывать те же приложения собственный кодом, компилируя его, если захочется, из командной строки вообще без Visual Studio.
Во многих книгах, посвящённых Windows Forms, я рекомендую читателям в начале нового проекта выбирать не Windows Application, а Empty Project. Empty Project не содержит ничего, кроме файла проекта. Все ссылки и весь код нужно добавить самостоятельно.
Оказываю ли я программистам услугу, показывая им, как писать код способом, диаметрально противоположным духу используемого ими инструмента? Я не знаю. Возможно, я не прав, но альтернативы не вижу.
Динамическая разметка
Я упоминал о выходе Visual Studio 2005 в следующем месяце. С ней идёт .NET Framework 2.0, несущий значительные изменения в Windows Forms, включая сильный уклон в сторону «динамической разметки» (также известной как «автоматическая разметка»). Динамическая разметка играет значительную роль и в философии Avalon.
Она – пример того, как стандарты веба проникли в Windows-приложения. Мы знаем, что в HTML совсем необязательно задавать каждому объекту точные координаты. Мы знаем, что менеджер разметки, встроенный в браузеры, может сместить текст и картинки вниз по странице или сгруппировать контент в таблицы или фреймы. HTML также отлично показал, как этого делать не нужно, так что вслепую идти не придётся.
Вкратце, когда вы используете динамическую разметку в Windows Forms, фактическое положение и размеры элементов управления неизвестны до времени выполнения. Когда форма отображается, менеджер разметки учитывает размеры всех элементов управления, размер контейнера и размещает их соответственно.
Динамическая разметка под Windows стала необходимой по ряду причин. Прежде всего, недалеки те времена, когда появятся мониторы с разрешением 200-300 dpi. Будет очень приятно, если написанные сегодня приложения Windows не сольются в одну точку на таких мониторах.
Кроме того, чем сложнее становятся элементы управления, тем труднее использовать их в предопределённой разметке. Насколько велик должен быть конкретный элемент? А если это можно узнать только в рантайме? Куда лучше, если не программа навязывает элементу управления размеры, а наоборот, элемент определяет свои размеры в рантайм, и они учитываются при создании разметки.
Понятно, что это непросто, поскольку менеджер разметки должен спросить у всех элементов управления, какого размера они хотят быть, а затем попытаться разместить их всех на фиксированной области экрана.
Всё это содержится в классах Windows Forms 2.0. FlowLayoutPanel и TableLayoutPanel, наряду со SplitContainer и свойством Dock обеспечивают весь набор инструментов для динамической разметки. Можно проектировать целые формы и диалоговые окна без использования пиксельных координат и размеров. Несомненно, есть исключения. Мне, скорее всего, понадобится задать ширину выпадающих списков, используя как единицу среднюю ширину символа. Для большинства остальных случаев всё работает и так. В своей новой книге я посвятил целую главу динамической разметке, которая заканчивается кодом, повторяющим стандартный FontDialog с помощью TableLayoutPanel, получилось довольно неплохо.
Теперь у нас есть оформленные в виде классов инструменты, которые позволяют признать дизайнер форм Visual Studio устаревшим. К сожалению, никто не сообщил Visual Studio об этом. Visual Studio прекрасно поддерживает разметку на основе FlowLayoutPanel и TableLayoutPanel, но вам придётся самостоятельно узнавать об этих вещах и вручную помещать их на форму до создания элементов управления. А Visual Studio неизвестно зачем будет хранить пиксельные координаты и размеры в вашем исходном коде, хотя в данном случае они просто неуместны.
Avalon и XAML
Кое-кто предположил, что с планируемым представлением Avalon – теперь носящим окончательное имя Windows Presentation Foundation – в следующем году Windows Forms уже можно считать устаревшими. Но чем больше я смотрю на Avalon, тем меньше верю, что это так. Avalon, безусловно, обладает достаточными возможностями и размахом, чтобы поддерживать большие приложения, а графическая подсистема даст в руки среднему программисту весь потенциал 3D.
Но Avalon на данный момент не содержит некоторое из того, что мы принимаем как должное – стандартные диалоги «Открыть», «Сохранить» и «Шрифт», split panel, и ничего даже близко напоминающего совершенно потрясающий DataGridView из Windows Forms 2.0. Попадёт ли всё это в Avalon до релиза, я не знаю. Но Windows Forms всё ещё могут быть лучшим вариантом создания оконных приложений для внутрикорпоративного использования.
Avalon, как я уже говорил, имеет заметный уклон в динамическую разметку. В Windows Forms по умолчанию используются пиксельные координаты и размеры. Необходимо явно создать FlowLayoutPanel или TableLayoutPanel, чтобы освободиться от пикселей.
В Avalon работа с пикселями по умолчанию не предлагается. Для каждого окна или страницы нужно выбрать модель разметки, и та, которая использует пиксели – потомок Panel по имени Canvas, – определённо не преподносится как лучший выбор. И даже если выбрать Canvas, работать вы будете не с пикселями, а с чем-то странным под названием «аппаратно-независимые пиксели», координатной системой с единицей, равной 1/96 дюйма, что один в один совпадает с современными видео-настройками по умолчанию, но позволяет достичь независимости от устройства и его настроек.
Но это даже не половина всего. Для сборки окон и диалогов в Avalon можно использовать как код, так и XML. Microsoft представила целый язык разметки страниц под названием XAML, Extensible Application Markup Language, произносится как «zammel». В хорошей программе под Avalon XAML должен хранить всё, что касается разметки, а программный код связывает всё это воедино, в основном обработчиками событий.
Вначале я скептически относился к этому изобретению по имени XAML. Мне нравилось, как в Windows Forms я делаю всё кодом, а теперь вдруг в Windows-программировании снова появляется ресурсный скрипт – пусть и куда более сложный. Постепенно я втянулся, и теперь мне это нравится.
Одна из вещей, которых пытаются добиться создатели Avalon, - позволить программистам и дизайнерам работать с общими файлами. Не в каждом программном продукте требуются дизайнеры экранов и диалоговых окон, но в больших требуются, и в прошлом дизайнеры рисовали эскизы в графических редакторах и доносили свои идеи до программистов через картинки. В Avalon инструменты дизайнера создают XAML, а программисты используют этот XAML как исходный текст для создания приложений.
Ещё одна причина, благодаря которой я втянулся: при уходе в динамическую разметку форма превращается в иерархию панелей и элементов управления разных типов. Можно начать с DockPanel, поместить меню и панели инструментов вверху окна, между ними панель Grid, и, возможно, в какой-то из её ячеек StackPanel, ну и так далее.
Эта иерархия панелей и элементов управления в XAML описывается вложенностью. Если отступы в XAML проставлены правильно, вложенность можно видеть прямо в файле.
Да и с визуальным редактором, генерирующим XAML, у меня было куда меньше проблем, чем с генерирующим C#. Как мы уже поняли, Visual Studio не хочет, чтобы вы просто видели C#, который она генерирует, и на то у неё есть причина. С XML ситуация иная. Сам смысл создания XML был в том, чтобы его могли создавать и редактировать и машины, и люди, причём неважно, кто именно. До тех пор, пока XML остаётся синтаксически правильным, – а почти правильным он быть не может, - неважно, кто его редактировал и в каком порядке. Если я собираюсь поместить XAML в книгу, не имеет значения, я написал его, или это сделала Visual Studio, потому что результат в целом тот же. И для тех, кто захочет самостоятельно воссоздать разметку панелей и элементов управления в Visual Studio, XAML прекрасно проиллюстрирует иерархию.
Будет ли встроен в Visual Studio дизайнер, работающий исключительно с XAML и позволяющий мне писать мой собственный код на C#? Пока не знаю. Но было бы здорово.
Я также надеюсь, что разработчики в конце концов отточат баланс между XAML и кодом. Создатели Avalon так гордятся XAML, – и по праву, - что стремятся использовать его везде. Я видел приложение-часы под Avalon, написанное кем-то из Microsoft. Оно единожды устанавливало время из кода, а потом использовало только анимацию Avalon, описанную в XAML, чтобы часы шли. Оно было очень, очень классное, за исключением того, что 12 часовых отметок были исполнены 12-ю практически идентичными кусками XAML. Единственная вещь, которая потрясла бы меня в большей степени – лицезрение 60 секундных отметок, выполненных 60-ю идентичными кусками XAML.
Я не знаю, каких правил придерживаетесь вы, но для меня всё просто: «Больше двух - используй for» (“Three or more: Use a for.”). Вот почему у нас есть циклы. Вот почему мы программисты.
Чистое наслаждение чистым программированием
Пару месяцев назад, – наверное, чтобы как-то отвлечься от навороченного программирования под Windows Forms и Avalon, – я снова начал программировать на C. Так, по мелочи. Журнал, который я читал, – английский еженедельник New Scientist, – каждый раз содержит небольшую рубрику под названием «Enigma», с небольшой математической задачкой. Вот одна из июньского номера: «Найдите наибольшее целое число, состоящее из неповторяющихся цифр (среди которых нет 0), которое делится на каждую свою цифру» (8). Решив загадку Enigma, можно выслать ответ, и случайно выбранный счастливчик получит 15 фунтов и будет упомянут в журнале.
Эти задачки раздражали меня годами, потому что всегда казалось, что их легко решить простейшей программой, которая переберёт все варианты, а это казалось мне нелепым.
Но всё же несколько месяцев назад я решил, что стоит попробовать порешать их кодом, и потом разместить ответы и программы на сайте на следующий день после истечения срока сдачи решений, но примерно за неделю до выхода журнала в печать.
Я решил использовать старый чистый ANSI C, редактировать исходный код в Notepad – не обладающем IntelliSense или разумностью (в оригинале снова «sense» – прим. перев.) любого иного рода – и компилировать с командной строки, используя Microsoft C compiler и Gnu C compiler.
Что было особенно приятно, так это что мне не надо было никуда подглядывать. Я писал на C 20 лет. Он был моим любимым языком до появления C#. Здесь просто чистое алгоритмическое программирование с простым текстовым выводом. И больше ничего.
Оказалось также, что задача требует некоторых предварительных размышлений. Очень часто число всех возможных комбинаций неподъёмно. Нужно серьёзно сузить круг поиска. Вы ведь не хотите писать программу, которая будет работать неделю, прежде чем дойдёт до команды printf. Вот хотя бы задача, за которую я взялся: «Найдите наибольшее целое число, состоящее из неповторяющихся цифр (среди которых нет 0), которое делится на каждую свою цифру». Весьма полезно догадаться, что это число не может содержать цифру 5, если содержит также любую чётную цифру, потому что тогда оно делилось бы на 10, и последняя цифра была бы 0, что противоречит условию. Так что число, по всей видимости, не содержит 5. Это тут же сокращает количество вариантов на порядок.
Даже после этого начального успеха ещё остаётся что программировать, но здесь нет API, нет классов, нет свойств, нет форм, нет элементов управления, нет обработчиков событий, и уж определённо нет Visual Studio.
Есть только я и код, и пусть ненадолго, но я снова чувствую себя настоящим программистом.
1) Это было в конце 70х. Я работал в New York Life Insurance Company на 51 Мэдисон Авеню, программировал на PL/I на IBM 370 через TSO (Time Sharing Option) и на терминале IBM 3278. Для редактирования кода я использовал новомодный "полноэкранный редактор", называемый FSE. В какой-то момент я нажал Backspace, но курсор не сдвинулся назад на один символ, вместо этого на один символ сдвинулся назад весь экран, включая рамку редактора, и начало каждой строки оказалось в конце предыдущей. Словно пополз весь буфер экрана. Я нажал Backspace ещё несколько раз, и произошло то же самое. Затем это начало происходить само по себе, линии описывали спираль по экрану и уходили вверх, пока весь экран не стал окончательно пустым. Мы позвали ремонтника из IBM. Я страшно хотел описать ему, что произошло, и услышать его вердикт, но 3278-ые они ремонтировали не так. Ремонтник притащил ящик с печатными платами и заменял их, пока терминал снова не заработал.
2) А другие можно найти на странице “Hollywood & Computer” сайта Charles Babbage Institute: http://www.cbi.umn.edu/resources/hollywood.html.
3) “Taglines for Colossus: The Forbin Project,” http://www.imdb.com/title/tt0064177/taglines.
4) “Focus: Misguided Missiles,” The Onion (New York City print edition), vol. 41, no. 30, pg. 15.
5) Посчитано вручную в разделе “Quick Reference” в Microsoft Windows Software Development Kit: Programmer’s Reference (Microsoft Corporation, 1985).
6) Charles Petzold, Programming Windows 95 (Microsoft Press, 1996), pg. 17.
7) Упаковка из 500 Staples brand cards примерно 10 см в высоту.
8) “Enigma 1343: Digital Dividend,” New Scientist, 4 June 2005, 28.
прослезился.
