Завински: Нет. У меня не было никакого желания снова погружаться в споры и эти долбаные противостояния по Bugzilla. Это совсем не весело. Но это неизбежно при создании больших продуктов. Если для работы над проектом требуется больше одного человека (что естественно для таких проектов, как Mozilla), по-другому не получится. Но я не хочу больше этих баталий, за многие годы это желание полностью выбили из меня. Как программист, я могу пойти работать где-то еще. Но мне это не нужно, да я и не хочу. Как только меня что-то достанет, я сразу ухожу. А если я организую собственную компанию, то не смогу там быть программистом, поскольку придется ею руководить.
Сейбел: Что вам нравится в программировании, кроме того что два миллиона человек пользуются вашим продуктом?
Завински: Трудно сказать. Думаю, поиск решения задачи. Это не совсем то же, что головоломка, да я и небольшой любитель головоломок. Просто пытаешься понять, как попасть из точки А в точку Б, и думаешь, как заставить машину выполнять то, что тебе нужно. Удовольствие от программирования заключается главным образом в этом.
Сейбел: Есть ли для вас понятие красоты кода? Помимо возможности поддержки, существует ли эстетическая составляющая?
Завински: Да, конечно. Когда что-то выражено очень верно — лаконично и по сути, — вроде хорошо сформулированного афоризма или мгновенной карикатуры, выполненной одним росчерком пера и очень похожей на оригинал. Что-то в этом духе.
Сейбел: Как вы думаете, программирование и писательская деятельность — это похожие интеллектуальные занятия?
Завински: В каком-то смысле да. Программирование все же гораздо строже. Но они очень близки во всем, что касается способности выражать собственные мысли. Никакого беспорядка: все, что приходит в голову и требует перевода в слова, выражаешь максимально четко. По-моему, именно этим программирование очень близко к сочинению прозы.
Мне кажется, здесь задействованы одни и те же отделы мозга, но выразить это словами нелегко. Я часто читаю код и чувствую, когда в нем что-то не так. Как и в большинстве договоров. Отсутствие гибкости, множество повторений. Смотрю на него и думаю: почему бы не разбить его на подпрограммы (которые мы называем параграфами). И то, что обычно вначале идут такие и такие определения, которые используются бла-бла-бла...
Сейбел: Поговорим о буднях программирования. Как вы проектируете код? Как структурируете его? Может быть, ваша недавняя работа над портированием XScreenSaver под OS X послужит примером?
Завински: Сначала я для затравки создаю маленькие демонстрационные программы, которые больше никем и никогда не используются. Делается это только для того, чтобы выяснить, как расположить окно на экране, и тому подобное. Поскольку я реализую протокол X11, то прежде всего беру один из скринсейверов и составляю список всех вызовов X11, которые он делает.
Потом я делаю для каждого из них заглушку и начинаю понемногу их заполнять, постепенно выясняя, как буду реализовывать тот или другой вызов.
На другом уровне, со стороны Мака, начинаем все с самого начала. Как расположить окно на экране? Затем в какой-то момент приходится прибегать к Xcode. При этом сложнее всего понять, как поднять и заставить работать систему сборки нормальным образом. Приходится экспериментировать, крутить то так, то сяк. Потом думаешь, может поместить этот кусок кода выше, чтобы он обращался вот к этому куску? А может быть, стоит вывернуть это наизнанку? Приходится перетасовывать немало кода, пока в голове не сформируется разумный поток управления. Потом я чищу код, перемещаю его в более подходящие файлы, так чтобы вот этот кусок кода был вместе с вот этим куском.
Это как рисовать жирные стрелки на схеме. Потом я перехожу к следующему скринсеиверу, а он использует другие три функции, которых не было в предыдущем, поэтому мне их тоже нужно реализовать. Каждая из этих задач достаточно проста. Но над некоторыми из них приходится попотеть, потому что в API для X11 есть миллион настроек для отображения текста на экране или для поворота прямоугольника. Постепенно этот кусок кода становится все сложнее. Но большинство задач довольно просты.
Сейбел: Итак, для каждого обращения к X11 вы пишете свою реализацию. А вам никогда не казалось, что у вас набирается куча практически одинакового кода?
Завински: Конечно. После двух-трех раз вырезания и вставки похожего кода думаешь: ага, пора остановиться и поместить этот код в подпрограмму.
Сейбел: Представим, что вы снова работаете над проектом такого же масштаба, что и почтовый клиент. Вы говорили о том, что пишете несколько абзацев текста и список функциональных возможностей. Это практически все, что вы сделаете до начала работы над кодом?
Завински: Да. Может, добавлю небольшое описание различий между библиотекой и клиентской частью. А может, и нет. Если бы я работал один, то я бы с этим не заморачивался, потому что для меня это очевидные вещи. Далее, первое, что я бы сделал, — это решил, сверху или снизу начинать. Можно начать так: расположить на экране окно с несколькими кнопками, а уже потом зарываться в детали и писать логику работы этих кнопок. А можно начать с другого конца — с разбора и сохранения почтовых сообщений. Можно начать с любой стороны или одновременно с двух сторон и затем встретиться посередине.
Я заметил, что получение чего-либо на экране как можно раньше помогает мне лучше сосредоточиться на задаче и понять, что делать дальше. Ведь если смотришь на огромный список задач и не знаешь, за что взяться, то на самом деле не важно, за что возьмешься в первую очередь. Но если есть на что конкретно смотреть, пусть даже это вывод отладочной информации синтаксического анализатора почтовых сообщений, — совсем другое дело! Это уже что-то: куда будем двигаться дальше? Ладно, вместо отображения этой древовидной структуры можно заняться генератором HTML или чем-то в этом духе. Или сделать более детальный разбор заголовков. Просто ищешь очередную задачу, которую нужно решить.
Сейбел: Вы применяете рефакторинг для сохранения целостности внутренней структуры кода? Или с самого начала способны четко представить, как различные части кода будут взаимодействовать между собой?
Завински: Обычно я достаточно хорошо представляю это. Очень мало таких случаев, когда я говорил себе: «Да я же сделал все шиворот-навыворот! Придется все переставить». Но иногда это происходит.
Когда пишу первую версию программы, я стараюсь поместить все в один файл. Потом я начинаю видеть в этом файле структуру. Вот эти блоки очень похожи. Вот в нем уже тысяча строк, так почему бы не переместить что-то в другой файл? Да и API в этом случае получается естественнее. Проектирование — это непрерывный процесс, никогда не знаешь, насколько проект хорош, пока программа не будет готова. Поэтому я предпочитаю как можно скорее снять пробу, получить что-нибудь на экране и посмотреть на это со всех сторон.
И потом, начав писать код, внезапно понимаешь: «Нет, это глупая идея. И почему я решил, что этот модуль сделать легко, когда на самом деле это гораздо сложнее?» Это такие вещи, которые не понять, пока не начнешь писать код и не почувствуешь, как они от тебя ускользают.
Сейбел: Каковы признаки того, что какие-то вещи от тебя ускользают?
Завински: Когда погружаешься во что-нибудь с мыслью «Так, здесь я за полдня напишу кусок кода такой-то длины», а потом приступаешь к работе и постепенно начинаешь чуять недоброе: «Ага, нужен еще кусок, надо бы и за него взяться. Да тут работы выше крыши!»
Сейбел: Я заметил, чем хороший программист отличается от плохого: хороший программист легко переходит от одного уровня абстракции к другому, он способен не смешивать эти уровни при внесении изменений и точно определяет уровень, на котором эти изменения нужно внести.
Завински: В том, где и что размещается, нужно придерживаться определенного стиля, это очень важно во всех отношениях. Решить какую-нибудь проблему на уровне, более близком к пользователю, или внести какое-то, возможно, более крупное изменение, которое отразится на всей системе? Любое из этих решений может быть правильным, и очень сложно понять, какое из них какое. Мне нужно сделать какое-то изменение, но является ли оно единичным частным случаем или таких случаев будет 12?
Думаю, одна из самых важных вещей, по крайней мере для меня, когда создаешь что-то с нуля, заключается как раз в том, чтобы как можно скорее довести программу до состояния, когда ты, программист, сможешь ее использовать. Хотя бы немного. Это подскажет, что делать дальше, — ты буквально почувствуешь, что нужно делать. Когда что-то уже есть на экране и есть кнопка, связанная с некоторой функцией, появляется ощущение, какая кнопка будет следующей. Конечно, это GUI-центричное описание того, что я имею в виду.
Сейбел: Мы немного говорили об ужасных ошибках, с которыми вы сталкивались, например та история с GNB. Но давайте еще немного поговорим о процессе отладки. Для начала, какие инструменты вы предпочитаете? Инструкции печати отладочной информации? Отладчики исходного кода (symbolic debugger)[13]? Формальные доказательства корректности?
Завински: За последние годы многое изменилось. Когда я работал на Лиспе, процесс отладки заключался в запуске программы, ее остановке и последующем изучении данных. Был специальный инструмент, который позволял копаться в памяти, и я изменил его таким образом, что все эти функции стали доступны через цикл Чтение-Вычисление-Печать (то есть через Lisp Listener). Когда этот инструмент выводил содержимое объекта, появлялось контекстное меню, щелкнув на котором, можно было получить значение этого объекта. Все это упрощало следование по цепочкам объектов и всякое такое. Я уже тогда думал о подобных вещах: погрузиться в середину кода, искать, экспериментировать.