Именно такие решения, как отказ от C++ и использования потоков, позволили нам выпустить продукт вовремя. Другой важной составляющей было то, что мы всегда выпускали версии под все платформы одновременно. Это решение они тоже считали глупым: "У 90% пользователей установлена Windows, так что мы сосредоточим усилия на работе версии под Windows, а позже портируем ее под остальные платформы". Так поступали многие компании, потерпевшие крах. Если вы собираетесь выпускать кроссплатформенный продукт, то история показывает, как именно не следует поступать. Если вы действительно хотите выпускать кроссплатформенное решение, то разрабатывать все нужно одновременно. А портирование приводит к паршивому результату на второй платформе.
Сейбел: Версия 4.0 создавалась с нуля?
Завински: Ну, не то чтобы совсем с нуля, но в итоге они переписали каждую строку кода. И использовали C++ с самого начала. Я боролся против этого изо всех сил и, черт возьми, был прав. Все стало распухать, появились проблемы с совместимостью, потому что когда пишешь на C++, невозможно прийти к согласию, какие именно 10% языка можно безопасно использовать. Кто-нибудь говорит: "Мне нужны шаблоны", а затем выясняется, что нет двух компиляторов, которые реализуют шаблоны одинаково.
А когда весь опыт написания кода говорит о том, что мультиплатформенный код означает работу и под Windows 3.1, и под Windows 95, вы даже не представляете, насколько это важно. Поэтому разработка версии под UNIX (к счастью, это была уже не моя проблема) стала настоящим кошмаром, как и разработка версии для Мака. Это означало, что стал невозможным выпуск под старые версии Windows, такие как Win16. Пришлось сокращать количество поддерживаемых платформ. Может быть и пришло время так поступить, но причины были ни к черту. В этом не было необходимости.
Может показаться, что это мой горький, сугубо личный взгляд на вещи, будто мы с Терри создали великолепную штуку и теперь наказаны за свой успех, а в качестве наказания нами управляют идиоты. То время в Netscape стало несчастьем для меня. Начался период, когда я оставался в компании, ожидая, когда Netscape перейдет в другие руки.
Сейбел: И вы проработали там пять лет?
Завински: Да. И еще один год после продажи Netscape, потому что незадолго до этого стартовал проект mozilla.org, и снова стало интересно. Так что я остался из-за него.
Сейбел: Вам все-таки пришлось иметь дело с C++?
Завински: Ну, скорее с Java. В какой-то момент мы решили переписать броузер на Java. Мысли у нас были такие: "Ура! Мы выкинем весь код версии 4.0, который грозит потопить нашу компанию, и это точно сработает, ведь мы знаем, что делаем!"
Но не сработало.
Сейбел: Не сработало, потому что язык Java был еще сырым?
Завински: Нет. Нас снова разбили на четко определенные группы. Трое работали над почтовым клиентом. И мы сделали его. Мы сделали действительно отличный почтовый клиент - быстрый, со многими удобными функциями, он лучше сохранял ваши данные и никогда не тормозил при записи больших файлов. Мы воспользовались многими преимуществами механизма многопоточности языка Java, работа с которым оказалась не такой мучительной, как я ожидал. Работать на самом деле было приятно. С помощью разработанного нами API мы видели все направления, в которых он мог бы развиваться.
Кроме одной вещи, с которой он не справлялся, - отображения сообщений. Он генерировал HTML, а для его отображения нужен был слой отображения HTML, который тогда не был готов и не был готов никогда. Работа группы планирования пошла насмарку, и именно они были причиной отмены всего проекта.
Сейбел: Значит, вам приходилось бороться с сырыми на тот момент библиотеками Java для построения пользовательского интерфейса.
Завински: Нет, я бы так не сказал. Все работало. Просто в середине окна был большой белый прямоугольник, где мог отображаться только обычный текст. Они подходили к проекту очень академично, оперировали такими понятиями, как объектная модель документа (Document Object Model, DOM) и описание типа документа (Document Type Definition, DTD). "Нам нужно создать вот тут еще один уровень абстракции и создать здесь делегирование для делегирования вон того делегирования. И может быть, на экране наконец появится буква".
Сейбел: По-моему, вас сильно раздражает перепроектирование.
Завински: Да. К концу дня доделай эту чертову хрень! Хорошо, конечно, переписывать код, чистить его, чтобы с третьего раза он-таки получился красивым. Но суть-то не в этом, ты сидишь здесь не для того, чтобы писать красивый код, а для того, чтобы выпускать продукт.
Сейбел: Любители перепроектирования часто говорят: "Ну, все пойдет как по маслу, после того как мы прикрутим эту библиотеку. На самом деле мы сэкономим кучу времени".
Завински: Это чистая теория.
Сейбел: Иногда она оправдывает себя на практике, если человек мыслит здраво, а библиотека не слишком переусложнена. Тогда это действительно экономит время. Можете ли вы четко обозначить свою позицию?
Завински: Я знаю, что это банально, но всегда оказывается верным принцип "чем хуже - тем лучше". Если тратишь время на создание совершенной библиотеки, которая будет делать то, что тебе хочется, и позволит сопровождать версии от 1.0 до 5.0, все прекрасно. Но знаете что: пока три года создаешь версию 1.0, конкурент создаст аналогичный продукт за полгода - и ты вне игры. Ты никогда не выпустишь версию 1.0, потому что кто-то успел раньше.
В версии твоего конкурента, выпущенной за полгода, код - полное дерьмо, и они собираются переписать его за два следующих года, но, видите ли, они могут себе это позволить, потому что ты уже без работы.
Сейбел: Иногда, когда время поджимает, приходится выкидывать большой кусок кода, потому что кажется, что проще написать его заново.
Завински: Да, порою кое-что приходится списывать в утиль. Мне никогда не нравился такой подход, но если тебе достается чужой код, бывает проще написать все заново, чем использовать старый. Ведь нужно потратить время, чтобы понять тот код, выяснить, как им пользоваться, и понять его настолько, чтобы ты смог его отлаживать. Начать с нуля получится быстрее. Он может выполнять только 80% от того, что тебе нужно, но, может быть, именно эти 80% тебе и нужны.
Сейбел: А разве не та же логика - когда кто-то приходит и говорит: "Я не могу понять эту ерунду, я просто перепишу ее заново" - приводит к бесконечному переписыванию, что вам так не нравится в разработке программ с открытым исходным кодом?
Завински: Да. Но есть и другой аспект, помимо вопроса эффективности: намного интереснее писать свой код, чем пытаться разобраться в чужом. Так что совершенно понятно, почему так бывает. Но вся возня с Linux/GNOME - это постоянное метание между чьим-то хобби и настоящим продуктом. Что это? Исследовательский проект, с помощью которого мы экспериментируем и пытаемся понять, как должна выглядеть графическая среда пользователя? Или конкуренция с компанией Apple? Трудно заниматься и тем, и другим.
Но даже это утверждение, которое предполагает, что есть некто, принимающий решение, совершенно не соответствует истине. Все это - просто стечение обстоятельств. Вот и получается, что все постоянно переписывается, но так и не доводится до конца. Все просто прекрасно, если компьютер для тебя - это всего лишь игрушка, с которой всегда интересно повозиться, а не средство для достижения цели, не инструмент, с помощью которого доводишь интересное для себя дело до конца.
Сейбел: Кстати, насчет "интересно повозиться": вы все еще получаете удовольствие от программирования?
Завински: Иногда. Сейчас я занимаюсь сисадминской работой, которую терпеть не могу, да и никогда не любил. Мне нравится работать над XScreenSaver, потому что в некотором роде скринсейвер (настоящий скринсейвер, а не библиотека XScreenSaver) - это совершенная программа: все делается с нуля и никаких версий 2.0. И ошибки в такой программе бывают редко. А если она падает (ай-ай-ай, произошло деление на нуль), просто ее исправляешь.
И никто никогда не попросит о новой функции для скринсейвера: "Хочу, чтобы он был более желтым". Ведь скринсейвер такой, какой есть. Вот почему для собственного удовольствия я пишу именно их. Это четкий результат, о котором не надо думать слишком много. Он не преследует тебя.
Сейбел: И вам нравятся головоломки из математики, геометрических построений и графики?
Завински: Да. Если повернуть это маленькое уравнение вот этак, что получится? Как сделать, чтобы эти шарики крутились более естественно и менее механически, чем это свойственно компьютеру? И все такое. Как сделать так, чтобы эти гармонические волны больше походили на чьи-то прыжки?
А затем я стал писать все эти мелкие глупые сценарии командной оболочки для самозащиты. Я знаю, что могу сделать это вручную, щелкнув на одной из 30 000 страниц, но почему бы не написать сценарий и не сэкономить время? Мне ничего не стоит это запрограммировать. А непрограммистам это кажется волшебством.
Мне очень понравилось портировать библиотеку XScreenSaver для Мака. Пришлось написать немало нового кода, обдумать API и всю общую структуру.
Сейбел: Вы проектировали API? Как вы структурировали код?
Завински: Я одновременно рассматривал существующие API и пытался найти лучший способ создать слой между миром X11 и миром Мака. Как мне все это структурировать? Какие API Мака подойдут лучше? Впервые за долгое время я сделал что-то и подумал: "Здорово! Пожалуй, тут я еще кое-что могу".
И это было незабываемое ощущение, потому что индустрия разработки ПО вымотала меня. Я не мог больше выносить всю эту политику как в мире корпораций, так и в среде свободных разработчиков. Я был сыт этим по горло. Я хотел работать над чем-то, где не было бы споров по всяким мелочам, и не хотел видеть, как мой продукт уничтожается бюрократическим решением, перед которым я бессилен.
Сейбел: А не было искушения вернуться и поработать над Mozilla?
Завински: Нет. У меня не было никакого желания снова погружаться в споры и эти долбаные противостояния по Bugzilla. Это совсем не весело. Но это неизбежно при создании больших продуктов. Если для работы над проектом требуется больше одного человека (что естественно для таких проектов, как Mozilla), по-другому не получится. Но я не хочу больше этих баталий, за многие годы это желание полностью выбили из меня. Как программист, я могу пойти работать где-то еще. Но мне это не нужно, да я и не хочу. Как только меня что-то достанет, я сразу ухожу. А если я организую собственную компанию, то не смогу там быть программистом, поскольку придется ею руководить.
Сейбел: Что вам нравится в программировании, кроме того что два миллиона человек пользуются вашим продуктом?
Завински: Трудно сказать. Думаю, поиск решения задачи. Это не совсем то же, что головоломка, да я и небольшой любитель головоломок. Просто пытаешься понять, как попасть из точки А в точку Б, и думаешь, как заставить машину выполнять то, что тебе нужно. Удовольствие от программирования заключается главным образом в этом.
Сейбел: Есть ли для вас понятие красоты кода? Помимо возможности поддержки, существует ли эстетическая составляющая?
Завински: Да, конечно. Когда что-то выражено очень верно - лаконично и по сути, - вроде хорошо сформулированного афоризма или мгновенной карикатуры, выполненной одним росчерком пера и очень похожей на оригинал. Что-то в этом духе.
Сейбел: Как вы думаете, программирование и писательская деятельность - это похожие интеллектуальные занятия?
Завински: В каком-то смысле да. Программирование все же гораздо строже. Но они очень близки во всем, что касается способности выражать собственные мысли. Никакого беспорядка: все, что приходит в голову и требует перевода в слова, выражаешь максимально четко. По-моему, именно этим программирование очень близко к сочинению прозы.
Мне кажется, здесь задействованы одни и те же отделы мозга, но выразить это словами нелегко. Я часто читаю код и чувствую, когда в нем что-то не так. Как и в большинстве договоров. Отсутствие гибкости, множество повторений. Смотрю на него и думаю: почему бы не разбить его на подпрограммы (которые мы называем параграфами). И то, что обычно вначале идут такие и такие определения, которые используются бла-бла-бла...
Сейбел: Поговорим о буднях программирования. Как вы проектируете код? Как структурируете его? Может быть, ваша недавняя работа над портированием XScreenSaver под OS X послужит примером?
Завински: Сначала я для затравки создаю маленькие демонстрационные программы, которые больше никем и никогда не используются. Делается это только для того, чтобы выяснить, как расположить окно на экране, и тому подобное. Поскольку я реализую протокол X11, то прежде всего беру один из скринсейверов и составляю список всех вызовов X11, которые он делает.
Потом я делаю для каждого из них заглушку и начинаю понемногу их заполнять, постепенно выясняя, как буду реализовывать тот или другой вызов.
На другом уровне, со стороны Мака, начинаем все с самого начала. Как расположить окно на экране? Затем в какой-то момент приходится прибегать к Xcode. При этом сложнее всего понять, как поднять и заставить работать систему сборки нормальным образом. Приходится экспериментировать, крутить то так, то сяк. Потом думаешь, может поместить этот кусок кода выше, чтобы он обращался вот к этому куску? А может быть, стоит вывернуть это наизнанку? Приходится перетасовывать немало кода, пока в голове не сформируется разумный поток управления. Потом я чищу код, перемещаю его в более подходящие файлы, так чтобы вот этот кусок кода был вместе с вот этим куском.
Это как рисовать жирные стрелки на схеме. Потом я перехожу к следующему скринсеиверу, а он использует другие три функции, которых не было в предыдущем, поэтому мне их тоже нужно реализовать. Каждая из этих задач достаточно проста. Но над некоторыми из них приходится попотеть, потому что в API для X11 есть миллион настроек для отображения текста на экране или для поворота прямоугольника. Постепенно этот кусок кода становится все сложнее. Но большинство задач довольно просты.
Сейбел: Итак, для каждого обращения к X11 вы пишете свою реализацию. А вам никогда не казалось, что у вас набирается куча практически одинакового кода?
Завински: Конечно. После двух-трех раз вырезания и вставки похожего кода думаешь: ага, пора остановиться и поместить этот код в подпрограмму.
Сейбел: Представим, что вы снова работаете над проектом такого же масштаба, что и почтовый клиент. Вы говорили о том, что пишете несколько абзацев текста и список функциональных возможностей. Это практически все, что вы сделаете до начала работы над кодом?
Завински: Да. Может, добавлю небольшое описание различий между библиотекой и клиентской частью. А может, и нет. Если бы я работал один, то я бы с этим не заморачивался, потому что для меня это очевидные вещи. Далее, первое, что я бы сделал, - это решил, сверху или снизу начинать. Можно начать так: расположить на экране окно с несколькими кнопками, а уже потом зарываться в детали и писать логику работы этих кнопок. А можно начать с другого конца - с разбора и сохранения почтовых сообщений. Можно начать с любой стороны или одновременно с двух сторон и затем встретиться посередине.
Я заметил, что получение чего-либо на экране как можно раньше помогает мне лучше сосредоточиться на задаче и понять, что делать дальше. Ведь если смотришь на огромный список задач и не знаешь, за что взяться, то на самом деле не важно, за что возьмешься в первую очередь. Но если есть на что конкретно смотреть, пусть даже это вывод отладочной информации синтаксического анализатора почтовых сообщений, - совсем другое дело! Это уже что-то: куда будем двигаться дальше? Ладно, вместо отображения этой древовидной структуры можно заняться генератором HTML или чем-то в этом духе. Или сделать более детальный разбор заголовков. Просто ищешь очередную задачу, которую нужно решить.
Сейбел: Вы применяете рефакторинг для сохранения целостности внутренней структуры кода? Или с самого начала способны четко представить, как различные части кода будут взаимодействовать между собой?
Завински: Обычно я достаточно хорошо представляю это. Очень мало таких случаев, когда я говорил себе: "Да я же сделал все шиворот-навыворот! Придется все переставить". Но иногда это происходит.
Когда пишу первую версию программы, я стараюсь поместить все в один файл. Потом я начинаю видеть в этом файле структуру. Вот эти блоки очень похожи. Вот в нем уже тысяча строк, так почему бы не переместить что-то в другой файл? Да и API в этом случае получается естественнее. Проектирование - это непрерывный процесс, никогда не знаешь, насколько проект хорош, пока программа не будет готова. Поэтому я предпочитаю как можно скорее снять пробу, получить что-нибудь на экране и посмотреть на это со всех сторон.
И потом, начав писать код, внезапно понимаешь: "Нет, это глупая идея. И почему я решил, что этот модуль сделать легко, когда на самом деле это гораздо сложнее?" Это такие вещи, которые не понять, пока не начнешь писать код и не почувствуешь, как они от тебя ускользают.
Сейбел: Каковы признаки того, что какие-то вещи от тебя ускользают?
Завински: Когда погружаешься во что-нибудь с мыслью "Так, здесь я за полдня напишу кусок кода такой-то длины", а потом приступаешь к работе и постепенно начинаешь чуять недоброе: "Ага, нужен еще кусок, надо бы и за него взяться. Да тут работы выше крыши!"
Сейбел: Я заметил, чем хороший программист отличается от плохого: хороший программист легко переходит от одного уровня абстракции к другому, он способен не смешивать эти уровни при внесении изменений и точно определяет уровень, на котором эти изменения нужно внести.
Завински: В том, где и что размещается, нужно придерживаться определенного стиля, это очень важно во всех отношениях. Решить какую-нибудь проблему на уровне, более близком к пользователю, или внести какое-то, возможно, более крупное изменение, которое отразится на всей системе? Любое из этих решений может быть правильным, и очень сложно понять, какое из них какое. Мне нужно сделать какое-то изменение, но является ли оно единичным частным случаем или таких случаев будет 12?