Текст книги "Кодеры за работой. Размышления о ремесле программиста"
Автор книги: Питер Сейбел
сообщить о нарушении
Текущая страница: 6 (всего у книги 41 страниц) [доступный отрывок для чтения: 15 страниц]
Сейбел: Вы читаете код ради собственного удовольствия или только тогда, когда это нужно вам по работе?
Фицпатрик: Иногда читаю. Я беру исходный код Android просто так, без видимой причины. То же самое с Chrome: когда его код стал открытым, я сделал зеркало репозитория и стал изучать код. И тоже самое сделал с Firefox и с Open Office. Пользуешься какой-то программой, а потом получаешь доступ к ее исходному коду и можешь на него взглянуть.
Сейбел: У таких программ объем кода довольно велик. Читая код просто ради интереса, как глубоко вы вникаете?
Фицпатрик: Как правило, я просто делаю конвейер из find в less («найти среди значений меньше, чем») и стараюсь понять структуру каталогов. Потом что-то привлекает мое внимание или я нахожу что-то, чего не понимаю. Я беру файл наугад, чтобы получить общее впечатление от него. Затем случайным образом прыгаю по коду, пока не надоест, и тогда снова беру произвольный кусок и начинаю разбираться с ним.
Я не раз выполнял сборку проекта, одновременно читая его код, поскольку эти задачи вполне можно выполнять параллельно, особенно если сборка проекта оказывается сложной. Собрав в конце концов проект, я могу поиграть с кодом, если захочу.
Сейбел: Значит, когда вы читаете хороший код, то он соответствует уже известным вам паттернам или вы открываете для себя новые? Но не всякий код хорош. Каковы первые признаки плохого кода?
Фицпатрик: Ну, я стал достаточно придирчивым, поработав в Google с его очень строгими стандартами оформления кода для всех языков. Для наших шести или семи основных языков есть очень четкие стандарты оформления кода, в которых сказано: «Вот так мы располагаем код. Так называем переменные. Так расставляем пробелы и отступы, используем такие-то паттерны и соглашения, так объявляем статические поля».
Мы стали выкладывать это и в Интернете в качестве справочного руководства для удаленных сотрудников, которые участвуют в наших проектах. Мы хотим иметь строго документированную политику, поэтому не говорим просто: «Нам не нравится, как вы оформляете код».
Сейчас, работая над проектом на Си, первым делом я добавил стандарт оформления кода. Поскольку проект зрелый и в нем участвуют многие, у них уже есть стандарты кодирования. Они даже не всегда оформляются в письменном виде – программист просто должен соблюдать оформление уже написанного кода. Ему, может быть, не по душе стандарт расположения фигурных скобок, но к черту все это, гораздо важнее иметь последовательное оформление кода в файле и в проекте целиком, чем оформлять код любимым для тебя способом.
Сейбел: Вам приходилось заниматься парным программированием?
Фицпатрик: Думаю, это довольно занятно и полезно во многих случаях. Иногда надо просто подумать и побыть одному. Не думаю, что это полезно всегда, но это однозначно весело.
Я запускаю слишком много проектов. И завершаю их, так как иначе чувствую за собой вину, но я определенно слишком часто переключаюсь с одного на другое и слишком распыляю силы. Вот почему мне нужно парное программирование – оно заставляет меня сидеть на одном месте целых три часа, или два, или хотя бы только час, и работать над одной задачей с другим человеком, и при этом я не скучаю. Если приходится заниматься скучным патчем, мне говорят: «Да ладно, нам же нужно это сделать», – и мы доводим это дело до конца.
Я люблю работать один, но в этом случае я постоянно перепрыгиваю между задачами. Я всегда беру в самолет запасные батареи для ноутбука, на котором есть полная среда разработки и локальный веб-сервер. Я запускаю веб-браузер и что-нибудь тестирую. При этом в браузере открываю дополнительные вкладки и набираю «reddig» или «lwn» – сайты, которые читаю постоянно. Автозаполнение, жму Enter – и получаю сообщение об ошибке. Я делаю так несколько раз в минуту. Черт! Поступаю ли я так же на работе? Посещаю ли я эти сайты постоянно, не задумываясь? Это ужасно. У одного моего приятеля правила для iptables[27]27
iptables – утилита командной строки, стандартный интерфейс управления работой брандмауэра netfilter для ядер Linux версий 2.4 и 2.6. – Прим. науч. ред.
[Закрыть] настроены таким образом, что при попытке подключиться к определенным IP-адресам в определенное время дня происходит перенаправление на страницу с надписью «Работать надо!». Я до этого еще не дошел, но, видимо, и мне уже нужно нечто подобное.
Сейбел: Что вы думаете о владении кодом? Важно ли человеку владеть кодом индивидуально или предпочтительнее – командой?
Фицпатрик: Не думаю, что у кода должен быть владелец. И, по-моему, никто на самом деле не думает о пользе владения. Вот как это устроено в Google: есть одно огромное дерево с общим корнем и единая система сборки всего кода. Поэтому каждый может взять и поменять что угодно. Но существуют ревизии кода (code review), и у папок есть владельцы, как минимум двое у каждой, на случай, если один из них уволится или уйдет в отпуск.
Для сохранения кода в репозитории требуется выполнение трех условий. Нужно, чтобы кто-то посмотрел код и сказал, что он выглядит нормально. Нужно иметь специальный сертификат удобочитаемости (readability) по данному языку, который доказывает, что ты знаком с его стандартом. Еще нужно одобрение одного из владельцев этой папки. Так что если ты владелец папки и имеешь такой сертификат по этому языку программирования, остается лишь найти кого-то, кто скажет: «Да, выглядит хорошо». Это достаточно хорошая система, поскольку в этом случае получается как минимум двое владельцев, а может быть, и двадцать или тридцать. Если немного поработать с базой кода, кто-нибудь добавит тебя в число владельцев. Мне кажется, это отличная система.
Сейбел: Давайте вернемся немного назад. Как начинался Живой Журнал?
Фицпатрик: Мы просто возились с друзьями со всякой ерундой, которой нам хотелось бы заниматься и которая казалась нам забавной. Комментарии в Живом Журнале были практически шуткой. Я проверял свою страницу, перед тем как идти на занятия. Мы только что придумали френдленту, и я увидел, что мой приятель написал какую-то глупость. Мне захотелось его подколоть, но я не мог ему ответить! И я пошел на пары, но во время занятий постоянно думал: «Как сделать систему ответов?» Я думал о существующей схеме и о возможностях ее изменения. Во время двухчасового перерыва между занятиями я добавил систему комментариев, написал что-то хитроумно-ехидное и пошел на урок. Когда я вернулся, парень ответил: «Какого хрена? Теперь можно комментировать?!»
Все в Живом Журнале было чем-то вроде игры. Все, что связано с безопасностью – вроде постов только для друзей и закрытых постов, – появилось после того, как приятель описал, как пошел на вечеринку, а на следующий день проснулся пьяный в канаве. Его родители прочли это и подняли шум: «Как? Ты пьешь?» Вот он и предложил: «Брэд, надо сделать возможность блокировать чтение этого дерьма». А я ему: «Будет сделано!» У нас уже была система френдов (друзей), и мы сделали так, чтобы некоторые сообщения были доступны только друзьям, – оставалось не добавлять в друзья своих родителей, и все.
Сейбел: На заре Живого Журнала ваша жизнь, видимо, состояла из бессонных ночей, когда засыпаешь под утро после многочасовой работы. Насколько это обязательный атрибут жизни программиста?
Фицпатрик: По-моему, ночь – просто наименее напряженное время суток. Днем все время что-то происходит: то тебе хочется перекусить, то идешь на занятия, то тебе кто-то звонит. Тебя всегда что-то прерывает. Я не могу расслабиться. Если я занимаюсь работой за два часа до какого-нибудь собрания, то эти два часа не такие продуктивные, какими могли бы быть в тот день, когда собрание назначено на утро или его вообще нет. Если я знаю, что меня не будут отвлекать, то гораздо меньше беспокоюсь.
Ночью я чувствую, что это мое время, потому что все остальные спят. Нет шума, никто не отвлекает, я могу делать что угодно. Я до сих пор засиживаюсь допоздна – вот, например, в эти выходные я немало поработал над разными вещами. Но потом несколько дней хожу сонный. В колледже мне часто приходилось работать по ночам, потому что я занимался одновременно несколькими проектами, включая Живой Журнал, а это можно было делать только ночью. Ну, и обслуживать наш сервер тоже приходилось ночью. А если на дворе лето, то почему бы так не работать? Раз утром не надо идти на занятия или куда-нибудь еще, то можно сидеть по ночам.
Сейбел: Поговорим о рабочем времени и интенсивности работы. Не сомневаюсь, что вы работали по 80, 120, 150 часов в неделю. При каких обстоятельствах это необходимо, а при каких – просто говорит о желании самоутвердиться?
Фицпатрик: Не уверен, что в моем случае это было необходимо или говорило о желании самоутвердиться. Мне было интересно все это, и это было именно то, что я хотел делать. Периодически что-то ломалось, но даже если ничего не ломалось, я продолжил этим заниматься, потому что постоянно работал над новыми возможностями, которые очень хотел реализовать.
Сейбел: Бывали ситуации, когда вам действительно приходилось оценивать необходимое время для реализации чего-то?
Фицпатрик: Да, когда я попал в компанию Six Apart. Это был мой первый подобный опыт, и произошло это три с половиной года назад. Мы начали заниматься переносом данных по просьбе одного из клиентов. Нужно было добавить поддержку этого в код, протестировать все и отправить заказчику. Мне было ужасно не по себе. Мне и сейчас не по себе, потому что я постоянно забываю о поправке на отвлечения и о том, что не могу избавиться от поддержки десятка уже существующих проектов.
Думаю, постепенно я научился лучше оценивать время, но, слава богу, меня не просят об этом слишком часто. И сейчас, когда на носу дедлайн, я думаю: «Ура! Дедлайн!», – меня это так заводит, что адреналин так и хлещет, и я работаю и заканчиваю эту чертову работу. На самом деле, в Google дедлайнов нет. А бывает примерно так: «Как насчет того, чтобы это запустить? Есть такое ощущение?» Реальные сроки сдачи проектов ставятся редко и главным образом в такой форме: «Хорошо бы запустить это к такому-то числу», – и все прилагают для этого максимум усилий. Но если не заканчиваешь что-то в срок, то подводишь других. Большинство же проектов, над которыми я работаю, реализуются по принципу «Когда сделаем, тогда и сделаем».
Сейбел: Наняв программистов для Живого Журнала, вы руководили ими?
Фицпатрик: Я предполагал, что никому из них руководство не нужно, что все они будут работать самостоятельно, как я. Это был отличный опыт в управлении персоналом. Я понял, что есть те, кто делает только то, что поручено, без какого-либо стремления к совершенству. Они работают по принципу: «Сделано. Следующее задание?» – или ничего не говорят, а просто шарят по Интернету. Так что у меня было несколько таких неприятных случаев. Но, кажется, через год-другой я понял, что все люди разные.
Есть пуристы: они городят абстракцию на абстракции поверх абстракции. Они делают все страшно медленно и очень строги в вопросе оформления кода. Они считают себя мастерами программирования, а я доказываю им, что их код не работает, что он неэффективен и непохож на любой другой код, с которым взаимодействует.
Сейбел: Вы нашли способ извлекать пользу из работы таких людей?
Фицпатрик: С одним парнем я испробовал с десяток различных способов. Он был лет на десять меня старше, точно не знаю, я никогда его об этом не спрашивал – боялся, что задавать подобные вопросы незаконно. Но у меня было ощущение, что ему не хочется работать на какого-то паршивца. Мне тогда было 22. С этим парнем мы так и не сработались, и это был единственный человек, которого я уволил.
К остальным я в конце концов нашел подход и выяснил, что их мотивирует. У одного отлично получалось делать «заплатки» и создавать прототипы. Он писал на Perl как сисадмин. Он мог соединять различные вещи, писать скрипты командной оболочки, писать действительно ужасный код на Perl и на Си, но почему-то все это у него работало. Мы поражались: «Черт возьми, как ты умудрился изучить все это и как тебе удалось увязать все эти компоненты друг с другом?»
Мы устанавливали голосовой сервис для Живого Журнала: записываешь что-то и постишь в Живой Журнал. Было очень много динамичного. Адская работа. А ему нравилось. Он разобрался со всем и заставил это работать. Позднее мы полностью все переписали, но выяснили, как это работает, именно благодаря ему. Он набросал интерфейс, который мы потом доводили до ума. Как только я понял, что в этом его призвание, мы прекрасно сработались.
Сейбел: Вы нанимали людей для своей компании. Предполагаю, что и в Google вам тоже приходится этим заниматься. Как вы распознаете в человеке отличного программиста?
Фицпатрик: Обычно я ищу тех, кто много чего написал по собственной инициативе, а не потому, что ему сказали это сделать. Я не имею в виду учебные задания и проекты от предыдущего работодателя. Я о тех, кто чем-то увлечен, кто выполнял сторонние проекты. Как он их сопровождал и насколько серьезно к ним подходил? Вдруг клепал что-то на скорую руку и забывал о проекте?
Сейбел: У вас есть любимые вопросы на собеседовании?
Фицпатрик: Один из вопросов, который я задавал несколько раз, – это вопрос из моего теста на школьном факультативном курсе по программированию: даны два десятичных числа в виде строки произвольной длины, нужно их перемножить. Есть много способов решения этой задачи. Если человек силен в математике – в отличие от меня, – он может найти какой-нибудь изящный и эффективный способ решения. В худшем случае можно создать класс, который выполняет серию сложений.
Я говорю им с самого начала: «Не волнуйтесь. Вам не нужно сделать это предельно эффективно. Сделайте хотя бы как-нибудь». Некоторые нервничают, не зная с чего начать. Это плохой признак. В худшем случае можно реализовать алгоритм, который применялся в начальной школе.
Я действительно в начальной школе написал программу, чтобы она выполняла за меня деление и умножение в столбик, показывая свою работу. Включая все шаги и зачеркивание. Потом мы взяли задачи, примерно по десять на страницу, я вбил их все в компьютер, а затем переписал решения от руки. То же самое я проделал на химии для нахождения орбиталей электронов. Я тогда кое-что понял: даже при написании такой жульнической программы учишься, потому что для этого нужно действительно глубоко понять задачу.
Сейбел: Думаете, это годится для всех? То есть вместо того чтобы обучать детей делению в столбик, будем учить их программированию: «А теперь напишите программу для деления в столбик». И написав эту программу, они заодно освоят деление. Или это сработает, только если есть природная склонность к этому?
Фицпатрик: Для меня это сработало. Часто бывает, что кто-то учит тебя чему-то, и ты говоришь: «Да-да, понятно». И обманываешь себя. Но как только придется заняться этим на практике, понять все граничные случаи, придется на самом деле освоить этот предмет. Но я не знаю, подходит ли это всем.
Сейбел: Говорят, в Google, как и в Microsoft, на собеседованиях задаются вопросы в виде головоломок.
Фицпатрик: Кажется, такие вопросы запрещены или, по крайней мере, не приветствуются. Может, кто-то и задает их, но, скорее всего, в общем случае они не приветствуются.
Сейбел: А вас о чем спрашивали на собеседовании?
Фицпатрик: Например, был вопрос: представьте, что у вас есть несколько компьютеров, подключенных через коммутатор, которые занимают целую стойку. Напишите алгоритм, чтобы каждая машина в стойке знала статус любой другой машины – включена та или нет. То есть задача в целом сводилась к определению присутствия. Это было серьезным ограничением. В основном они описали схему работы сети Ethernet: вы можете послать широковещательное сообщение всем или посылать сообщение по конкретному МАС-адресу. Надо было проанализировать множество различных стратегий для минимизации полосы пропускания и времени определения того, что один из компьютеров вырубился. Это была интересная задача.
Сейбел: Какую из найденных вами ошибкок вы считаете самой серьезной?
Фицпатрик: Я стараюсь их не запоминать. Ненавижу, когда предположения столь сильно расходятся с реальностью. Недавно (это явно не пример самой плохой ошибки в моей жизни) я потратил полтора часа на отладку, потому что писал в один файл, а читал другой – с таким же точно именем, только путь к нему был на один элемент короче. Я продолжал перезапускать этот огромный MapReduce, наблюдая за выходными данными, и наконец запустил GDB для пошаговой отладки. «Какого хрена? – говорил я себе. – Ничего не меняется!» В конце концов я глянул на пути и воскликнул: «Бог ты мой!», – не знаю, как я мог потратить на это полтора часа. Я был так одержим, что даже не вернулся, чтобы проверить корректность командной строки.
И так бывает нередко. Мы постоянно сталкиваемся с подобными вещами в Perl, например, когда переменная $_ не определена в лексической области видимости. Возишься с $_ в сортировке, а на самом деле используешь значение, определенное где-то очень далеко. Эта ошибка доставала нас постоянно, создавая немало проблем. Когда мы наконец выяснили в чем дело, я провел аудит всего нашего кода, и мы ввели правило «никогда не делай этого».
Сейбел: Какие инструменты вы используете для отладки? Отладчики? Операторы print In? Еще что-то?
Фицпатрик: Я использую операторы print In, если среда позволяет это. Если в среде есть хорошие отладчики, использую отладчик. GDB хорошо поддерживается в Google и порой просто незаменим. Стараюсь использовать его пореже. Я в нем не такой уж большой специалист, но могу осмотреться и представить положение вещей в целом. Если приходится забираться в дебри, то я всегда могу как-нибудь выпутаться. Я люблю утилиту strace, просто не представляю жизни без нее. Если я не знаю, что делает моя или чья-то программа, то запускаю ее под strace и вижу, что конкретно в ней происходит. Если бы мне пришлось выбрать только одну утилиту, я бы выбрал именно ее. Все инструменты, вроде Valgrind и Callgrind, очень хороши.
Но в последнее время, если происходит что-то странное, я поступаю так: «Хорошо, вот эта функция слишком велика; давайте разобьем ее на части поменьше и напишем модульные тесты, чтобы проверить работоспособность каждой части независимо и найти место, в котором мои предположения оказались ошибочными, а не втыкать операторы print In где попало».
Бывает позже, в процессе рефакторинга, я начинаю думать о коде больше, и проблема становится очевидной. Тогда я могу вернуться к той огромной уродливой функции и исправить ее, но половину исправлений я уже внес; я могу продолжить, чтобы облегчить работу того, кто будет поддерживать код после меня.
Сейбел: Как вы используете инварианты в своем коде? Одни программисты добавляют специальные утверждения, другие добавляют инварианты на каждом шагу, что позволяет им проверить формальные свойства своей программы. Между этими двумя крайностями много промежуточных вариантов.
Фицпатрик: Я не сторонник чисто формального подхода. Мое основное правило: если некорректные данные могут приходить от конечного пользователя, то это не ошибка времени выполнения. Но если взаимодействие осуществляется между двумя кусками моего кода, я прерываю выполнение настолько жестко, насколько это возможно, – чем раньше упадет программа, тем лучше.
Я стараюсь мыслить главным образом в терминах предусловий и проверяю данные в конструкторе и в начале функции. При этом, если возможно, я использую условные проверки, чтобы компилятор мог их впоследствии выкинуть. Тут есть много подходов, я недостаточно подкован, чтобы говорить о том, какой из них самый верный. Есть языки, в которых все это является частью самого языка. Но почти во всех языках, которыми я пользуюсь, это оставлено на усмотрение программиста.
Сейбел: Вы писали когда-то, что оптимизация – ваш любимый процесс в программировании. Это все еще так?
Фицпатрик: Я люблю оптимизацию за то, что без нее можно обойтись. Вы делаете это, когда все уже работает, а это самое важное. Дальше вы либо экономите деньги, либо устраиваете соревнования по гольфу на языке Perl[28]28
Code golf – состязания в программировании: побеждает программа с минимальным количеством знаков, решающая данную задачу. Понятие пошло именно из языка Perl (Perl Golf Context), но потом распространилось и на другие языки программирования. – Прим. науч.ред.
[Закрыть]: как сделать этот код короче или значительно быстрее? Нам надо было обнаружить наиболее часто используемые участки кода в Живом Журнале, и я устроил небольшие состязания: «Вот код. Вот тестовая программа. Сделайте код максимально быстрым». И выслал парсер заголовка балансировщика нагрузки. Мы писали безумные регулярные выражения, без поиска с возвратом, пытаясь захватить что-то самым эффективным способом. Мы соревновались друг с другом, получая все более эффективные решения. Но на следующий день пришел один парень. Он написал все на C++ с применением XS[29]29
XS – интерфейс, определяющий формат файлов для взаимодействия кода на Си/С++ и кода на Perl. – Прим. науч.ред.
[Закрыть] и говорит: «Я выиграл».
Сейбел: Сегодня обратная сторона этого в том, что...
Фицпатрик: Время программиста дороже подобной ерунды? Да, это верно, но только если компьютеров мало. Если количество компьютеров возрастает, время программиста начинает стоит меньше, чем компьютеры, на которых установлено ПО. В этом случае стоит писать на Си, и профилировать свой код, и исправлять компилятор, и платить людям за работу на GCC для ускорения компиляции.
Сейбел: Но даже Google использует C++, а не ассемблер, так что есть какая-то точка, в которой попытка выжать максимальную производительность становится невыгодной. Или есть теория, что хороший компилятор C++ генерирует лучший код, чем все программисты на ассемблере, которых еще поискать?
Фицпатрик: Мы все еще пишем кое-что на ассемблере, но крайне редко. Мы профилируем огромное количество кода, и бывают случаи, когда требуется переписать код с Perl на Си, а потом с Си на ассемблер. Но даже для платформы х86 есть различные варианты этой платформы. Вы действительно хотите писать разный ассемблерный код для каждого варианта платформы x86? Этот процессор использует SSE 2, а этот только SSE 3.1. Пусть лучше всем этим занимается компилятор.
Сейбел: Вы учились программированию по руководству программиста еще в детстве. Есть ли книги, которые вы настоятельно рекомендуете начинающим или всем программистам?
Фицпатрик: Если говорить о Perl, то даже программисту, который знает его хорошо, я бы посоветовал книгу Марка Джейсона Доминуса (MJD) «Higher-Order Perl» (Высокоуровневый Perl). Книга действительно отличная, автор начинает с простых вещей, и вы думаете: «Знаю, знаю, что такое замыкания», – но он потихоньку долбает ваш мозг, и к концу книги он просто готов взорваться. И хотя теоретически я знал все это, но увидев столь экстремальный подход, изменил свое мнение. Я рекомендовал эту книгу многим своим друзьям, им она тоже взорвала мозг. В целом, я бы советовал читать книги, которые заставляют думать по-новому. Это просто самый свежий пример, который мне вспомнился.
Сейбел: Вижу, у вас есть книга «The Art of Computer Programming»[30]30
Дональд Э. Кнут «Искусство программирования». – Вильямc, 2008.
[Закрыть], но она не выглядит слишком потрепанной. Вы много из нее прочли?
Фицпатрик: Я не трогал ее около пяти лет, да, не меньше. Иногда я брался за нее и читал отдельные куски ради удовольствия. Но к тому времени, как я купил эту книгу, я уже знал многое из того, что в ней описано, по университетским занятиям. Так что от нее было бы больше пользы раньше. Но до появления Интернета я ничего о ней не знал.
Сейбел: Как вы считаете, в каком объеме программист должен знать математику? Чтобы прочесть и как следует понять книги Кнута, нужно иметь приличную математическую подготовку. Но необходимо ли это сегодня программисту?
Фицпатрик: Ему не нужно так уж много математики. Для большинства программистов в ежедневной работе гораздо важнее статистика. Если рисуешь всякие графики, то математика, само собой, нужна, но большинство программистов в основном разрабатывают разные корпоративные приложения на Java и всякую ерунду для Сети. Очень помогает знание логики, ну и статистика тоже очень полезна.
Сейбел: Вы явно все еще получаете удовольствие от программирования. Но если почитать ваши записи в Живом Журнале времен учебы в колледже, создается впечатление, что вы порой уставали и начинали ненавидеть компьютеры.
Фицпатрик: О да, я всегда ненавидел компьютеры. Похоже, тут уже давно нет никакого прогресса. Кажется, что компьютеры все медленнее работают, все чаще падают и глючат, чем раньше. Но поскольку я оптимист, то верю, что все изменится к лучшему. Наверное, десять лет назад я получал больше удовольствия от работы, чем сегодня. Может быть, десять лет назад мой компьютер работал быстрее; мне кажется, что тогда он работал лучше. Компьютеры стали быстрее, но в то же время программы стали больше глючить и работать медленнее.
Сейбел: Как думаете, почему?
Фицпатрик: Не знаю. Может, понизилась планка? Или, раз компьютеры стали быстрее, можно забыть об эффективности – или совсем не думать о том, что делаешь? У меня нет ответа. Может быть, всё вышесказанное в совокупности. А может, просто появилось такое множество слоев абстракции, что люди перестали понимать, что же происходит внутри, а компьютеры стали настолько быстрыми, что скрывают их глупость.
Сейбел: То есть, возможно, программы не настолько быстро работают, как должны бы работать при такой скорости компьютеров. Но ведь десять лет назад вообще не было таких возможностей, какие сегодня предоставляет пользователям тот же Google.
Фицпатрик: Да. Некоторые пишут эффективный код и им пользуются. Я не играю в компьютерные игры, но когда порой наблюдаю за чьей-то игрой, думаю: «Черт, как такое возможно?» Я просто в шоке. Очевидно, что некоторые делают все правильно.
Наверное, в основном я недоволен своими настольными приложениями. Похоже, большинство хорошего, интересного происходит на стороне сервера. А работая на своем компьютере, я все больше разочаровываюсь. Наверняка мой Мак не должен постоянно показывать мне вращающиеся пляжные мячи смерти[31]31
Симптом зависания программ, работающих под управлением MAC OS: курсор превращается во «вращающийся пляжный мяч смерти» (Spinning Beach Balls of Death). – Прим. науч. ред.
[Закрыть].
Сейбел: Не интересует ли вас написание более качественных настольных приложений?
Фицпатрик: Проблема в том, что они никому не нужны. Хочется разрабатывать приложения, которыми будут пользоваться, а сейчас всем нужны веб-приложения. Однажды я потерял ноутбук, и все спрашивали: «Как, ты потерял информацию?» Но на нем не было никакой информации. Это был просто терминал для работы в Сети. А диск был зашифрован, так что я не беспокоился насчет паролей, cookies и всего такого. Мне кажется, люди уже не хотят скачивать программы.
Сейбел: А что вас сильнее мотивирует: то, что ваш продукт используют другие, или просто удовольствие от программирования?
Фицпатрик: Конечно же, есть программы, которые я пишу для себя, и пишу явно в расчете на то, что ею буду пользоваться я один; в этом случае я меньше забочусь насчет патчей и всего такого. Но часто мне хочется работать с другими. Наличие пользователей – ключевой момент для совместной работы. Чем больше пользователей, тем больше ошибок они находят, тем больше сценариев использования. Работать с другими людьми интереснее, особенно в проектах с открытым исходным кодом.
Всегда приятно, когда тебе пишут: «Привет, мы используем твою программу для того-то». Глядя на то, сколько сайтов используют mem-cached, балансировщик нагрузки или еще что-нибудь, я думаю: «Как здорово!» А сколько владельцев порносайтов сообщали мне, что пользуются моей файловой системой! Это о чем-то говорит. Я помогаю порноиндустрии. В Крейгслисте каждый запрос направляется через вебсервер, который использует memcached. Вот так.
Сейбел: Как по-вашему, программисты склонны излишне увлекаться всем новым – языками, инструментами и так далее?
Фицпатрик: Да, возможно. Может быть, тут есть отчаянная надежда, что новая версия вдруг окажется нормальной, что новый язык будет делать все, что нужно. Но так думают и пользователи – они всегда хотят получить новую версию, даже если она хреновее.
Не знаю, отличаются ли статистически программисты от других людей. Новое – значит, лучшее. Далеко не всегда это так, но люди надеются. Они хотят, чтобы было именно так. Помню беседовал как-то со своим дантистом – она вспоминала все новые и новые методы в стоматологии, кажется, за последние лет пять, и была от них просто в восторге.
Сейбел: Искусство программиста сейчас во многом состоит в том, чтобы найти нужные компоненты и понять их ровно настолько, чтобы суметь ими воспользоваться. Что вы об этом думаете?
Фицпатрик: В CPAN[32]32
CPAN (Comprehensive Perl Archive Network – всеобъемлющая сеть архивов Perl) – архив документации и ПО на языке Perl. – Прим. науч.ред.
[Закрыть] есть все. Там 14 парсеров ID3. Выберите один.
Сейбел: Так вот проблема современного разработчика – выбрать одно из 14 решений. Как вы делаете выбор?
Фицпатрик: Запускаем поиск в Google и смотрим, какой из них попадает в начало списка. Какой больше всего нравится людям? И нужно знать людей. Я стал значительно больше участвовать в жизни сообщества открытого исходного кода, посещать все эти конференции, поскольку там я встречаюсь с людьми и понимаю, кто пользуется большим уважением, кто действительно крут.
Потом я смотрю их код: а, помню того парня, он просто потрясающий. Он весел, дружелюбен, привлекателен, внимателен, и он действительно заботится о своем коде. Очень серьезно относится ко всем жалобам на его код. Я могу спокойно пользоваться его кодом, потому что знаю: если найду ошибки, он обязательно их исправит. Или наоборот, какой-нибудь ворчун, который, может, и пишет замечательный код, но постоянно ворчит и не хочет тебя слушать, если ты нашел ошибку или у тебя есть вопрос. Вот и выбираешь таких людей, поддерживающих конкретный проект, которым доверяешь, относишься с уважением.
Сейбел: Можно ли быстро выяснить, подходит тебе что-то или нет?
Фицпатрик: Я просто начинаю. Не включаю это сразу же в свой код, а сперва пишу тестовую программу, которая использует несколько нужных мне функций, чтобы убедиться, что все работает. Или пишу модульный тест только для этой библиотеки и только для тех данных, которые предполагаю использовать вместе с ней. У многих библиотек нет собственных тестов. Но даже если есть, может быть так, что читаешь документацию и не доверяешь тому, что в ней написано, или по ней невозможно понять, что делается. Поэтому я пишу собственные тесты для того, что мне нужно. Поскольку для изучения этой библиотеки мне все равно придется написать пробную программу с ее использованием, я вполне могу начать с модульного теста.
Сейбел: А как насчет инструментов, которыми вы сейчас пользуетесь, – по-прежнему применяете Emacs?
Фицпатрик: Да, я все еще использую Emacs. Правда, не знаю его так хорошо, как хотел бы. Я знаю все горячие клавиши, но сам не настраиваю его. Пользуюсь чужими настройками и почти могу прочесть их. Иногда мне это надоедает, и я думаю: «Пора бы написать кое-что на Elisp[33]33
Elisp, или Emacs Lisp – диалект языка Лисп, используемый в текстовых редакторах GNU Emacs и XEmacs. – Прим. науч. ред.
[Закрыть] для привязки этой штуки к горячей клавише», – но никогда этого не делаю.
