Творческий отбор. Как создавались лучшие продукты Apple во времена Стива Джобса

АКТ I. СЦЕНА XXXVI.

Кампус компании Apple Infinite Loop, Купертино. Кабинет Кена.

Кен сидит за столом. Его руки лежат на клавиатуре. Он печатает команду активировать компилятор на файл под названием kjs_binding.cpp.

КОМПИЛЯТОР: kjs_binding.cpp: error on line 200: use of undeclared identifier «protocol»

(ошибка в строке 200: использование необъявленного идентификатора «протокол»)

Кен ищет соответствующий идентификатор для «протокол». Печатает его.

КЕН: Вот тебе, компилятор! Я определил «протокол». Пожалуйста, попробуй еще раз!

Кен снова вбивает команду активировать компилятор на файл под названием kjs_binding.cpp.

КОМПИЛЯТОР: kjs_binding.cpp: error on line 201: use of undeclared identifier «host»

(ошибка в строке 201: использование необъявленного идентификатора «хост»)

Кен ищет соответствующий идентификатор для «хост». Печатает его.

КЕН: Надо же, я забыл определить идентификатор «хост»! Ну вот он! Попробуем еще раз.

Кен опять вбивает команду активировать компилятор на файл под названием kjs_binding.cpp.

КОМПИЛЯТОР: kjs_binding.cpp: error on line 201: use of undeclared identifier «port»

(ошибка в строке 201: использование необъявленного идентификатора «порт»)

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

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

Наша прикидка насчет двух месяцев оказалась правильной. Наконец, компилятор перестал выдавать сообщения об ошибках. Konqueror скомпилировался на Macintosh, и у нас было приложение, которое можно было запустить двойным щелчком мыши. Когда мы запускали его, наш новый браузер показывал пустое белое окно. Теперь мы должны были заставить код делать то, для чего нужны браузеры, — загружать веб-страницы. Пока наш браузер только «падал» при попытке что-то загрузить. Или вообще ничего не делал.

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

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

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

Мы двигались вперед, и после нескольких недель монотонного труда Ричард взял пару выходных. Он занимался обработкой графических данных для отображения элементов на экране и считал, что близок к тому, чтобы избавиться от нескольких наиболее важных FIXME. Он передал работу мне, и я начал с того места, где он остановился. После нескольких часов анализа я нашел место, где, как мне казалось, программа, грубо говоря, пытается нарисовать что-то на странице, на самом деле не касаясь ручкой бумаги. Будто браузер играет на воображаемой гитаре. Я написал код, чтобы исправить это, затем скомпилировал приложение и запустил его.

Я набрал URL-адрес: http://www.yahoo.com. Как обычно, отчет FIXME заполнялся строка за строкой, но браузер не падал. Прошло несколько секунд, а потом браузер кое-что сделал. Он показал мне картинку.

Я закрыл приложение и попробовал снова. Я опять загрузил домашнюю страницу Yahoo. Отчет FIXME заполнился, браузер не упал, снова та же короткая пауза… и тот же черный прямоугольник!

Черный прямоугольник. Первая настоящая «веб-страница», которую наш браузер Apple загрузил из интернета

Я выбежал в коридор, чтобы позвать Дона. Когда мы вернулись, я закрыл приложение, снова открыл и загрузил главную страницу Yahoo. Во время паузы мы затаили дыхание… и опять увидели все тот же черный прямоугольник! Браузер наконец что-то сделал!

Мы начали кричать, улюлюкать и хлопать друг друга по спине. Мы вели себя как персонажи из фильма «2001 год: Космическая одиссея», когда наши отдаленные предки австралопитеки вошли в контакт с инопланетным Черным монолитом, чему посвящены первые десять минут фильма. Мы даже превзошли их.

Мы тыкали пальцами в экран и вопили. Я попытался снова загрузить страницу. Браузер опять сработал… еще один черный прямоугольник! Это действительно случилось!

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

У нас с Доном состоялась собственная встреча с Черным монолитом. Мы прошли через долгий период блужданий во тьме и сомнений по поводу этого проекта, и теперь наступал рассвет.

Во всей моей карьере в Apple было всего два момента, когда я был готов кричать «Эврика!», и это был один из них. Я жалел, что с нами нет Ричарда, чтобы разделить радость этого мгновения. Его демоверсия показала потенциал Konqueror, а встреча с черным прямоугольником была следующим большим шагом. Она показывала, что стратегия портирования действительно работает, и стала на пути превращения демоверсии в продукт.

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

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

Эдисону тоже приходилось сражаться с техникой, например, искать материал для нити накаливания, который мог бы гореть ярко и долго. Мне очень нравится, как причудливо описываются эти поиски в книге 1910 года под названием «История великих открытий».

Однажды вечером [Эдисон] размышлял над проблемой и, сам того не осознавая, крутил в руках кусочек ламповой сажи [красителя, изготавливающегося из копоти], смешанной со смолой, которую он использовал при создании телефона. Не думая о том, что он делает, Эдисон скатал эту смесь сажи и смолы в нить. Тут он посмотрел на то, что у него получилось, и в голову ученому пришла мысль: «А почему бы не пропустить электрический ток через этот углеродный материал?» Он попробовал, и в результате получилась яркая вспышка…

Затем Эдисон решил найти лучший вариант углеродного материала для своих целей. Он покрывал углем бумагу и различные породы дерева — да и любые материалы, все, из чего можно было сделать углеродную нить. Он пробовал даже использовать японский веер из бамбука, и обнаружил, что это волокно светится лучше, чем что-либо еще. Потом он начал искать лучший вид бамбука. Ученый узнал, что существует 2000 разновидностей этого растения. Он должен был заполучить все образцы. Эдисон отправлял людей по всему миру в разные места, где рос бамбук. Одному из них пришлось преодолеть 48 тысяч миль и повстречаться по дороге с дикими животными. Наконец, в Японии нашелся бамбук, который был лучше других сортов. Поиск материала для углеродной нити обошелся примерно в 100 000 долларов{14}.

В этой короткой истории есть все. Озарение! Отважные люди! Огромные расстояния! Столкновения с дикими животными! Громадные суммы денег! Даже автор истории великих открытий носил имя, подходящее для рассказчика, — Элмер Элсуорт Бернс.

Конечно, настоящая история создания лампочки гораздо сложнее, и, думаю, мы с вполне обоснованно можем спросить, действительно ли Эдисон крутил в руках кусочек ламповой сажи и смолы, а затем ему пришла в голову потрясающая идея пропустить электрический ток через получившуюся у него нить, напоминающую провод. Как Стивен Джонсон пишет в своей книге «Откуда берутся хорошие идеи»[16]: «Народная молва утверждает, что Эдисон является изобретателем лампы накаливания, но, на самом деле она появилась в результате сложной системы взаимодействий между Эдисоном и его соперниками… Эдисон опирался на разработки, по крайней мере, полдюжины других изобретателей, предшествующих ему. Среди них были Джозеф Суон и Уильям Сойер»{15}.

Эдисон не сам выдумал идею электрического освещения, а уголь использовался в исследованиях материалов для нитей накаливания ламп задолго до того, как Эдисон выяснил, что он ему подходит. Джозеф Суон активно экспериментировал с углем. Тем не менее предшественники Эдисона не смогли создать применимую на практике лампу накаливания, а он смог. Почему? Чтобы это объяснить, надо рассказать, что Эдисон понимал освещение как сложную, создающую и распределяющую электричество систему, о его достижениях как изобретателя, способности умело использовать свою репутацию для получения финансирования исследований и о том, что он собирался учредить и возглавить одну из первых ориентированных на продукт исследовательских лабораторий — организацию, которая бы эффективно управляла работой других{16}.

Все это имело значение, но я думаю, что весь успех Эдисона строился на внимании к деталям. Давайте обратимся к тому, как ученый описывает свой подход к основе собственных новаторских исследований. В частности, как он решал такие проблемы, как поиск лучшего материала для лампы накаливания: «Ни одно из моих изобретений не было случайным. Я видел перспективную потребность и проводил опыт за опытом, чтобы прийти к ней. Гений — это один процент вдохновения и девяносто девять процентов тяжелого труда»{17}.

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

Как инженера меня интересуют конкретные цифры, приведенные Эдисоном. Соотношение 1 к 99 между вдохновением и тяжелым трудом выглядит огромным. Так ли это на самом деле? История разработки нашего браузера для Apple позволяет проверить это утверждение. Источником вдохновения для нас послужила демоверсия Ричарда. С этого момента мы с Ричардом и Доном принялись за дело. Мы напряженно работали до момента встречи с черным прямоугольником. Вот приблизительная разбивка затраченного нами времени.

СООТНОШЕНИЕ ЭДИСОНА В ПРОЕКТЕ СОЗДАНИЯ БРАУЗЕРА

На первый взгляд, это соотношение 1:75 показывает, что Эдисон, возможно, переоценивал количество затраченных усилий примерно на 25 процентов, и это серьезная ошибка. Тем не менее в своем заявлении об 1 к 99 Эдисон говорил о состоявшихся изобретениях. Как я уже упоминал, встреча с черным прямоугольником была важной вехой в нашем проекте, но потребовался еще год, чтобы закончить работу. Вспомните, что означал черный прямоугольник, — это был первый раз, когда наш новый код браузера сделал хоть что-то, кроме отказа отвечать, а не упал или выдал кучу отчетов FIXME. И даже в тот момент мы все еще находились на одном из ранних этапов разработки программы. Впереди были многие месяцы до того, как мы решили, что у нас получился конечный продукт, при этом мы уже потратили к тому времени семьдесят пять частей тяжелого труда на одну часть вдохновения. С этой точки зрения, Эдисон значительно недооценил соотношение.

Сомневаюсь, что Эдисон действительно считал свое соотношение 1:99 физическим законом или универсальной константой. Но даже если так, то опыт научил его кое-чему относительно изобретений: главное здесь — напряженный труд.

И все же, если вернуться к отрывку из Бернса, то смола и ламповая сажа в руках занимают в рассказе то же место, что и поиск по всему миру материала для лампы накаливания. Если принимать на веру соотношение Эдисона 1:99, то Бернс в своей книге сильно преувеличивает роль вдохновения, и, возможно, именно поэтому Эдисон говорил о необходимости приложить усилия, чтобы перейти от идеи к изобретению.

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

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

Представьте себе, где бы мы были через несколько недель после показа демоверсии Ричарда, если бы не разработали стратегию портирования и начали над ней работать. Мы добились бы не больше, чем я и Дон за первые шесть недель исследований, пока в Apple не пришел Ричард. Мы никуда не пришли бы, и нам нечего было бы показать. Демоверсия Ричарда вряд ли была бы чем-то бо́льшим, чем программистская диковинка, если бы мы втроем не стиснули зубы и не заставили себя работать без передышки, вспоминая все поговорки о труде, которые знали, когда компилировали код, исправляли перекрестные ссылки по одной за раз, изучали множество примечаний FIXME и в итоге дождались встречи с черным прямоугольником.

Но было ли дело только в этом? Складывалось ли создание браузера всего лишь из хорошей демоверсии и приложенных усилий программистов? И что насчет приложенных усилий? Поскольку Эдисон предполагает, что размышления и разработка гипотез занимают так мало времени, что же тогда составляет остальные 99 процентов тяжкого труда?

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

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

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

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

4. Одно простое правило

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

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

В Apple мы всегда старались поставлять с устройствами лучшие программные продукты, и, помимо скорости, нам нужно было создать браузер со всеобъемлющим набором функций. Первыми в списке стояли удобное управление закладками и четко организованный в соответствии с современными требованиями пользовательский интерфейс. Тем не менее команда сосредоточилась на скорости. Эта трудная задача дала нам цель. Наш чат, работавший по протоколу Internet Relay Chat (IRC), гудел от технических вопросов, комментариев по последним проблемам, идей для воплощения в жизнь, предложений по изменению кода. По меньшей мере четверо или пятеро из нас каждый день собирались за обедом, и мы вместе, как небольшой отряд, шли в Caffe Macs, пересекая кампус в Купертино через зеленую лужайку между Infinite Loop 2 и Infinite Loop 4. Мы шли плотной группой, чтобы каждый из нас мог слышать любой возникший заумный разговор. Я завел традицию ждать за столиком и не начинать есть, пока все не подойдут со своими заказами из кафетерия, и добродушно стыдил остальных, чтобы они делали то же самое — без слов, просто посмотрев искоса, опустив подбородок и слегка приподняв бровь. Начинали есть мы все вместе. Мы не были семьей, но были сплоченной командой.

Мы были такой моделью сотрудничества в стиле Apple — маленькой группой, упорно работавшей над одной задачей — созданием быстрого браузера.

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

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

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

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

Дон был тем, кто придумал, как мы можем заставить код работать быстрее. Однажды, через месяц или два после встречи с черным прямоугольником, он позвал меня к себе в кабинет и попросил написать тестовую программу, чтобы измерить скорость браузера. Он задумал автоматизированный инструмент, который будет запускать наше приложение и отдавать ему команду загрузить несколько страниц, одну за другой, в быстрой последовательности. В течение следующих нескольких дней я писал этот код. Я назвал программу «Тест загрузки страницы» (Page Load Test), но вскоре мы начали называть ее PLT.

PLT стала тренером нашей программы, вроде сержанта-инструктора по строевой подготовке, сжимающего в руке секундомер. Когда мы нажимали кнопку Start в окне PLT, тестовая программа брала первый URL из списка, как такой вот суровый тренер, «орала» этот адрес в лицо браузеру, засекала время, и, нетерпеливо постукивая пальцем, ждала, пока браузер загрузит страницу. Когда страница была полностью загружена и отображена, PLT «останавливала секундомер», отмечала время и «выкрикивала» следующий адрес из списка.

Дон выбирал каждую из сорока страниц в этом списке так, чтобы устроить нашему коду самое суровое испытание, какое только возможно. Он брал страницы, перегруженные текстом, как сайт Yahoo, и страницы, перегруженные графикой, как сайт Disney. В этом списке были и некоторые из самых посещаемых сайтов в сети. Некоторые — такие, как Amazon, Google и Ebay, — вы знаете и сейчас. Другие почти забыты, как Real Networks, Webcrawler и iVillage. Вместе они покрывали все важные характеристики загрузки и отображения веб-страницы, чтобы обнаружить любые слабые места браузера.

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

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

До PLT процесс редактирования в основном был сосредоточен на добавлении новых функций, исправлении ошибок и веб-стандартах гипертекстовых информационных ресурсов — насколько хорошо браузер делает то, что ему положено делать. Все эти показатели были качественными. А PLT проверяла скорость, это был количественный тест, который давал независимую оценку каждому изменению кода, которое мы делали. Теперь точность и скорость шли рука об руку. Дон постановил, что, если мы всегда принимаем во внимание PLT и отклоняем любые изменения кода, замедляющие его, могут произойти только две вещи. Либо скорость браузера останется прежней… либо он станет быстрее. Чтобы подчеркнуть эту хитроумную логику, Дон постукивал указательным пальцем по виску. С того дня, когда PLT будет закончена, заявлял он, наш браузер будет становиться быстрее, потому что перестанет замедляться. Это был его коан.

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

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

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

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

* * *

Даже среди программистов не так уж много знаменитых ученых в области теории вычислительных машин и систем, но Дональд Кнут по праву является одним из них. Он написал книгу «Искусство программирования» (англ. The Art of Computer Programming) — одну из основополагающих работ в компьютерных науках, многотомное руководство, над которым Кнут с самоотверженностью средневекового монаха-отшельника продолжает работать с 1962 года{18}. Он тщательно проводит исследования, пишет с чрезвычайной осторожностью и снабжает свои выпуски такими подзаголовками, как «Введение в комбинаторные алгоритмы и Булевы функции, побитовые решения и методы», «Двоичные диаграммы решений» и «Формирование всех деревьев — история комбинаторной генерации». Для разработчиков программного обеспечения, которые воспринимают свою работу всерьез, Кнут является непревзойденным мастером своего дела. Вот что он говорит об оптимизации:

Программисты тратят огромное количество времени на размышления или беспокойство о скорости работы некритичных частей своих программ, и эти попытки добиться эффективности на самом деле оказывают большое отрицательное воздействие, если говорить о поиске ошибок и поддержании рабочего состояния. Мы должны забывать о низкой эффективности, скажем, в 97 % случаев: преждевременная оптимизация — корень всех проблем{19}. (Выделение автора.)

Оптимизация — это процесс, когда программисты пытаются заставить код работать быстрее. Но разве не для этого была создана программа PLT? И вроде бы оптимизация — это хорошо, правда? Не всегда. И если принимать на веру численную оценку Кнута (а она заслуживает доверия, поскольку этот человек говорит только о вещах, имеющих под собой основание), оптимизация плоха в 97 % случаев. Почему?

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

Приведем пример. Если я приглашу вас к себе на кухню и попрошу:

• Вытащить баночку горчицы из холодильника.

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

• Пойти в супермаркет и купить баночку горчицы.

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

Как это связано с оптимизацией? Вот ряд инструкций для следующего кухонного задания:

• Вытащить все из моего холодильника.

• Расставить предметы на стойке.

А вот попытка оптимизации:

• Вытащить все из моего холодильника.

• Расставить предметы на стойке.

• Сделать как можно меньше подходов.

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

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

Этот один из возможных вариантов развития событий показывает нам, почему такой опытный программист, как Кнут, считает нужным предостеречь на счет оптимизации. Эта дополнительная инструкция «Сделать как можно меньше подходов» повышает шанс ошибок, добавляет двусмысленность, из-за которой труднее изменить код, ведь на самом деле мы не знаем главной причины, по которой был добавлен этап, и конечный результат, вероятно, не окажется быстрее. Эта добавленная для «оптимизации» инструкция может создать больше проблем, чем выгоды. Кнут предполагает, что в 97 процентах случаев так оно и есть.

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

В программировании существует традиционная точка зрения, что «преждевременность», о которой говорит Кнут, каким-то образом связана с расписанием проекта.

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

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

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

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

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

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

С приближением даты выхода проекта отделу маркетинга Apple предстояло выбрать официальное название для нашего браузера. За месяц до объявления о нашем приложении на весь мир, которое планировалось сделать на выставке-конференции Macworld Expo в Сан-Франциско в начале 2003 года, мы все еще называли его или веб-браузером, или «Александром». Последнее, более позднее название, дали проекту в честь великого македонского царя, знаменитого завоевателя. Мы считали, что очень здорово придумали, но в качестве продуктового наименования Apple такое название не годилось. Скотт Форсталл и отдел маркетинга попросили команду, делавшую браузер, предложить идеи для официального имени, но я был так сосредоточен на доведении до совершенства кода, что названия предлагал без всякого энтузиазма и теперь даже не могу их вспомнить.

У Стива Джобса было несколько идей, и, впервые услышав их, я поморщился. Вначале ему нравилось Thunder (гром), но вскоре Стив решил, что Freedom (свобода) гораздо лучше. Мне оба названия показались ужасными. Я просто и представить не мог, как говорю людям: «Я работаю на Freedom», как будто я какой-то полупомешанный фанат супергероев из комиксов.

Тем, кто в конце концов придумал подходящее название, был Скотт. Safari — оно подходило к той же тематике путешествий по всему миру, что и у других известных браузеров Navigator, Explorer, Konqueror. При этом оно не было подражанием. Оно звучало свежо. Дону название тоже пришлось по душе, и, что куда важнее, оно понравилось Стиву.