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

Мы с Доном устроили совещание. Он сказал, что собирается уехать на неделю в отпуск, который планировал еще до того, как мы начали работать в Apple. Он хотел, чтобы я за эту неделю полностью погрузился в попытки скомпилировать Mozilla под Mac OS X.

И я погрузился. Я педантично делал заметки. Я проводил долгие часы один на один с кодом. Когда Дон вернулся в офис, я передал ему документ, озаглавленный «Компилирование Lizard. Пятьдесят шагов, чтобы запустить Mozilla на Mac OS X».

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

Хорошая новость состояла в том, что все эти шаги работали… Ну, в какой-то мере. Следуя указаниям, мне удалось воспроизвести ярлык программы веб-браузера на своем рабочем столе. Плохая новость состояла в том, что это приложение-Франкенштейн не оживало. Когда я кликал мышью по иконке, Mozilla запускался, но не загружал веб-страницы. Что бы я ни пытался сделать, браузер неизбежно «падал». Пытаясь понять, что не так, я безнадежно запутался в миллионе с лишним строчек исходного кода.

Занимаясь всеми этими исследованиями браузеров, мы одновременно пытались нанять в команду других людей. Мы получили одобрение на то, чтобы взять еще пару программистов, и еще до официального объявления Apple о вакансии начали поиски. Дон знал нескольких человек из Netscape, имеющих опыт в создании браузеров, мы знали нескольких отличных программистов из Eazel, которые все еще не приняли решения по поводу новой работы, и еще мы получили пару заявок от кандидатов внутри компании. Мы столкнулись и с новой трудностью: как убедить людей, у которых есть другие хорошие варианты, согласиться на работу в проекте, о котором мы не можем им рассказать. Дон делал это подмигивая и одновременно заверяя кандидата в том, что его зовут в «большое дело». Все нам отказывали. Те, у кого был опыт работы в Netscape, понимали намек Дона, и никто не хотел никоим образом участвовать в создании еще одного браузера. После недавних мучений с Mozilla я понимал, почему они ведут себя именно так.

В разгар моей борьбы с Mozilla я познакомился с новым кандидатом. Ричард Уильямсон начал с того, что заявил, будто знает, как быстро добиться результата. С британским акцентом, смягченным двумя десятками лет проживания в Соединенных Штатах, он рассказал о себе. В подростковом возрасте он основал собственную компанию по разработке ПО, пару лет занимался смартфонами, затем сделал паузу в учебе, проработав год в NeXT, компании, которой руководил Стив Джобс после увольнения из Apple. Вернувшись после окончания учебы в NeXT, Уильямсон иногда получал приказы от самого Джобса — например, Стив посылал его в Японию на переговоры с клиентом о создании дополнительной сетевой карты для компьютеров NeXT. Переговоры Ричард провел успешно.

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

Но были у Ричарда реальные достижения или он просто умел хорошо говорить? Пытаясь понять это, я спросил его о конкретных технических проблемах, с которыми он сталкивался, и как он их решал.

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

После собеседования я пошел к Дону и сказал, что не уверен насчет смелых заявлений Ричарда. Дон ответил, что Бертран Серле, начальник Скотта Форсталла, работал с Ричардом в NeXT и очень хорошо о нем отзывается. На Дона собеседование произвело впечатление, и он хотел взять Уильямсона на работу. Но друг уважал мои сомнения и предложил мне позвонить Ричарду по телефону и поговорить еще.

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

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

— А как долго вы, ребята, работаете над этим проектом с браузером? — спросил Ричард.

Судя по его тону, наши усилия его не впечатлили.

— Шесть недель, — ответил Дон.

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

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

Обустройство не заняло у Ричарда много времени. Через два дня он позвал нас к себе посмотреть демоверсию. Что?! Демоверсию?

Мы с Доном пришли в темный кабинет Уильямсона, где не было окон и светился только экран его компьютера Mac. Мы заглядывали к нему через плечо, пока Ричард щелчком мыши запускал веб-браузер. Не просто оболочку, а настоящий, действующий браузер. Он успешно загружал страницы, «кликал» ссылки, возвращался назад, «кликал» другие ссылки, загружал еще страницы — в целом, он серфил по интернету как ни в чем не бывало. Что же, черт возьми, мы видели?

Уильямсон объяснил, что перед нами Konqueror, один из браузеров с открытым исходным кодом, о котором мы рассказали ему пару дней назад. Konqueror был разработан в проекте KDE — сообществе программистов, чьи цели были схожи с проектом GNOME. KDE также представлял собой полнофункциональную компьютерную среду, похожую на Mac и Windows, систему, построенную вокруг свободного программного ядра Linux.

Ричард рассказал, что он загрузил KDE и поставил себе простую цель: добиться работающего на Mac кода так быстро, как только возможно, чтобы он мог оценить потенциал веб-браузера Konqueror. Поскольку KDE работает на Linux, а не на Mac OS X, Ричарду пришлось, как он сказал, сделать оболочку — дополнительное программное обеспечение, которое заставляло Konqueror «думать», что он работает на компьютере с Linux, а потом «убеждало» компьютер, что браузер — это программа, сделанная под Macintosh. Внесу ясность: написать оболочку чрезвычайно сложно. Понимать, что эта проблема разрешима, было потрясно. Всего за два дня у нас была рабочая оболочка, так что уверенность Ричарда в своих силах оказалась небезосновательной. Да что там, это был высший пилотаж программирования.

Видя наше изумление, Уильямсон сказал нам, что были две хитрости, с помощью которых он заставил свою демоверсию работать. Во-первых, он использовал графическую подсистему Linux X Windows вместо графической системы Apple, оригинальной для Mac OS X. Во-вторых, он запустил всю систему KDE, а не только веб-браузер Konqueror. Если для вас эти слова могут звучать как техническая абракадабра, то для нас они ею не были. Чем дальше Ричард описывал свою работу, тем больше мы с Доном понимали, как эти хитрости позволили ему быстро воспользоваться кодом Konqueror.

Уильямсон не беспокоился о том, что X Windows не идеально встроилась в горизонтальное меню вверху экрана Mac, о том, чтобы шрифты отображались один в один, строго до пикселя, о том, что система KDE включала множество программного обеспечения, не имеющего отношения к веб-браузеру. Ричард знал, что эти технические детали придется решать в процессе разработки, но также он знал, что тревога по поводу хитростей, которые он применил, исчезнет из сознания смотрящих демоверсию, как только он повернется к компьютеру и нырнет в интернет с помощью чего-то, выглядящего очень похоже на браузер для Macintosh.

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

Мы с Доном шесть недель работали над созданием веб-браузера для Macintosh, но у нас все еще не было работающего кода и никаких вариантов его сделать. За очень маленький отрезок этого времени Ричард загрузил веб-браузер из Linux и приспособил Konqueror так, что его можно было загружать на Mac. Его демоверсия браузера работала, она могла загружать веб-страницы, она не «падала» и хорошо себя показывала. Мы с Доном были восхищены. Если бы Ричард еще и повторил свои движения коленчатого вала, думаю, я бы упал в обморок.

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

Можно ли лучше оценить его достижение, измерить его качественно и количественно? Возникает искушение процитировать легендарное высказывание и назвать Ричарда «10х программистом» — суперпродуктивным гением, который может приносить намного больше пользы, чем простые смертные{9}.

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

Имеют ли эти ограничения отношение к развитию информационных технологий? В классической книге по разработке программного обеспечения «Мифический человеко-месяц»{10}, вышедшей в 1975 году, Фредерик Брукс говорит, что имеют. Рассказывая о том, чему он научился, будучи руководителем проекта по созданию операционной системы мейнфреймов OS/360 в 1960-е годы в IBM, Брукс делится наблюдением: «Если задачу нельзя разбить на части, поскольку существуют ограничения на последовательность выполнения этапов, то увеличение затрат не оказывает влияния на график. Чтобы родить ребенка, требуется девять месяцев, независимо от того, сколько женщин привлечено к решению данной задачи»{11}.

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

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

Более того, Ричард за два рабочих человеко-дня сделал для нашего проекта больше, чем мы с Доном сделали за предыдущие двенадцать человеко-недель. Это ускорение более чем в тридцать раз.

Чем можно объяснить такое отличие? Поначалу может сложиться впечатление, что многое держится на ловкости Ричарда как программиста, на его созданной программными средствами оболочке. Тем не менее его усилия по работе с Konqueror очень напоминают мои попытки обуздать Mozilla. Возможно, он просто был куда лучшим программистом, чем я, и без его таланта в разработке кода не было бы и этой истории.

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

Он начал с того, что расспросил нас о том, какой анализ браузеров мы провели до его прихода в компанию, и, услышав об этом, быстро сбросил со счетов нашу идею с Mozilla, поскольку этот браузер едва ли нам подходил. Так он показал, что уверен в себе, и не стал заискивать перед руководителем с многолетним опытом в технической области, где Уильямсон был новичком. Далее Ричард сумел добиться результата в самые короткие возможные сроки. Он загрузил проект с открытым исходным кодом, который выглядел многообещающим, — исходник Konqueror из KDE, браузер, который мог стать основой для нашей долговременной работы. Пытаясь заставить этот код работать на Macintosh, Уильямсон решил сделать наиболее близкую к реальности версию браузера, которую только возможно было создать за короткий срок. Он выделил три функции: загрузка страниц, переход по ссылкам и возвращение на предыдущую страницу. Он посчитал, что уже это может стать достаточно веским подтверждением концепции. Затем Ричард применил свои хитрости для упрощения задачи, и после стало понятно, чего у нас пока не будет: на время пришлось отказаться от идеального отображения шрифтов, а также от полной интеграции с оригинальной графической системой Macintosh, равно как и от использования минимального количества исходного кода KDE. Уильямсон рассудил, что все эти недоделки хотя и имеют значение, но не могут существенно преуменьшить значение от появления браузера, отображающего веб-страницы. Он решил свести воедино все эти составные части в одну демоверсию, которая показала бы потенциал Konqueror. Наконец, затем он проработал технические детали и таким образом разработал оболочку, поскольку оставалось только одно препятствие, мешающее реализации его плана. Его мышление дополнило техническую смекалку.

А вот мы с Доном вцепились в то, что Mozilla каким-то образом оправдает ожидания. Я пытался заставить эту громадину с открытым исходным кодом скомпилироваться на Macintosh, нисколько не думая, что же будет после этого. У меня не было никаких достойных планов, целей, списка того, чем можно пренебречь, жесткого графика или технических задумок.

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

Если бы мы с Доном продолжили работать в Apple так же, как было принято в Eazel, кто знает, когда мы смогли бы показать демоверсию? В тот момент нашей карьеры мы просто не знали, как раскрутить крупный проект и вывести его к успеху.

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

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

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

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

Одна из моих любимых натурных сцен — это площадка из «Поющих под дождем», мюзикла 1952 года, выпущенного компанией Metro-Goldwyn-Mayer, с Джином Келли и Дебби Рейнольдс в главных ролях. Рассмотрим заглавный танцевальный номер фильма, где Джин Келли после того, как поцеловал Дебби Рейнольдс, желая ей спокойной ночи на крыльце ее дома, с ликованием отбивает чечетку, прыгает, приземляется в воду и кружится под проливным дождем. Эта сцена поставлена на голливудской натурной площадке, изображающей городскую улицу. Сразу после того, как Келли окатил бурный поток воды из водосточной трубы, спускающейся с крыши одного из «зданий», мимо которых он движется в танце, актер минует магазин женских головных уборов La Valle — соблазнительно выглядящую витрину с выставленными в ней модными женскими шляпками. Конечно, этот магазин не был настоящим. Витрина могла быть плоской фанерой, за которой ничего не было, или за дверью «магазина» мог скрываться обычный студийный кабинет, где, возможно, сидел бухгалтер или клерк MGM. Нам это неважно. Мы слишком очарованы танцами и пением. Сравните этот фальшивый магазин шляп с еще одним предметом реквизита, который мы видели раньше, когда Келли запрыгивал на фонарный столб на краю тротуара. В отличие от магазина шляп этот фонарный столб должен быть реальным или, по крайней мере, достаточно реальным, чтобы выдержать вес актера. А что насчет остальных фонарных столбов на площадке? Мы не знаем, но, опять же, нам это не важно. Может быть, они настоящие, а возможно, и нет, но декораторы должны быть уверены в том, что один определенный фонарный столб достаточно прочен, чтобы главный герой фильма запрыгнул на него. Он должен быть хорошо сделан, потому что этого требует танец.

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

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

За годы, которые прошли с тех пор, когда Ричард показал мне свою демоверсию браузера, я перенял манеру его работы.

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

Главное — это, собственно, то, что обведено маркером, и им я уделяю особое внимание, точно так же, как декораторы уделяли внимание фонарному столбу на съемочной площадке. За пределами нарисованных кругов я оставляю менее важные детали, которыми, конечно, когда-нибудь придется заняться, но делать это немедленно нет необходимости. Им я уделяю минимум внимания. Я исключаю их из демоверсии, если могу без них обойтись, как внутреннюю часть того магазина головных уборов. С особой осторожностью я подхожу к тому, что оказывается на границе. Некоторые элементы находятся на воображаемой жирной черте. Это детали, которые требуют некоторого внимания, поскольку они помогают задать тон и развеять сомнения тех, кто будет смотреть демо. Например, если речь об экране параметров настройки приложения или второстепенном элементе пользовательского интерфейса, находящемся в стадии разработки, я могу сделать скриншот экрана с настройками другого приложения вместо того, чтобы делать полный рабочий интерфейс. Это похоже на то, как реквизитор кладет в витрину несколько шляп. Я хочу, чтобы те, кто будет смотреть мою демоверсию, думали, что видят что-то настоящее, хотя оно таковым и не является. Я понимаю, что она не является реальным продуктом, и моя аудитория тоже это понимает, но в процессе разработки создание видимости настоящего продукта очень важно для того, чтобы увидеть, чего же мы в действительности пытаемся добиться. Таким же образом мои коллеги могут начать реагировать и давать отзывы о моей работе, словно демоверсия — это уже продукт.

Эта попытка сделать процесс разработки непрерывным и последовательным предполагает еще одну, последнюю характеристику, которую можно сравнить с работой на съемочной площадке. И площадка, и демоверсия — части какого-то крупного проекта. У каждой своя история. Танцы и пение Джина Келли под дождем выражают его радость от первого поцелуя, это тот момент фильма, когда главные герои показывают нам, что влюбились друг в друга. Это магия Голливуда в своем лучшем проявлении. Демоверсия Ричарда была тем переломным моментом, когда нам показали потенциальные возможности открытого кода Konqueror, и мы решили, что это может быть ответом на вопрос, который мы искали. Это магия Кремниевой долины в ее лучшем проявлении.

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

Всему этому мы научились у Ричарда. Он изменил то, как мы работали.

3. Черный прямоугольник

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

Дон поручил работу по подсчету строк мне, вероятно, дав возможность внести свой вклад в достижение Ричарда. Если он хотел меня так мотивировать, то ему это удалось. На следующее утро после показа браузера я пришел в офис примерно на час раньше обычного, около шести утра. На стол рядом со своим Macintosh я установил PC с системным блоком типа «башня». Я собирался установить на него Linux и загрузить весь исходный код KDE. Сделав это, я бы изучил код и провел несколько тестов, чтобы начать процедуру отделения Konqueror от окружающей его системы.

Пока все устанавливалось, я смотрел на стоящие передо мной два компьютера: персональный компьютер с Linux и Macintosh. На моем столе их разделяло всего несколько сантиметров, но в плане ПО они были гораздо дальше друг от друга. Хотя можно проследить общее происхождение Linux и Mac OS X, восходящее к UNIX, операционной системе, созданной как исследовательский проект в лаборатории Bell в 1969 году, обе системы сильно отдалились от своей предшественницы. Со временем Linux и Mac стали напоминать две местности, в которых говорили на одном языке, но с разными диалектами. Linux говорил «трейлер», а Mac — «фура». Если говорить о таких приложениях, как веб-браузеры, то между ними едва ли существовала совместимость, но, если копнуть глубже, на уровне алгоритмов, с которыми работают программисты, сходство двух систем проявлялось сильнее. В них была общая техническая грамматика, обе системы позволяли компилировать и запускать программы, написанные на C++, языке программирования, который разработчики Konqueror использовали для написания исходного кода. Но даже при этом Linux и Mac использовали разные словари и идиомы программирования для написания программ на C++, особенно когда речь шла о графических пользовательских интерфейсах. В конечном счете мы не могли просто скопировать код с одного компьютера на другой. Если мы хотели использовать Konqueror как основу для нашего проекта веб-браузера, мы должны были залатать все подобные терминологические и технические отличия в исходном коде Konqueror под Linux и заменить оболочку Ричарда прочным фундаментом программного обеспечения. Адаптация кода, написанного для одной операционной системы, так, чтобы он работал на другой, настолько распространена, что у программистов даже есть специальное слово для описания этой задачи — портирование. Поскольку на выходе нам нужно было получить браузер стандарта Apple, исходный код которого должен был работать так, будто он изначально был написан для Mac (хотя это было не так), нам в самом деле предстояла большая работа по портированию.

Для того чтобы выделить код браузера из системы KDE, мне не потребовалось много времени. Программное обеспечение было организовано очень аккуратно, и Konqueror обитал, в основном, в двух директориях: KHTML и KJS.

После того, как я отделил код, я дал компьютеру задание подсчитать общее количество строк в этих двух директориях. Это должно было дать нам примерное представление о том, какой объем портирования нас ждет. Поскольку портирование могло потребоваться для каждой строчки кода, то, чем меньше их будет, тем лучше. Увидев результат, я улыбнулся, а когда я сообщил о нем Дону и Ричарду, они тоже расплылись в улыбке. В Konqueror было чуть больше 120 000 строк, и он составлял менее одной десятой размера Mozilla{12}. Сначала мы просто не могли поверить, что между двумя массивами исходного кода со схожими функциями может быть такая разница.

Дон объяснил, почему так произошло. Руководители проекта Mozilla разрабатывали систему, которая, как они надеялись, превратит их программное обеспечение в компоненты, соединяющиеся друг с другом, как кубики LEGO. Тем не менее такая схема требовала большого количества дополнительного стереотипного кода: программисты должны были сделать что-то вроде заполнения кучи форм, чтобы регистрировать новый код при повторном запуске системы, и эта волокита поглотила браузер. Теперь мы видели результат применения этого инженерного решения — размер кода Mozilla соотносился с кодом Konqueror как 10 к 1. Очевидно, работа с этими составляющими вышла из-под контроля. Mozilla оказался раздутым, громоздким и ненадежным.

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

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

Успехи добавили нам уверенности взяться за дело. Дон сказал, что он вместе с Ричардом покажет его демоверсию всей цепочке руководителей, отвечающих за создание программного обеспечения. Они надеялись получить одобрение Скотта Форсталла, его начальника Бертрана Серле и босса Бертрана Эви Теваняна на то, чтобы использовать Konqueror как основу нашего проекта по созданию веб-браузера.

Через несколько дней выяснилось, что наши руководители приятно удивлены, как мы и надеялись.

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

После получения их одобрения нужно было разработать стратегию портирования 120 000 строк кода Konqueror на Macintosh. Чтобы понять, какую сложную программистскую задачу нам предстояло попытаться решить, потребуется некоторое знание жаргона разработчиков.

* * *

Когда я хочу, чтобы компьютер выполнил какую-то работу, я пишу точные инструкции, используя один из языков программирования, например, C++ — тот язык, который разработчики KDE использовали для создания Konqueror.

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

Поскольку полнофункциональные программы, такие как браузер, требуют большого количества исходного кода — более 100 000 строк для достаточно скромного Konqueror, например, — программисты разбивают все эти строки на отдельные файлы исходного кода. Это помогает им организовать и структурировать отдельные подзадачи. В случае с веб-браузером код, отвечающий за обработку веб-адресов (URL) может содержаться всего в одном файле исходного кода, тогда как связанная с ним более сложная составляющая, например использование URL для загрузки информации, может быть распределена по многим файлам исходного кода.

Шеф-повара также разделяют свои рецепты на отдельные части. Рецепт яиц «Бенедикт», к примеру, помимо инструкций по приготовлению яйца-пашот, поджаривания канадского бекона и английских булочек, будет содержать часть с рецептом голландского соуса. Тем не менее, автор кулинарной книги может не привести полное описание рецепта голландского соуса непосредственно для яиц «Бенедикт», особенно если этот соус встречается в других блюдах в той же книге, например в рецепте приготовления спаржи. В большой кулинарной книге, скорее всего, будет только один рецепт голландского соуса, на который автор будет ссылаться при описании всех блюд, где он используется, примерно вот так: «см. Голландский соус, с. 123».

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

Эта система не идеальна, поскольку в схеме перекрестных ссылок могут быть ошибки. Например, если я нахожусь в середине приготовления яиц «Бенедикт» и пытаюсь найти ссылку на голландский соус на странице 123, я могу открыть кулинарную книгу на 132 странице, и нужного мне рецепта там не будет.

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

Когда я делаю похожую ошибку в программе, компилятор выдает мне сообщение об ошибке. Обычно такие сообщения бывают краткими и точными: «expected expression, line 3, column 5» («ожидается выражение в строке 3, колонке 5»). Это может оказаться и ошибкой при наборе, и простой логической ошибкой. Такое сообщение напоминает шеф-повара на суматошной кухне, который бросает один взгляд через плечо помощника, готовящего тарелку яиц «Бенедикт», и выносит приговор: «Голландский соус слишком густой!» Оба этих сообщения констатируют ошибку, и, хотя в них нет четких инструкций решения проблемы, они чрезвычайно полезны.

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

* * *

Получив «добро» от начальства, мы с Ричардом и Доном собрались, чтобы разработать нашу стратегию портирования.

Прежде всего мы должны были вернуться к демоверсии Ричарда и разобраться со всеми трудными местами, которые он в ней обошел. Чтобы сделать это, нам предстояло скопировать исходный код Konqueror на Macintosh и скомпилировать его. Затем нужно было все проверить и выловить ошибки, чтобы в результате код браузера выглядел как написанный для системы Mac.

Также, поскольку Konqueror относился к свободному ПО, нам приходилось подчиняться лицензии Столлмана, которую авторы прикрепили к своему софту. Наше руководство хотело опубликовать исходный код части программного обеспечения, но по большей части он должен был быть закрытым и проприетарным[15]. Причина проста: Mac OS X была продуктом, который приносил Apple прибыль. В эру iPhone компания начала публиковать бесплатные обновления программного обеспечения, но во времена, о которых идет речь, операционная система Macintosh в Соединенных Штатах стоила 129 долларов для одного компьютера{13}. Когда мы продумывали нашу стратегию разработки веб-браузера, руководство предпочитало не «свободное, как свобода слова» и не «бесплатное, как бесплатное пиво» ПО, а «хорошо спрятанное, как деньги».

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

Дон обожал занудствовать по поводу деталей лицензий свободного ПО. За время работы в Netscape и Eazel он подробно изучил эту тему и любил чесать языком, обсуждая достоинства, недостатки и положения различных лицензий. Он явно получал удовольствие, объясняя хитросплетения стандартной общественной лицензии ограниченного применения исходного кода Konqueror. Эти положения гласили, что если мы включаем Konqueror в «кулинарную книгу» Macintosh как отдельную главу, используя его код только с помощью перекрестных ссылок, и открыто публикуем любые изменения, которые делаем, чтобы рецепт Konqueror «получался вкусным» на Macintosh, мы работаем в соответствии с лицензией свободного программного обеспечения Столлмана.

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

Я был где-то посередине.

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

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

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

Представим, что миллионы строк кода, которые составляют операционные системы Linux и Mac, — это большие кулинарные книги, написанные разными авторами. Иногда представленные в них рецепты пересекаются, но отдельные блюда отличаются. В книге рецептов Mac браузера нет. В разделе KDE кулинарной книги Linux он есть, в главе под названием Konqueror. Наш план состоял в том, чтобы выдернуть эту главу, уничтожить то, что останется от KDE и Linux, и добавить страницы Konqueror в кулинарную книгу Mac. Все это вело к одной совершенно очевидной проблеме. Таким образом мы уничтожим все перекрестные ссылки, связывающие Konqueror с другими частями кулинарной книги, которую мы планировали выкинуть. Не будет больше никакого рецепта голландского соуса на с. 123.

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

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

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

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

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