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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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