Творческий отбор

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

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

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

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

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

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

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

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

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

* * *