Мы стали выкладывать это и в Интернете в качестве справочного руководства для удаленных сотрудников, которые участвуют в наших проектах. Мы хотим иметь строго документированную политику, поэтому не говорим просто: "Нам не нравится, как вы оформляете код".
Сейчас, работая над проектом на Си, первым делом я добавил стандарт оформления кода. Поскольку проект зрелый и в нем участвуют многие, у них уже есть стандарты кодирования. Они даже не всегда оформляются в письменном виде - программист просто должен соблюдать оформление уже написанного кода. Ему, может быть, не по душе стандарт расположения фигурных скобок, но к черту все это, гораздо важнее иметь последовательное оформление кода в файле и в проекте целиком, чем оформлять код любимым для тебя способом.
Сейбел: Вам приходилось заниматься парным программированием?
Фицпатрик: Думаю, это довольно занятно и полезно во многих случаях. Иногда надо просто подумать и побыть одному. Не думаю, что это полезно всегда, но это однозначно весело.
Я запускаю слишком много проектов. И завершаю их, так как иначе чувствую за собой вину, но я определенно слишком часто переключаюсь с одного на другое и слишком распыляю силы. Вот почему мне нужно парное программирование - оно заставляет меня сидеть на одном месте целых три часа, или два, или хотя бы только час, и работать над одной задачей с другим человеком, и при этом я не скучаю. Если приходится заниматься скучным патчем, мне говорят: "Да ладно, нам же нужно это сделать", - и мы доводим это дело до конца.
Я люблю работать один, но в этом случае я постоянно перепрыгиваю между задачами. Я всегда беру в самолет запасные батареи для ноутбука, на котором есть полная среда разработки и локальный веб-сервер. Я запускаю веб-броузер и что-нибудь тестирую. При этом в броузере открываю дополнительные вкладки и набираю "reddig" или "lwn" - сайты, которые читаю постоянно. Автозаполнение, жму Enter - и получаю сообщение об ошибке. Я делаю так несколько раз в минуту. Черт! Поступаю ли я так же на работе? Посещаю ли я эти сайты постоянно, не задумываясь? Это ужасно. У одного моего приятеля правила для iptables настроены таким образом, что при попытке подключиться к определенным 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 где попало".
Бывает позже, в процессе рефакторинга, я начинаю думать о коде больше, и проблема становится очевидной. Тогда я могу вернуться к той огромной уродливой функции и исправить ее, но половину исправлений я уже внес; я могу продолжить, чтобы облегчить работу того, кто будет поддерживать код после меня.
Сейбел: Как вы используете инварианты в своем коде? Одни программисты добавляют специальные утверждения, другие добавляют инварианты на каждом шагу, что позволяет им проверить формальные свойства своей программы. Между этими двумя крайностями много промежуточных вариантов.
Фицпатрик: Я не сторонник чисто формального подхода. Мое основное правило: если некорректные данные могут приходить от конечного пользователя, то это не ошибка времени выполнения. Но если взаимодействие осуществляется между двумя кусками моего кода, я прерываю выполнение настолько жестко, насколько это возможно, - чем раньше упадет программа, тем лучше.
Я стараюсь мыслить главным образом в терминах предусловий и проверяю данные в конструкторе и в начале функции. При этом, если возможно, я использую условные проверки, чтобы компилятор мог их впоследствии выкинуть. Тут есть много подходов, я недостаточно подкован, чтобы говорить о том, какой из них самый верный. Есть языки, в которых все это является частью самого языка. Но почти во всех языках, которыми я пользуюсь, это оставлено на усмотрение программиста.
Сейбел: Вы писали когда-то, что оптимизация - ваш любимый процесс в программировании. Это все еще так?