Творческий отбор. Как создавались лучшие продукты Apple во времена Стива Джобса - Кен Косиенда
Шрифт:
Интервал:
Закладка:
Исправление ошибок, которые не позволяли просматривать сайты и не давали программе корректно работать, занимало много времени, но, принимая во внимание указание Стива ускорить браузер, мы постоянно размышляли о том, как это сделать.
Дон был тем, кто придумал, как мы можем заставить код работать быстрее. Однажды, через месяц или два после встречи с черным прямоугольником, он позвал меня к себе в кабинет и попросил написать тестовую программу, чтобы измерить скорость браузера. Он задумал автоматизированный инструмент, который будет запускать наше приложение и отдавать ему команду загрузить несколько страниц, одну за другой, в быстрой последовательности. В течение следующих нескольких дней я писал этот код. Я назвал программу «Тест загрузки страницы» (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}. (Выделение автора.)
Оптимизация — это процесс, когда программисты пытаются заставить код работать быстрее.
