Старший архитектор JavaScript в Yahoo! Дуглас Крокфорд занимается программированием с середины 1970-х — тогда, в колледже, не получив студийного времени по своему основному предмету — телевещанию, он прослушал курс Фортрана. Всю карьеру он совмещал программирование и медийную деятельность в таких компаниях, как Atari, Lucasfilm, Electric Communities, а теперь — Yahoo!.

Крокфорд по натуре склонен к простоте и аккуратности. Он изобрел JSON — формат передачи данных, широко применяемый в Ajax-приложениях, поскольку XML, с его точки зрения, слишком сложен. В его недавней книге «JavaScript: The Good Parts» (JavaScript: положительные стороны) утверждается, что JavaScript — весьма неплохой язык, если избегать некоторых его возможностей. В беседе со мной Крокфорд подчеркивает важность иерархии как способа борьбы со сложностью и описывает свой метод чтения кода, который начинается с его чистки.

Ко времени нашего интервью Крокфорд уже был известен как непримиримый критик ECMAScript 4 (ES4) — новой версии стандарта языка ECMAScript (JavaScript), поскольку считает ее слишком сложной. Он высказывался в пользу версии с менее масштабными изменениями — ES3.1. В конце концов, точка зрения Крокфорда и других защитников ES3.1 возобладала, версия ES3.1 получила название ES5, a ES4 была официально отвергнута.

Мы с Крокфордом беседовали о том, что ему не нравится в ES4, о важности чтения кода как части работы в команде и о том, как совершенствовать Сеть, несмотря на имеющиеся в ней старые системы.

Сейбел: Как вы начали заниматься программированием?

Крокфорд: Я учился в Университете Сан-Франциско. Поступил туда потому, что там была хорошая система подготовки специалистов для телевидения. Но в первый год мне не удалось получить доступ к студии, и по счастливой случайности я решил посещать курс языка Фортран на математическом факультете. Оказалось, у меня прекрасно получается, так что я продолжил изучение в следующем семестре.

Это был 1971-1972 учебный год. В библиотеке хранилось множество перфокарт. Разделение времени только-только начало внедряться. В Университете Сан-Франциско не было сильного инженерного факультета, который бы занимался всеми компьютерами. Вместо этого они были распределены по всему колледжу. Свои лаборатории были на факультете естественных наук, в школе бизнеса, на гуманитарном и педагогическом факультетах. Интересно, что все эти факультеты использовали компьютеры.

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

Потом я все же получил доступ к студии и занялся всякими телевизионными делами. Это было весело, но в конце концов я решил посвятить себя компьютерам. При этом постоянно думал, как объединить обе эти вещи. Я предчувствовал многое из того, что сейчас называют мультимедиа и цифровым мультимедиа. Впоследствии я не раз возвращался к работе с медиа, а потом опять к компьютерам.

Сейбел: Итак, вы начали с Фортрана и поняли, что делаете в нем успехи. Чем еще привлекало вас программирование, кроме мысли о том, что у вас это получается?

Крокфорд: Только это. Это был мой первый семестр в колледже, надо было прослушать один курс на математическом факультете, я выбрал его наугад, и это оказался курс Фортрана. Так что я не шел туда специально для того, чтобы научиться программированию. Просто так вышло.

Сейбел: Помните свою первую действительно интересную программу?

Крокфорд: Давно это было. Кажется это была программа дизассембли-рования работающей системы на Фортране для системы с разделением времени, которую я использовал. В процессе ее написания я понял, как работает система, и многое узнал о программировании, основанном на этой модели, включая некоторые вещи из того, что обычно не публиковалось.

Сейбел: По сравнению с тем временем, что больше всего изменилось в вашем подходе к программированию?

Крокфорд: Был период, лет десять, когда важнейшим фактором была производительность. Кажется, это было в самом начале эры микропроцессоров, когда объем памяти был крайне небольшим, а процессоры работали очень медленно. Мы засели за ассемблер для разработки игр или прослушивания музыки, чтобы они влезали в доступную память и работали достаточно быстро. Но этот этап пройден, и сегодня мы создаем большие приложения на JavaScript, работающие в браузере. Это чрезвычайно неэффективная среда по сравнению с теми, в которых мы привыкли работать, но благодаря закону Мура мы вполне можем себе это позволить.

Сейбел: Есть ли сожаления по поводу того пути, который вы выбрали, изучая программирование?

Крокфорд: Есть интересные языки, поработать с которыми мне так и не пришлось. Я много читал об APL и понимаю, почему он погиб, но это был очень логичный язык; жаль, что так и не удалось им позаниматься. Были и другие подобные языки, которыми я интересовался, читал о них кое-что, но так никогда и не получил шанса научиться думать на них.

Сейбел: Получив диплом телеведущего, чем вы занялись?

Крокфорд: Я поступал в магистратуру по технологиям образования. Но скоро понял, что знаю намного больше, чем мне преподают, и что все это пустая трата времени. Я бросил это дело где-то через год и пошел работать в Стэнфордский исследовательский институт в Менло-Парке. Потом я перешел в компанию Basic Four, которая производила миникомпьютеры для бизнеса, и проработал там довольно долго. Я разрабатывал текстовый процессор для компании и начал кое-какие исследования насчет переносных машин и персональных компьютеров. Я пытался обратить внимание компании на персональные компьютеры. Первым в компании купил персональный компьютер и оставил его на своем столе, чтобы инженеры приходили и смотрели на детище IBM.

Но мне так и не удалось изменить корпоративную культуру компании, поскольку они были слишком зациклены на том, что делают.

Однажды на Рождество, кажется в 1981 году, я купил Atari 800. В компьютерном магазине был еще Apple II, но Atari смотрелся шикарнее, и я выбрал его. Я думал написать на нем текстовый процессор или создать для него язык программирования. Но процессор 6502 был просто ни на что не способен. То есть я потратил две тысячи долларов на эту штуку, но что она может? Ну, хотя бы игры. Поэтому я начал создавать компьютерные игры, продал одну из них компании Atari и получил предложение поработать в их исследовательской лаборатории в Саннивейле. Это была лаборатория, организованная Аланом Кэем (Alan Kay), — первое, что он сделал со времен работы в Xerox PARC. Там было просто здорово. Я проработал там два года, наблюдая, как компания рассыпается. Но мне удалось сделать кое-что интересное и поработать с прекрасными людьми.

Сейбел: До этого вы увлекались компьютерными играми?

Крокфорд: Разве что потратил несколько четвертаков на Space Invaders и Рас-Man. Мне нравились игры, но их фанатиком я никогда не был. Компьютерные игры мне нравились как еще одно место взаимодействия компьютеров и телевидения. Первое такое место, открытое для широкой публики. По-моему, это было действительно интересно.

Сейбел: Что было после краха Atari?

Крокфорд: Я перешел в компанию Lucasfilm и работал там восемь лет.

Сейбел: И разработка игры Habitat началась, когда вы работали там.

Крокфорд: Конечно. Этот проект начал мой друг Чип Морнингстар. Он придумал аватары и виртуальный графический мир. Сначала он занимался всем этим. Работало все это на компьютере Commodore 64 и ненагруженных сетях Х.25. Проект был невероятно дальновидным, с огромным количеством правильных решений, просто потрясающе. Я наблюдал со стороны, подбадривал их, но в том, что они сделали, моей заслуги нет.

Сейбел: А потом вы вместе ушли и основали Electric Communities, которая построена на этих идеях?

Крокфорд: Да. Морнингстар и Рэнди Фармер ушли из Lucasf ilm и основали компанию American Information Exchange, в которой применили идею социальной сети к онлайновым рынкам. Блестящая идея, но увы, опередившая свое время. Сделав это несколько позже, они могли бы стать чем-то вроде eBay.

Потом у нас появилась идея: давайте попробуем снова и создадим общую платформу, которая бы занималась развлечениями, социальными вещами, бизнесом — да чем угодно, — создадим платформу для всего мира. У нас были кое-какие мысли насчет того, как сделать ее полностью распределенной, чтобы не было единственного сервера, а она была бы распределена по всему Интернету. И мы придумали модели обеспечения безопасности, которые позволили бы ей быть полностью децентрализованной. Эта действительно отличная идея и привела к созданию Electric Communities.

Сейбел: Именно там и была создана первая версия языка Е.

Крокфорд: Совершенно верно. Нам нужен был безопасный язык для разработки платформы и приложений под нее. Сначала мы пытались использовать язык Joule компании Agorics. Это был язык на основе модели акторов, и многое в нем делалось необычным способом; язык был блестящий, но слишком уж непривычный.

У нас были сомнения по поводу Joule. Мы собирались научить людей пользоваться этим языком. Но не слишком ли он экстравагантен? Тогда у нас появилась идея насчет языка E, который заимствовал основные концепции акторов языка Joule и был построен поверх языка Java.

Сейбел: Применялся ли язык E кем-нибудь, кроме его создателей?

Крокфорд: В своей первоначальной версии — нет. Старый E был диалектом Java. Из-за этого у нас возникали всякие проблемы с компанией Sun. Потом мы разработали язык сценариев E — более легкий, но с аналогичными возможностями. Именно этот язык сейчас известен как E.

Мы разработали этот язык в компании Electric Communities, но, кажется, так его и не использовали. В какой-то момент мы просто решили, что не будем его использовать. Несмотря на это язык оказался неплох, и мы продолжали его развивать. И я рад, что он все же выжил.

Один из плюсов работы в Electric Communities — там я научился думать в терминах замыканий. А начав заниматься Сетью, посмотрел на JavaScript и сказал: «Кажется, мне это знакомо». Ведь JavaScript многое унаследовал от Scheme, но из документации не понять, что в нем есть замыкания. Так что я открыл это случайно и сказал себе: «Ого, здорово!» И стал продвигать идею, что на этом дурацком маленьком языке можно делать серьезные вещи.

Сейбел: Это возвращает нас к недавним спорам по поводу ECMAScript 4. Как я понял, вам нравится простота версии ES3 JavaScript.

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

JavaScript стал самым популярным в мире языком программирования чисто случайно. Сейчас процессоров, на которых могут выполняться программы на JavaScript, гораздо больше, чем для любого другого языка программирования. И несмотря на все проблемы с безопасностью, JavaScript — единственный язык, который даст вашему коду запуститься на каком угодно компьютере.

Но это еще не все: он встроен во множество приложений. Большинство приложений компании Adobe поддерживает JavaScript, так что вы можете использовать его локально. Многие другие приложения также поддерживают эту возможность. То есть он становится невероятно популярным.

Проблема с этим языком в том, что он ворвался на рынок слишком быстро и так же слишком быстро был стандартизирован. Так что большинство его недостатков связаны не с текущей реализацией, а находятся в спецификации. Стандарт указывает делать это неправильно. А это просто ужасно. Но ситуация именно такова. В 1999 году развитие этого языка замерло, все должны были его забыть, и он должен был умереть. Но вместо этого совершенно случайно возник Ajax, и теперь JavaScript — самый важный язык программирования в мире.

И теперь мы думаем, что должны его как-то исправлять. Это нужно было сделать еще в 2000-м, но тогда этого никто не сделал, поскольку на него тогда никто не обращал внимания. Теперь же это сделать очень сложно.

Есть еще одна особенность JavaScript в контексте Сети. Обычно, разрабатывая серверное, прикладное или встроенное (embedded) приложение, выбираешь не только язык, но и компилятор, и среду выполнения. Однако в случае JavaScript нет такого выбора: нужно, чтобы код работал на чем угодно.

Поскольку код должен выполняться на чем угодно, ошибки не исправляются. Если разработчик браузера выпустит его с ошибкой, то скажет: «Ой, мы лажанулись», — и на следующий месяц выпустит следующую версию с другой ошибкой, а мы не можем подстраиваться под все обновления, которые устанавливают их пользователи. Большинство пользователей, установив однажды Internet Explorer, никогда его не обновляют. Ошибки в этом браузере остаются с ними годами.

Сейбел: То есть ситуация сейчас именно такова. Но вы хотите сделать Сеть более совершенной платформой для разработки приложений. Если мы не можем исправить свои ошибки, пока разработчики браузеров не исправят собственные, если даже и это не помогает, значит, мы в тупике. Где же выход?

Крокфорд: Как раз этим я и занимаюсь. Я вижу идеальное решение. Я знаю, каким оно должно быть. Знаю, где мы находимся, и вижу все преграды на нашем пути. И пытаюсь придумать, каким образом нам выйти из этого положения. Мы оказались в ловушке, в том смысле что разработали громоздкие системы — экономические, социальные, технические, которые в значительной степени зависят от этих непродуманных решений.

Несомненно, худшей особенностью JavaScript является зависимость от глобального объекта. В JavaScript нет компоновщиков и информация между элементами компиляции никак не скрывается. Все объединяется в общий глобальный объект. Так что каждый компонент видит все остальное; все компоненты имеют равноправный доступ к DOM; все они имеют одинаковый доступ к сети. Если какой-нибудь скрипт проберется на вашу страницу, он сможет зайти на сервер, представив себя в качестве вашего скрипта, и сервер никак не сможет отличить его от вашего.

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

Ситуация ухудшается еще и тем, что есть и другие пути попадания скрипта на вашу страницу. Архитектура Сети включает несколько языков: HTTP, HTML, язык URL-адресов, CSS и язык сценариев. Все они существуют и могут встраиваться друг в друга, обладая разными правилами цитирования (quoting), экранирования (escaping) и комментирования. Не во всех браузерах все эти правила реализованы одинаково. А некоторые из этих правил могут быть вообще не определены. Из-за этого злоумышленник легко может встроить какой-либо скрипт в URL, вставить его в кусок CSS, который затем вставить в HTML, а тот — в другой скрипт и так далее.

Сейбел: Классические межсайтовые скриптовые атаки, связанные с ошибками в браузере.

Крокфорд: Именно. Это ужасно. Нам нужно что-то с этим делать, потому что оставлять все это так совершенно не хочется.

В конце концов мы открыли мэшапы. Это как раз то, чего мы пытались добиться в области программного обеспечения в течение двадцати лет: компоненты многократного использования, которые можно объединять друг с другом, как детали в конструкторе LEGO, очень быстро создавая новые приложения. Мэшапы действуют аналогичным образом, и получается великолепно: берешь что-то из Yahoo!, что-то из Google, что-то свое, что-то чье-нибудь еще и делаешь из всего этого приложение. Класс! И все это делается в браузере, прямо у тебя перед глазами. Проблема одна: каждый из этих компонентов имеет доступ к тому же, что и другие. Мы сознательно создаем условия для XSS-атак. Модель безопасности браузеров не ожидает от этого ничего хорошего и не предоставляет никаких механизмов взаимодействия при взаимном недоверии. Вся всемирная Сеть построена на сплошных ошибках. Результат — множество неприятностей.

Сейбел: Можно ли из всего этого сделать вывод, что все усилия по принятию стандарта ES4 относятся к альтернативным издержкам и все думают именно об этом, а не о том, как избавиться от имеющихся проблем?

Крокфорд: Именно так. Этот стандарт решает не ту проблему. Он решает проблему, связанную с тем, что люди ненавидят JavaScript. И я могу понять позицию Брендана Айка, поскольку он проделал потрясающую работу, но он торопился, допускал ошибки в руководстве, и в итоге вышла полная ерунда. Его ругали и поносили последние двенадцать лет за его глупость и за то, что он создал глупый язык, но все это не так. Там есть блестящие идеи, и сам Брендан — блестящий парень. Он сейчас пытается оправдаться и доказать, что действительно умен, и показать это всем с помощью языка, который будет содержать все классные возможности, которые он когда-либо видел, объединенные и работающие все вместе.

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

Думаю, нужно двигаться шаг за шагом. Если у нас появится модульность или возможность выбирать язык программирования, это уже будет шаг вперед. Это еще не все, что нам нужно, но гораздо больше того, что есть у нас сейчас. Потом есть такие вещи, как Caja и ADsafe, пытающиеся сделать то же самое с помощью сегодняшних технологий. Мы не можем ждать.

ADsafe создает безопасное подмножество языка JavaScript, блокируя доступ ко всему глобальному и опасному. Но даже это подмножество все еще представляет собой полезный язык. У нас все еще остаются лямбда-выражения, а они могут многое. Таким образом, это нестандартный язык. Он не позволяет использовать прототипы так, как мы уже привыкли. Но этот язык остается невероятно мощным, поскольку в нем присутствуют лямбда-выражения.

Сейбел: Возвращаясь к ES4: есть ли в нем хоть что-то, что вам нравится с точки зрения языка?

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

А он будет стандартизирован и внедрен до того, как мы поймем, что он действительно работает. Думаю, мы слишком торопимся. Я бы чувствовал себя спокойнее, если бы существовали примеры его реализации и полезные приложения, написанные на нем. Вот тогда я бы сказал: «Хорошо, давайте стандартизировать язык, давайте внедрять его по всему миру». А мы все делаем в обратном порядке.

Сейбел: Google Web Toolkit (GWT) позволяет компилировать Java в JavaScript. Многие уже пробовали компилировать другие языки в JavaScript. Это правильный путь?

Крокфорд: Любопытно наблюдать, как JavaScript становится универсальной средой выполнения. Мы никогда не ожидали увидеть его в такой роли.

Сейбел: Но, как вы уже говорили, он везде. Он стал универсальной средой выполнения.

Крокфорд: Что тем более заставляет нас обратить внимание на производительность. Особенно при переходе на мобильные платформы, к которым закон Мура неприменим. Здесь уже имеет большое значение то, сколько времени мы тратим на интерпретацию. Все это дополнительные такты процессора. Так что, думаю, это должно дополнительно улучшить качество среды выполнения.

Я придирчиво наблюдаю за тем, чего достигли GWT и другие средства преобразования. С этими средствами очень трудно работать — если найдете что-нибудь работающее, вам повезло. Лично я опасаюсь использовать их, поскольку боюсь дыр в абстракциях. Если возникнут проблемы с вашим Java-кодом, или с GWT, или со сгенерированным кодом, то у вас может быть, а может и не быть возможности справиться с этим. Особенно в том случае, если предпочтете ничего не знать о JavaScript, поскольку этот язык скрыт от вас. Тогда, если что-то пошло не так, вы столкнетесь с огромными проблемами. Я пока не слышал о подобных случаях, и это значит, что те, кто этим занимается, делают всё правильно. Но такой риск определенно есть.

Сейбел: Каким бы вы хотели видеть JavaScript?

Крокфорд: Думаю, лучший способ усовершенствовать JavaScript — сделать его более компактным. Если бы можно было оставить только те возможности, которые работают действительно хорошо, убрав малозначительные или ненужные, то мы бы действительно получили заметно улучшенный язык. И я думаю, что этот же подход применим и к HTML, и к HTTP, и к CSS. Мне кажется, что работая со всеми этими стандартами, нужно выяснить, что они делают правильно, а чего в них не хватает, и на этом основании переориентировать их, а не просто добавлять новые функции поверх существующих.

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

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

На самом деле проблема в том, что Ajax-библиотек стало слишком много. Это следствие того, что JavaScript — очень мощный язык, потребность в подобных библиотеках очень высока, а создавать их относительно легко. Поэтому в течение какого-то времени все их и писали. Я жду, что их станет меньше, но пока напрасно. Из-за этого у нас сейчас другая проблема — библиотек столько, что разработчики не знают, какую выбрать. Думаю, все же в будущем их количество уменьшится.

Сейчас заметна тенденция сближения функциональности Ajax-библиотек. В j Query можно получить список объектов из DOM с помощью CSS-ceлекторов и затем управлять группой объектов. Это оказалось действительно хорошей идеей — вот пример того, как JavaScript кое-что делает эффективно. Да, интерфейс взаимодействия с DOM просто ужасен, но он скрыт полностью. Разработчики jQuery очень упростили программную модель и сделали это блестяще.

А теперь каждая библиотека делает то же самое — мы наблюдаем сближение функциональных возможностей. Для пользователей проблема встает еще острее, так как все труднее выбрать нужную библиотеку, поскольку все они становятся очень похожими. Но в конце концов они начнут объединяться, и в результате останется всего несколько библиотек, возможно всего одна. Думаю, одним из победителей будет Microsoft с ее библиотекой Atlas, просто потому что Microsoft всегда оказывается среди победителей. Но, по-моему, у них нет достаточной поддержки. Открытые фреймворки, похоже, намного эффективнее. Думаю, в конце концов победит один или два открытых фреймворка.

Сейбел: Сегодня вы архитектор и евангелист языка JavaScript в Yahoo!, поэтому часть вашей работы, по-видимому, в том, чтобы говорить JavaScript-программистам в Yahoo!: «Делайте так-то». Обязаны ли вы также анализировать код и проекты на соответствие общепринятым практикам кодирования и проектирования?

Крокфорд: Я всегда настаиваю на необходимости чтения кода. Думаю, чтение кода — самое полезное, что программисты могут сделать друг для друга: постоянно уделять часть своего времени чтению кода коллег. При управлении проектами программистов часто предоставляют самим себе, затем всю их работу объединяют, и если результат удается скомпилировать, то полученный продукт выпускают на рынок и забывают о нем.

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

Сейбел: Давайте поговорим о том, как читают код у вас.

Крокфорд: На каждом совещании есть ответственные за чтение кода: они разбирают и проверяют код под наблюдением остальных. Это отличная возможность для каждого понять, как его фрагменты кода будут согласовываться с фрагментами других.

Мы садимся за стол, перед каждым лежит стопка бумаг. Мы выводим код на экран и комментируем его по ходу чтения. Кто-то говорит: «Я не понимаю этот комментарий» или «По-моему, этот комментарий не описывает этот код». Это очень важно, поскольку как программист вы перестаете читать свои комментарии, не сознавая, что другому что-то может быть непонятно. Прекрасно, когда коллеги по проекту помогают поддерживать ваш код в чистоте — вы находите ошибки, которые никогда бы не нашли самостоятельно.

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

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

В частности, это облегчает контроль выполнения проекта, поскольку мы видим прогресс каждого участника, что позволяет довольно рано заметить, если мы вдруг начнем сбиваться с намеченного пути.

Я управлял проектами, в которых незадолго до срока сдачи люди говорили: «Все практически готово», — а затем я смотрел их код, но там еще ничего не было или была полная ерунда, или он был очень далек от завершения. Жуткое испытание для руководителя проекта, и я думаю, что чтение кода как раз помогает избежать подобных ловушек.

Сейбел: Допустим, мы читаем мой код. Выводим код на экран — и что дальше? Я буквально читаю код вслух?

Крокфорд: Да, строку за строкой, параллельно его комментируя. Именно так все и должно происходить. Когда есть время, мы читаем код построчно.

Сейбел: Вам приходилось обучать людей чтению кода? Думаю, непросто найти хороший компромисс — сделать достаточно критических замечаний и при этом не задеть самолюбие автора кода.

Крокфорд: Да, здесь требуется взаимное доверие между членами команды, и нужны четкие правила насчет того, что допустимо, а что нет. В неслаженной команде чтение кода приведет к тому, что участники просто разорвут друг друга на части. То есть в процессе чтения кода очень быстро выясняется, слаженная команда или нет. При чтении кода вы можете многое узнать и многому научиться. Поначалу процесс может казаться неестественным, но стоит войти в ритм, как это ощущение пройдет.

Другой момент: нужно писать код так, чтобы другие смогли его прочитать. Здесь важны ясность кода и стиль его написания. Благодаря этому будет постепенно улучшаться качество кода и компетентность команды в целом.

Сейбел: Что для вас делает код читаемым?

Крокфорд: Читаемость складывается из нескольких уровней. Самое простое: нужно быть последовательным в оформлении кода, всегда использовать одинаковые отступы, расставлять пробелы во всех нужных местах. У меня есть дурная привычка, приобретенная еще во времена программирования на Фортране: я использую слишком много однобук-венных переменных, а это нехорошо. Я очень стараюсь избавиться от этой привычки, но это трудно сделать.

Сейбел: Насколько это трудно? Вы пишете код, а затем перечитываете его и думаете: «Боже! Только посмотрите на все эти однобуквенные переменные!»?

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

Сейбел: Для этого есть специальные инструменты?

Крокфорд: Да, можно применить gzip — и готово, так что у меня нет оправдания. Если, просматривая свой старый код, я вижу слишком короткие имена, то при наличии времени я их исправляю. Некоторые переменные, вроде счетчиков цикла, я всегда называю i. He думаю, что когда-то стану исправлять и это. Для многих переменных длинные имена просто неоправданны.

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

Сейбел: На какие конкретно вещи должен обращать внимание разработчик, чтобы его код легко читался?

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

Вспоминается Фортран, но это справедливо для всех языков. Иногда авторы языка допускают ошибки. С моей точки зрения, в языке Си полно ошибок.

Сейбел: Каких, например?

Крокфорд: Например, оператор switch изначально является неудачным, не нужно было делать его таким. У оператора ++ огромные проблемы в смысле безопасности, поскольку он провоцирует вас на разные хитрости и попытки сделать слишком многое в одной строке кода. В результате код становится трудным для понимания, что часто приводит к различным ошибкам, таким как переполнение буфера. Так что большинство проблем безопасности, которые мы наблюдаем в операционных системах последние пять лет, связаны с использованием оператора ++.

Обычно я вообще не использую оператор ++. Бывает, его можно использовать, но чаще нет, и мне трудно различить эти случаи в своем коде.

Сейбел: Но ведь можно возразить, что проблемы безопасности, связанные с оператором ++, возникают не из-за самого оператора ++, а из-за отсутствия проверки выхода за границу массива или из-за проблем с обычными указателями. В Java нет подобных проблем с безопасностью, поскольку если есть оператор ++ и происходит выход за границу массива, то получается исключение.

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

Другой пример — оператор continue. Я еще не встретил ни одного фрагмента кода, который не смог бы улучшить, выкинув оператор continue. Да, с его помощью легче создать какую-то сложную конструкцию. Но я заметил, что всегда могу улучшить эту конструкцию, найдя способ выкинуть его. Так что лично я никогда не использую оператор continue. Если же я вижу continue в своем коде, значит, что-то недодумал.

Сейбел: Как вы читаете чужой код?

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

Сейбел: Вам встречался код, который поначалу выглядел сумбурно, но после чистки вы понимали, что на самом деле он хорош?

Крокфорд: Нет, такого никогда не случалось. Мне кажется, очень сложно небрежно написать хороший код (под хорошим кодом я понимаю читаемый). На этом уровне совершенно неважно, что означает этот код для машины, если я не могу понять, что он должен делать; он может оказаться удивительно эффективным, или компактным, или потрясающим еще в каком-то смысле, но это уже неважно.

Сегодня читаемость кода — мой главный приоритет. Она важнее эффективности и почти так же важна, как корректность, и я думаю, что читаемость кода — важнейший шаг к его корректности. А если код тяжело читать, то, по-видимому, разработчики выбрали неверные компромиссы, и нельзя этот код назвать хорошим.

Сейбел: А как насчет глубоко вложенного цикла, который должен выполняться невероятно быстро? Должен ли весь код быть читаемым — или иногда читаемость можно принести в жертву эффективности?

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

Сейбел: В языках программирования с фигурными скобками программисты ведут бесконечные холивары («священные войны») по поводу того, где расставлять эти скобки, доказывают, что тот или иной стиль делает код более читаемым. Занимаясь чисткой кода, вы приводите его в форму, облегчающую восприятие?

Крокфорд: Непременно — ведь я считаю, что использую единственно правильный способ форматирования! Полагаю, Томпсон и Ричи оказали всем плохую услугу, не определив стандарты оформления кода для языка Си. Они сказали: «Мы используем такое оформление, а вы можете оформлять код как-то иначе», — и тем самым сильно навредили человечеству: теперь, возможно, люди всегда будут использовать только их версию.

Сейбел: То есть вы предпочитаете стиль отступов K&R?

Крокфорд: Да, думаю, Керниган и Ричи сделали все правильно и их исходный стиль правилен. В особенности это касается JavaScript. JavaScript вставляет точки с запятыми, и во многих местах смысл программы резко меняется в зависимости от того, слева или справа вы поставите скобки. Стиль K&R не страдает этим недостатком, в отличие от стиля без отступов.

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

Это примерно то же, что спорить о достоинствах левостороннего и правостороннего движения. Разумных доводов в пользу того или другого нет. Если вы живете на необитаемом острове, то можете ездить как угодно, но общество определенно выиграет, если все будут ездить по одной стороне.

Сейбел: Если вам предложат новую работу, где надо программировать на Си или Java не в том стиле, какой вы предпочитаете, как вы поступите? Скажете: «Хорошо, я перейду на ваш стиль. Уверен, что вскоре буду этому рад»? Или откажетесь от такого предложения?

Крокфорд: Может быть, стоит всегда замечать, какой стиль принят в том или ином месте? Правостороннее или левостороннее там движение? И не соглашаться на работу там, где ездят не по той стороне дороги. Как в сказке Доктора Сьюза, настроение зависит от того, есть ли у тебя на животе звезда. В конце концов приходится перейти на принятый в компании стиль, в надежде, что люди, принявшие этот стиль, знали, что делают. Но если и не знали, неважно. Важнее, чтобы все шагали в ногу.

Сейбел: Итак, чистку кода вы начинаете с оформления. Насколько глубоко или существенно вы перерабатываете код?

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

Сейбел: Значит, вы против предварительного объявления ?

Крокфорд: Да, против. Или, по крайней мере, предварительное объявление должно быть явным. Я против того, чтобы код располагался в произвольном порядке, кроме случаев литературного программирования (literate programming), когда я изменяю порядок кода для его наглядности, отказываясь от привязки к требованиям языка, — и мне это очень нравится. Но без специальных инструментов лучше это не делать.

Сейбел: В одном из интервью вы цитировали Исход, 23:10-11: «Шесть лет засевай землю твою и собирай произведения ее, а в седьмой оставляй ее в покое», — утверждая, что каждый седьмой цикл следует посвятить чистке кода. Какой разумный временной промежуток вы имели в виду?

Крокфорд: Шесть циклов — это циклы между выпусками чего-либо. Если вы выпускаете новую версию ежемесячно, то каждые полгода следует пропускать один цикл выпуска, посвятив это время чистке кода.

Сейбел: То есть, не делая это через каждые шесть циклов выпуска, можно столкнуться с необходимостью серьезного переписывания кода. А как вы определяете, что настало время для серьезного переписывания, — если с вами такое бывало?

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

Руководителю очень сложно это увидеть, особенно если он не программист. Но даже для руководителя-программиста это очень непростая задача, поскольку к этому времени сделано слишком много вложений. Начать заново — значит вернуться назад и проделать тот же путь. Но это невозможно, поскольку мы не будем двигаться вперед. Поэтому они говорят: «Нет, будем двигаться вперед с тем что есть».

Ошибочно считать, что во второй раз будет затрачено столько же времени, сколько и в первый раз, хотя есть и противоположные примеры. Это так называемая проблема второй системы: когда те, кто уже чего-то достиг, получают задание начать все с чистого листа и делать то, что считают нужным. Обычно это ведет к провалу, поскольку люди становятся слишком амбициозными в своих целях и не видят границ. В результате вы не получаете ничего. Нужна невероятная дисциплина, чтобы можно было сказать: «Нет, мы не начинаем с чистого листа, а заново реализуем то, что уже сделали ранее; давайте делать то, что мы уже знаем».

Одна из главных трудностей программирования в том, что мы обычно занимаемся тем, чем никогда прежде не занимались. Если мы имеем дело с чем-то, что уже делали, то используем это повторно. Но в основном мы делаем то, чего никогда раньше не делали. А создавать что-то, чего никогда не делал, сложно. Заниматься этим очень интересно, но весьма непросто. Особенно когда работаешь по классической методике и должен классифицировать систему, которую до конца не понимаешь. В этом случае очень высока вероятность сделать неправильную классификацию.

Сейбел: Под «классической» методикой вы подразумеваете применение классов?

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

Сейбел: Но ведь вы считаете рефакторинг кода полезным, раз советуете посвящать ему каждый седьмой цикл? И тогда необходимость в серьезном переписывании отпадает.

Крокфорд: Да, я считаю его полезным. Можно подумать о том, чтобы выкинуть все и начать сначала, только в том случае, когда это писал не ты или сделал это плохо, что-то пошло не так, и в результате получилась база кода, с которой невозможно работать. Всегда можно прикинуть, что быстрее — переписать все заново или вносить исправления.

Сейбел: А как быть с проблемой, когда не полностью понимаешь назначение того кода, который собираешься переписывать? Ведь каждый фрагмент кода несет в себе кусочки знаний — маленькие, неприметные кусочки, которые на самом деле являются частицами дорого доставшейся функциональности, о которой не думаешь, решая все переписать.

Крокфорд: Да, это серьезная проблема. Одна из причин, почему в Сети творится такая неразбериха, — отсутствие спецификаций. Спецификации были неполными, при этом еще и трактовались зачастую неверно, и многие из-за неверного понимания стали частью общепринятых правил. Все эти системы значительно сложнее, чем могли бы быть, именно благодаря историческим причинам. Работая на этом уровне, я, конечно, тепло отношусь к этим недокументированным знаниям, которые содержит исходный код.

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

Подобные ошибки в спецификации — действительно очень и очень серьезная проблема. У нас есть такие проблемы в мире Ajax. Основные трудности, связанные с Ajax, заключаются главным образом в отличиях на уровне браузеров. Разработка кроссбраузерных приложений значительно сложнее, чем могла бы быть, именно из-за отсутствия полноценной спецификации Сети, а также из-за существенных различий в реализациях.

В последние пять лет ситуация значительно улучшилась, особенно с появлением Ajax-библиотек. Большинство из них делают очень полезные вещи, хотя и не все, что нужно, но достаточно для повышения вашего уровня как программиста. Теперь не нужно копаться во внутренностях браузера, для этого у нас есть нечто вроде виртуального слоя, на основе которого можно разрабатывать весьма гибкие и переносимые приложения. Здесь, в Yahoo!, у нас есть команда, основная задача которой — работа с проблемами, связанными с браузерами. Хорошая работа этой команды значительно облегчает жизнь другим нашим разработчикам.

Сейбел: С другой стороны, переписывание системы не всегда срабатывает. Ранее вы упомянули эффект второй системы, а в другом интервью назвали это явление в действии «душераздирающим зрелищем». Когда это случилось?

Крокфорд: Это было в Electric Communities. Мы собрали там команду умнейших программистов, которую я когда-либо видел. У нас был достаточный бюджет, мы собирались заново реализовать кусок, который уже написали Чип и Рэнди, так что мы точно знали, что нам делать. Разница была только в масштабе.

Сейбел: Речь шла о переделке Habitat?

Крокфорд: Да, мы собирались переписать Habitat, только на этот раз с учетом его глобального распределения. Это оказалось крайне нелегко. Хотя нам и удалось его создать, это было мучение. Не хотел бы я вновь пережить нечто подобное.

Сейбел: Как вы думаете, тот совет, который вы дали чуть раньше, — быть достаточно дисциплинированными, чтобы реализовать заново только то, что действительно понимаешь, — мог уберечь от беды?

Крокфорд: Думаю, это помогло бы. Мы не продумали как следует процесс с учетом всех его этапов. У нас не было инкрементального подхода. Если бы он был, я бы направил усилия на две параллельные задачи. Во-первых, разработал безопасную распределенную платформу, которая бы не делала ничего, кроме обмена сообщениями и управления объектами. Во-вторых, переписал бы Habitat с учетом всех наших знаний о современных языках программирования. Просто переписал бы и все.

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

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

Сейбел: Думаете, вы решили делать все одним этапом именно потому, что уже знали крупные куски будущей программы?

Крокфорд: Потому что мы были очень умны и опытны. Мы решили, что промашка просто невозможна. Программисты по своей природе оптимисты. И мы были оптимистами, иначе эту работу было бы не сделать. Вот почему мы пали жертвой эффекта второй системы, не сумев спланировать свои проекты, вот почему все оказалось для нас таким трудным.

Сейбел: Легче ли программировать со временем? Станет ли в будущем больше способных к тому, что мы сейчас называем программированием?

Крокфорд: Для меня программирование интересно тем, что я помогаю другим заниматься программированием. Я проектирую язык или инструмент так, чтобы он был доступен множеству людей. Именно из этих соображений была начата работа над языком Smalltalk. Smalltalk пошел другим путем, но первоначальная идея была для меня крайне привлекательна. Как создать язык программирования, предназначенный специально для детей, или как создать язык специально для тех, кто не считает себя программистами?

Сейбел: Видимо, вы полагаете, что научиться программировать должен каждый, хотя бы чуть-чуть?

Крокфорд: По-моему, иного выхода нет. Сегодня компьютеры захватили мир, и для того чтобы защитить себя или чтобы быть полноценным гражданином, вы должны хотя бы немного понимать, как все это работает.

Сейбел: Кое-кто считает, что программирование развивает особый тип мышления — в том смысле, что чтение и решение математических задач — это два разных способа мышления, и оба важны.

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

Сейбел: Вы все еще получаете такое же удовольствие от программирования, как раньше?

Крокфорд: А как же!

Сейбел: Как по-вашему, становится ли программирование уделом молодых?

Крокфорд: Раньше я так и думал. Несколько лет назад у меня произошла остановка дыхания во сне, но я об этом не знал. Я думал, что просто становлюсь старым и усталым, что дошел до той точки, когда сконцентрироваться невозможно. И я решил, что не смогу больше программировать, потому что просто не могу удерживать все нужное в голове. В процессе программирования часто приходится держать в голове множество вещей, пока не сможешь записать их, оформив в виде каких-то конструкций. А как раз этого я больше не мог.

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

Сейбел: Вы как-то назвали великолепной идеей литературное программирование в стиле Дональда Кнута. Вы применяете инструменты для литературного программирования?

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

Сейбел: Дело в проблеме взаимодействия инструментов между собой? Если ее решить, как думаете, вы бы писали литературные программы?

Крокфорд: Да. Думаю, что было бы значительно легче сопровождать JSLint, например с помощью литературного программирования. В литературном программировании мне нравится то, что проектируешь программу специально для чтения. Мне кажется, это придает ей невероятную ценность.

Сейбел: Каковы, по-вашему, основные возможности инструментов для литературного программирования?

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

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

Благодаря Кнуту можно взять по отдельности все аспекты этой функции, которые могут быть тесно связаны между собой, но при этом объем слишком велик. Литературное программирование позволяет снабдить каждый элемент чего-то большого четкой описательной меткой и сказать: «Эта функция включает:» — и привести список этих меток. Почти то же самое можно сделать с помощью функций, но в этом случае придется вникать во взаимодействие ее элементов и так далее. При этом вводятся новые структуры, которые, собственно говоря, не решают никаких задач.

В идеале я хотел бы увидеть языки программирования, спроектированные специально для литературного программирования. Кнут удачно применил свою идею к Паскалю и Си, но мне хочется видеть новые языки, целиком и полностью разработанные именно для таких задач.

Сейбел: Вы читали программы Кнута, написанные в этом стиле?

Крокфорд: Конечно.

Сейбел: Как вы их читали? Как роман?

Крокфорд: Да, как роман. Я больше читал его книг, чем его программ, но мне действительно нравится, как он располагает код; пишет он действительно здорово, иногда даже вставляет небольшие шутки. Читать его программы действительно приятно.

Сейбел: Что именно вы выносите из них для себя? Вот вы прочли его книгу про ТеХ. Готовы ли вы добавлять новые возможности в ТеХ, или просто восхищаетесь тем, какой Кнут классный парень?

Крокфорд: Отличный вопрос. Я ознакомился с книгой про ТеХ, но читал ее без намерений что-то в нем изменять. Я читал просто с целью посмотреть, что же он такое сделал. Больше всего меня интересовало, как он реализовал разбиение строк, и эту часть я прочел с особым вниманием: я хотел прежде всего разобраться в алгоритме, а не понять, как работает код, чтобы его потом изменять или повторно использовать. Конечно, если бы я намеревался влезть в саму программу, я бы читал книгу по-другому.

Сейбел: Часто ли вы читаете код, написанный в литературном стиле или в каком-то еще, просто для удовольствия?

Крокфорд: Да. Но на самом деле не так-то просто найти код, который можно читать просто для удовольствия. Кнут написал кое-что. Фрейзер и Хэнсон создали компилятор Си в стиле литературного программирования — он очень классный. Но примеров не так много. Очень жаль. Это может говорить о том, что литературное программирование, возможно, потерпело неудачу.

Сейбел: А как насчет главного труда Кнута, «Искусства программирования»? Вы из тех, кто прочел его от корки до корки, или используете его как справочник, или просто поставили на полку и никогда в нее не заглядываете?

Крокфорд: Все что угодно, кроме последнего. Когда я учился в колледже, то пару месяцев не платил за квартиру, чтобы купить его книги. Я читал их и находил там шутки, например в содержании первого тома, но понимал далеко не все. В некоторых местах Кнут гораздо выше моего разумения, но книги мне очень понравились, кроме того, я часто использовал их в качестве справочников.

Сейбел: Вы и вправду читали их от корки до корки, пропуская особо трудные математические пассажи?

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

Сейбел: Мне кажется, что для чтения книг Кнута нужно уметь читать и понимать математические выражения. Как вы думаете, в какой степени, математическая подготовка необходима программисту?

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

Мне бы хотелось, чтобы все это было совершенно необходимо программистам, но это не так. Может быть, именно поэтому веб-программирование получило столь бурное развитие и стало доступно многим, именно поэтому JavaScript так популярен. Все это не так сложно. А большинство сложностей — лишние. Если мы чуть-чуть почистим платформу, эта работа станет значительно легче.

Сейбел: Итак, Кнут дал вам эти унылые формулы, а потом — раз! — и появилась цельная картина. Даже если почистить платформу, создание и проектирование больших и понятных систем останется нелегким делом. Как вы проектируете свой код?

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

Вот за что я люблю JavaScript, так это за возможность рефакторинга кода. Я понял, что делать это очень и очень просто. В то время как ре-факторинг посредством глубокой иерархии классов может стать настоящим мучением.

Например, JSLint немало изменился с тех пор, как я начал разрабатывать его в 2000-2001 гг. Да и задачи его существенно изменились: теперь на нем можно делать то, чего я и не представлял, — и во многом благодаря гибкости JavaScript. Я могу вертеть его как хочу, программа может разрастаться, но при этом не становится громоздкой.

Сейбел: Так что же делает его использование настолько простым?

Крокфорд: Я стал горячим поклонником «мягких» объектов. В JavaScript любой объект является тем, чем вы укажете ему быть. Это настораживает людей, которые смотрят на это с традиционной точки зрения, поскольку что вы получите без класса? Оказывается, вы получите именно то, что хотите, и это действительно полезно. Приспосабливайте свои объекты — и они получаются куда более наглядными.

Сейбел: Возможно, проблема языков, основанных на классах, заключается в слишком строгой типизации. Вы получаете большую иерархию классов, и если понадобится внести в эту иерархию изменения, то придется разъединить ее, а потом соединить обратно. В JavaScript другая опасность — язык может быть слишком динамическим. Вы допускаете маленькие ляпы по всей программе, и ее текущая структура начинает зависеть от множества вещей, происходящих во время выполнения. Нет ничего статического, на что можно взглянуть и сказать: «Ага, эта программа структурирована так-то».

Крокфорд: Да, есть от чего встревожиться, но это и хорошо; тревога — это реальность. Это дисциплинирует. В большинстве традиционных языков дисциплину вам навязывает язык. Работая с JavaScript, вы должны дисциплинировать себя сами.

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

Сейбел: Итак, «мягкость» объектов в JavaScript может быть опасной. Но если вы никогда не пользовались возможностью расширения объектов, то с тем же успехом могли бы создавать классы в Java. Как вы полагаете, можно ли структурировать программы на JavaScript, так чтобы извлечь максимальную пользу из гибкости языка?

Крокфорд: Мне потребовались годы проб и ошибок. До работы с JavaScript я ничего не читал об этом языке, просто начал работать и все. Я нашел пример программы, довольно жуткий, и всячески вертел его, пока все не заработало примерно так, как мне было нужно. В общем, я начал программировать на языке, не имея представления о том, что это за язык, как он работает и как на нем думать.

Я понимаю, почему люди в нем разочаровываются. Если вы попытаетесь писать программу на JavaScript так же, как на Java, язык станет кусаться. Я прошел через это. Первое, что я сделал, — это попробовал найти способ имитировать что-то вроде классов Java, но не смог. Я так ничего и не добился.

В конце концов я выяснил, что классы мне вообще не нужны, — язык сделает все за меня. Вместо того чтобы бороться с языком, я почувствовал, как сам язык придает мне силы.

Сейбел: При проектировании программ вы предпочитаете идти снизу вверх, сверху вниз или от середины?

Крокфорд: Все сразу. Это способ держать систему целиком в голове. В конце концов, вы должны разделять и властвовать, приведя ее к такому виду, чтобы с ней можно было справиться. Я берусь сразу за все стороны проблемы и пользуюсь одновременно всеми подходами. Я борюсь с системой до тех пор, пока не прояснится ее структура. А остальное придет само.

Сейбел: Как у вас связано проектирование и кодирование? Вы сразу же начинаете писать код и потом постепенно его улучшаете или делаете что-то помимо собственно кодирования?

Крокфорд: Обычно это два независимых процесса. Сейчас, правда, они становятся более похожими друг на друга. Я пользуюсь языком проектирования, или метаязыком, чем-то полуанглийским, слабо структурированным, более описательным, чем язык, предназначенный для кодирования. Но если программа должна быть на JavaScript, то я пишу сразу на JavaScript.

Сейбел: Какими инструментами вы пользуетесь для написания кода?

Крокфорд: Я работаю в небольшом бесплатном текстовом редакторе. Никаких хитрых функций у него нет, да мне ничего и не надо. Здесь не нужно множество формальных инструментов, как для других языков. Браузеру нужен только файл с исходным кодом, который вы ему посылаете, компилятор встроен в браузер, так что делать-то почти ничего и не надо. Не нужно ничего особенного; весь код запускается в браузере.

Сейбел: И, разумеется, вы используете JSLint.

Крокфорд: Да, причем постоянно. Я стараюсь использовать его каждый раз перед запуском программы, то есть если я что-то изменил, то перед запуском прогоняю код через JSLint.

Сейбел: Значит, вы редактируете код в текстовом редакторе, потом прогоняете его через JSLint и наконец запускаете в браузере. А как насчет отладки?

Крокфорд: Зависит от браузера. Если это Firefox, использую Firebug, если IE — отладчик Visual Studio. Оба эти инструмента очень хороши. У нас в браузерах есть на удивление хорошие отладчики.

Я использовал фреймворки, в которые были встроены специальные модули на основе DOM-элементов, позволяющие анализировать содержимое объектов. Но потом понял, что это не нужно и отладчика вполне достаточно.

Сейбел: Вы когда-либо выполняете свой код пошагово просто так, не пытаясь выловить конкретную ошибку?

Крокфорд: Только если имею дело с чем-то очень сложным. Я выполняю код пошагово в процессе тестирования, но в основном делаю это, когда есть конкретная проблема.

Сейбел: Что вы можете сказать о других методах отладки, таких как операторы утверждений или формальные доказательства корректности? Вы применяли их? Что вы думаете о понятии инварианта?

Крокфорд: Мне нравятся эти методики. Я был разочарован тем, что Eiffel не стал победителем среди объектно-ориентированных языков программирования, уступив первое место C++. По-моему, Eiffel был куда интереснее, мне нравилась его система контрактов на основе предусловий/постусловий. Я хотел бы видеть ее встроенной во все языки, с которыми я работаю. К сожалению, это еще одна из тех идей, которая так и не прижилась.

Сейбел: Какова худшая ошибка из тех, что вам пришлось отлавливать?

Крокфорд: Ошибка в реальном времени, например в видеоигре. Постоянные прерывания, натыканные повсюду, полное отсутствие управления памятью — и программа просто внезапно падает, непонятно почему. Справиться с подобными ошибками очень трудно, и на отладчик рассчитывать не приходится.

На Basic Four мы разработали полностраничный терминал для обработки текста, основанный на процессоре Z80 с 64 Кбайт памяти, чего было недостаточно для экрана такого размера. У нас также было подключение к локальной сети, по которой мы посылали страницы на свой сервер.

И у нас возникла проблема — экран то и дело гас. Архитектура была такая: в памяти хранилась строка текста со специальным символом конца строки, за которым следовал адрес следующей строки. Эти ссылки обрабатывались небольшим DMA-процессором. В какой-то момент ссылка пропадала — видимо, возникало что-то вроде гонок.

С нашей точки зрения, если посмотреть логически, все ссылки были правильными. Но мы не учитывали взаимодействия в реальном времени с тем процессором, который мог обращаться к памяти не одновременно с нами. И я таки разобрался в этом. Помню, в тот день я работал дома и по телефону постоянно созванивался со своей командой. Внезапно меня словно озарило. Я понял, в чем дело, объяснил им, как исправить ошибку, и больше она не появлялась.

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

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

Событийно-ориентированная модель — та, что применяется в браузере, — работает отлично. Она плохо работает только в том случае, если у вас появляется процесс, который требует много времени. Мне нравится, как Google решил эту проблему в Gears: они используют отдельный процесс, полностью изолированный от остальных, которому можно послать программу для выполнения. По окончании выполнения этот процесс сообщит о результате, и этот результат будет возвращен в качестве события. Просто блестящая модель.

Сейбел: Вас когда-нибудь интересовали формальные доказательства корректности ПО?

Крокфорд: В 1970-е я следил за ними с интересом, ожидая, чем все это закончится. Но особого результата так и не увидел. Программное обеспечение — сложная штука, и что-то может пойти не так по разным причинам.

Программное обеспечение — это прежде всего спецификация того, как программа должна работать. И ничто, кроме полной спецификации, не объяснит вам, каким должно быть поведение в конечном итоге. Именно это делает разработку программного обеспечения настолько сложным.

Сейбел: Как вы тестируете код? Вы заражены тестированием, как сейчас говорят?

Крокфорд: Я скорее стараюсь действовать по обстоятельствам. Это еще один аспект, который я хотел бы изменить в своей работе, но полностью этого еще не сделал.

Сейбел: Речь о JsUnit?

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

В JavaScript тестировать отдельную функцию не слишком разумно, поскольку для ее работы требуется некоторое состояние. Так что я пока не нашел разумный подход к модульному тестированию в JavaScript.

Сейбел: Если в компании есть отдельная группа тестировщиков, то как она должна взаимодействовать с командой разработчиков?

Крокфорд: Я работал в компаниях, где существовало противостояние между командами разработчиков и тестировщиков; по-моему, это нездоровое явление. Там исходили из принципа, что те и другие должны «стучать» друг на друга. Мне кажется, это кошмарная модель.

Гораздо эффективнее, когда две эти команды сидят вместе, и тестеров-щики помогают разработчикам улучшить программу, а не грызутся с ними. Это влияет на способ отчетности, и работа идет куда результативнее. Кроме того, разработчики участвуют в тестировании, так что нельзя сказать, что вы исключительно разработчик или тестировщик.

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

Это дало мне возможность взглянуть изнутри на то, как используются наши программы, и понять, что можно сделать для облегчения их использования. Разработчики, не имевшие подобного опыта, всегда казались мне непростительно высокомерными. Поразительное неуважение к людям, которые пользуются нашим продуктом! А все потому, что они этих людей попросту не видели.

Сейбел: Кем вы себя считаете — ученым, инженером, художником, ремесленником или кем-нибудь еще?

Крокфорд: Скорее писателем. Иногда я пишу на английском, иногда на JavaScript.

В конце концов все сводится к коммуникациям и к структуре, призванной их облегчить. Естественные и компьютерные языки функционируют во многом по-разному, но в конечном счете я сужу о компьютерной программе по ее способности взаимодействовать с человеком, читающим эту программу. В этом смысле различий нет.

Сейбел: И если программа хорошо взаимодействует с человеком, то в части ее взаимодействия с компьютером проблемы почти отпадают?

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

Сейбел: У Дейкстры есть известная статья «On the cruelty of really teaching computing science» (О сложности практического обучения компьютерной науке), где утверждается, что программирование — ветвь прикладной математики. Вы согласны с этим?

Крокфорд: Математика важна для программиста, но это лишь одна из множества других важных вещей. Мне кажется, что преувеличение значения математики может привести к недооценке значения чего-то другого, возможно, более важного, например грамотности.

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

Сейбел: Кажется, у Дейкстры есть примерно такое утверждение: «Если не можешь писать на своем родном языке, лучше не берись за программирование».

Крокфорд: Совершенно согласен.

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

Крокфорд: Да, и в некотором роде это донкихотство. Я знаю, что многое из того, чего я хотел бы добиться, неосуществимо. Но время от времени что-то получается. Так, когда XML предложили в качестве формата обмена данными, моя первая реакция была: «Господи, это же безумно сложно! Все это не нужно для простой передачи данных туда и обратно». Я предложил другой путь, по которому все и пошли. Теперь JSON — самое популярное средство передачи данных в Ajax-приложениях, он активно используется и во многих других приложениях. И он действительно очень прост. Такие случаи возвращают мне веру в человечество, в то, что в конце концов все будет сделано правильно.

Но нельзя, чтобы все разбредались и делали каждый что-то свое. Так не получится, от этого никому не станет лучше. Одни должны создавать продукт, остальные — высказываться «за» или «против». JSON — тоже историческая случайность.

Сейбел: Как вы думаете, индустрия ПО — это система блестящих инноваций или омерзительная свалка?

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

Сейбел: Как ни выражайся, суть останется прежней: омерзительная свалка. Как с ней покончить?

Крокфорд: Вот как раз это я и пытаюсь выяснить. Думаю, во многом нынешняя ситуация связана с нашим подходом к созданию стандартов. Если сегодня все работает хорошо, то это потому, что Сеть работает хорошо. Все преимущества, которые принес Интернет, идут от возможности связать все воедино, причем сделать это достаточно надежным способом. Но стоит немного копнуть, как обнаружатся места, где все работает не так, как надо, и где можно было бы сделать лучше. Вопрос в том, как сделать это прямо на месте. Внесение любого изменения в стандарт — это акт насилия. Это ужасно. Это приведет к неработоспособности множества вещей и нанесет вред людям. Поэтому к изменению стандартов надо подходить очень осторожно, учитывая стоимость внесения изменений. Надо убедиться, что выгоды превосходят нанесенный ущерб. Сейчас, насколько я могу судить, об этом не задумываются. Стандарты меняют, обосновывая это тем, что «мы так хотим», или «так будет понятнее», или еще что-то, совсем необязательно связанное с желанием принести пользу людям. Я борюсь с этим — ведь таким образом мы ничего не улучшим.

Сейбел: Вы склоняетесь к тому, чтобы не создавать лишних спецификаций. Это, конечно, позволяет избежать чрезмерной спецификации и стандартизации того, о чем впоследствии пожалеете. Но чем меньше спецификаций в стандарте, тем больше люди создают самостоятельно, в результате чего появляются неформальные стандарты. Решит ли упрощение стандартов эту проблему или сложность появится с какой-то другой стороны?

Крокфорд: Что нам действительно нужно, так это более точные прогнозы насчет того, что нам может понадобиться в будущем. Может, стоит подождать, пока мы научимся путешествовать во времени, и тогда наконец-то сможем делать все правильно. А пока я смотрю, как люди экспериментируют, придумывают разные подходы к стандартизации. Может быть, взяв лучшие из них, наиболее удобные и приспособленные к дальнейшему совершенствованию, мы получим правильный подход к стандартизации. То есть комитет по стандартизации, вместо того чтобы пытаться предугадать лучший путь, возьмет имеющиеся примеры, которые продемонстрировали лучшие результаты.

Сейбел: Но в целом есть прогресс, как вы считаете?

Крокфорд: Прогресс — это не всегда движение вперед. Иногда мы движемся вперед, иногда отходим назад. Перейдя на персональные компьютеры, мы потеряли кучу всего другого. Тогда рынком правили системы на основе разделения времени. Было сообщество, участники которого могли обмениваться электронными сообщениями, файлами, общаться в чате и играть. Все это с приходом ПК было утрачено и появилось снова лишь через двадцать лет.

Мы также сделали большой шаг назад в плане безопасности. Системы с разделением времени уже начали понимать, как защищать систему и пользователей друг от друга. С переходом на ПК все изменилось: у вас был собственный компьютер, и все, что работало на нем, имело одинаковые права доступа и могло делать что угодно, но потом оказалось, что не все программы, работающие на вашем компьютере, работают в ваших интересах. Мы до сих пор боремся с этим. Да, мы видим множество улучшений в операционных системах персональных компьютеров, но все еще не достигли уровня передовых систем с разделением времени. А сколько лет уже прошло!

Сейбел: О каких конкретно системах вы говорите?

Крокфорд: В MULTICS были интересные возможности по взаимодействию процессов, там было несколько адресных пространств, способных взаимодействовать, но не имевших доступа к содержимому друг друга. Это отправная точка, необходимая для кооперативных вычислений. Сейчас мы думаем, как реализовать это в браузерах. А ведь прошло уже огромное количество времени. Сейчас мы возвращаемся к решениям, внедренным уже тогда.

Сейбел: Я заметил, что нечто похожее происходит и с языками программирования: программы для ПК писались на языке ассемблера, поскольку даже Си был для него слишком высокоуровневым. И только сегодня мы переходим к языкам, по мощности приближающимся к Smalltalk и Лиспу, существовавшим в момент появления ПК. Интересно, программисты задумаются над историческими уроками или так и будем продолжать изобретать велосипед?

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

Есть удивительные истории о том, как все это возникло, вследствие чего, кто это сделал, что считается ошибкой сейчас и что обязательно будет считаться ошибкой со временем. Порой я считаю себя археологом программного обеспечения: понемногу у меня скопилась коллекция недооцененных технологий, вещей, которые я считаю просто великолепными и которые намного превосходят то, что мы делаем сегодня. Я по-прежнему надеюсь, что мы заново откроем для себя все это, по достоинству оценим и извлечем из этого пользу, — но если такое и произойдет, то не скоро. Люди зациклены на том, что есть здесь и сейчас, и сдвинуть их с места нелегко.

Сейбел: Назовите некоторые из этих технологий.

Крокфорд: Ну, скажем, уже упоминавшиеся Лисп и Smalltalk. Отличные вещи; некоторые из тех идей переходят в современные языки, и мы, работая с JavaScript, стараемся воскресить те старые идеи. Правда, в этом языке уже есть многое из того. Лексические границы и функции высшего порядка — это блестяще! А теперь мы пытаемся понять, как внедрить в него больше полезных свойств Smalltalk и Scheme, не нарушая структуру языка. Можно возразить, что лучше бросить все, над чем мы работаем, и просто вернуться к Smalltalk и Scheme; возможно, так действительно было бы лучше, но такой вариант не рассматривается.

Чем больше мы работаем с мэшапами, тем чаще нам требуется импортировать откуда угодно код — который мы никогда не сможем проверить, — и запускать его у себя. Это новый вид программирования. Раньше такого не было. Я считаю, что это — будущее программирования. Мы впервые делаем это в JavaScript, у которого много недостатков, но именно к таким вещам он приспособлен.

Давайте посмотрим на основные этапы истории программирования. Мы начали с машинных кодов, потом совершили скачок к символьному языку ассемблера, потом к высокоуровневым языкам, затем к структурному программированию и наконец к объектно-ориентированному. И каждый такой скачок происходил один раз за поколение.

А вот очередной скачок запаздывает. Мы уже давно застыли на объектно-ориентированном программировании. Можно возразить, что это был Smalltalk-80. Можно пойти и еще дальше вглубь времен, но все равно мы сидим на этих идеях слишком долго.

Думаю, очередной скачок — как бы он ни назывался — будет связан с мэшапами, когда мы сможем брать куски разных программ, соединять их и тут же получать новую программу. Уже десятилетия ведутся разговоры о программной модели, в которой программы собирались бы наподобие конструктора LEGO. Этого пока не произошло, но уже начинает происходить в JavaScript — в наименее ожидаемом месте.

Сейбел: Как вы на собеседовании распознаете хорошего программиста?

Крокфорд: Сейчас я определяю это по чтению кода. Я предлагаю соискателю принести фрагмент его лучшего кода и пройтись по нему.

Сейбел: Что конкретно вы в нем ищете?

Крокфорд: Я ищу там качественное представление кода. Хочу понять, чем этот человек гордится. Убедиться в том, что он действительно автор того, что представил. Я понял, что это куда более эффективный способ, чем предлагать головоломки или задавать стандартные вопросы. По-моему, все это бесполезно. А вот коммуникативные способности — это то, что я ищу.

Сейбел: Что вы можете посоветовать программистам-самоучкам?

Крокфорд: Много читать. Есть масса хороших книг — берите и читайте. А если вы веб-разработчик, зайдите на лучшие сайты и посмотрите их код. Правда, я даю этот совет не без опаски. Большинство веб-разработчиков учились своему делу «глядя в исходники», и до недавнего времени эти исходники никуда не годились. Целое поколение программистов выросло на плохом коде, который они считают образцовым. Сейчас положение исправляется, но плохого кода все еще так много, что я боюсь давать подобный совет.

Сейбел: А что вы порекомендуете тому, кто получает диплом по компьютерным наукам и хочет работать программистом?

Крокфорд: На их месте я бы сконцентрировался на коммуникации. Учитесь писать, учитесь читать.

Всем остальным советую то же самое: читайте и пишите. Принимая человека на работу, я не требую от него специальных навыков. До недавнего времени невозможно было найти хорошего JavaScript-программиста — их было крайне мало. Сейчас они появились, но это произошло буквально только что. До того я брал на работу за хорошие способности. Мне неважно, кто вы — хороший Java-программист, хороший Си-программист или хороший программист на чем-нибудь еще. Для меня важно просто знать, что вы можете реализовать алгоритм, понимаете структуры данных и умеете их документировать. Тогда вам будет понятен и JavaScript.

Сейбел: А у вас не было проблем с этим? Тот, кто хорошо освоил один язык, обычно с трудом отказывается от привычных приемов, применяя их даже тогда, когда новый язык для этого плохо подходит.

Крокфорд: У меня было такое, скажем, с Windows-программистами. В Windows есть ряд очень сложных API, их можно осваивать годами. И получается, что вы ничего не можете, кроме как написать обработчик оконных сообщений. Без особой необходимости я никогда не ищу таких узких специалистов. В общем случае я предпочитаю тех, кто разбирается во всем понемногу, кто способен освоить некоторый API, а не тех, кто на нем специализируется.

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

Крокфорд: У меня именно такое намерение.

Сейбел: И что из этого выходит?

Крокфорд: Большей частью мы справляемся неплохо. Мир улучшается, хотя при этом он не обязательно двигается вперед. Возьмите, к примеру, международные отношения за последние десять лет — появление Интернета не компенсировало разлагающий эффект от объединения крупных СМИ. Это большое разочарование.

В результате погибли сотни тысяч людей. Это печально. Я хочу, чтобы Интернет лучше выполнял свои функции и чтобы такого не повторялось. Пока непонятно, какие преобразования потребуются для достижения этой цели. Может, все образуется само собой, но в этом я пессимист. Думаю, нам нужно найти что-то для следующего скачка, чтобы исправить то, что сейчас плохо работает.

Сейбел: Но ведь миллионы блогеров могут сказать: «Мы тут в блогах отслеживаем все, а традиционные СМИ отдыхают».

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

Сейбел: Думаете, решение этой проблемы отчасти зависит от техники? Могут ли программисты и проектировщики систем создать такую архитектуру, которая будет для этого полезна? Или проблема чисто социальная?

Крокфорд: Может быть, новые социальные системы будут строиться на основе новой сетевой инфраструктуры, и, может быть, она все еще не дозрела до нужного уровня, и проблема в этом. Может быть, все решится само собой — надеюсь, так и будет. Но мне кажется, что без подобной помощи не обойтись. Сейчас в Сети очень слабы системы идентификации и безопасности, и, на мой взгляд, это необходимые компоненты для построения надежной социальной системы. В этом отношении Сеть все еще несовершенна, возможно, отсюда и столько лишних проблем.