разработчиков.

Сейбел: И вы, конечно, не знали о скором появлении двух разновидностей Emacs[14].

Завински: Разумеется. Но и без того уже были две версии Emacs - 18 и 19. Так или иначе, проблема совместимости все равно бы возникла. Оглядываясь назад, я понимаю, что если бы осознавал последствия внесенных мной изменений, то сделал бы все по-другому. Или потратил бы больше времени на то, чтобы старый вариант тоже работал. Как-то так.

Сейбел: Вы уже упоминали о написании легко читаемого кода, что непосредственно касается сопровождения. Так что же делает код легко читаемым?

Завински: Конечно же комментарии. Запись предположений и того, что код делает. Если речь идет о создании структуры данных, то описание ее устройства. Я много раз убеждался, что это полезно. Это особенно полезно при написании кода на Perl, где все обстоит примерно так: это хеш-таблица, а значения представляют собой ссылки на списки, поскольку структуры данных в Perl - такая вот ерунда. Нужно ли использовать стрелку вправо (->), чтобы добраться до этого? Думаю, такие примеры не помешают.

Я всегда советовал писать больше комментариев, но меня раздражает, когда комментарий представляет собой перефразированное имя функции. Функция называется pushstack (добавить элемент в стек), а комментарий - “добавление элемента в стек”. Большое спасибо.

В комментарии можно сказать то, что неочевидно из кода. Иначе зачем он нужен? Это должно быть высокоуровневое или низкоуровневое описание в зависимости от того, что важнее. Иногда самое важное - для чего вообще предназначен данный элемент. Зачем я его использовал? А иногда самое важное - диапазон допустимых входных значений.

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

Сейбел: А что насчет организации кода? В конце концов, организация кода является линейной, но программы по своей сути нелинейны. Вы пишете сверху вниз или снизу вверх?

Завински: Обычно я располагаю элементы нижнего уровня в верхней части файла и стараюсь придерживаться этого порядка. Также в самое начало файла я обычно помещаю то, что нужно для API: высокоуровневые точки входа этого файла, описание данного модуля и так далее. В объектных языках все это делает за вас язык программирования. А с Си приходится больше действовать самостоятельно. На Си я стараюсь, чтобы для каждого .c-файла был соответствующий .h-файл, который содержит все внешние объявления. Все, что не экспортируется из .h-файла, является статическим. Бывает, я возвращаюсь и думаю: “Стоп, мне надо вызвать вот это”, - и вношу соответствующее изменение. Но это делается намеренно, а не просто случайно.

Сейбел: Вы помещаете элементы нижнего уровня в начало файла. А код пишете так же? Начиная снизу?

Завински: Не всегда. Иногда я начинаю сверху, иногда снизу, когда как. Иногда я знаю, какие строительные блоки мне понадобятся, и сначала собираю именно их. А иногда сначала вижу решение только в общих чертах и лишь потом начинаю углубляться в детали. Бывает и так, итак.

Сейбел: Предположим, чисто теоретически, что вы собираетесь вернуться к программированию и набираете команду разработчиков. Как вы организуете их работу?

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

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

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

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

Сейбел: Как вы распознаете таланты?

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

Сейбел: А если работник плохой? Есть ли надежный способ определить это?

Завински: Когда как. Например, я всегда старался избегать ярых сторонников шаблонов C++. Возможно, зря. Может быть, в том контексте, где они использовались, это было хорошим решением. Что касается тех, с кем я работал, умение отстаивать свою позицию очень ценилось, потому что все мы были большими любителями поспорить. В той обстановке это сильно помогало. Разумеется, на способность программировать это никак не влияет. Все это из области межличностных отношений.

Сейбел: А в другой команде это умение может оказаться очень вредным.

Завински: Само собой.

Сейбел: Складывается впечатление, что в Netscape вы, ребята, разделили все так, что разные люди владели разными частями системы. Одни считают, что это очень важно. Другие полагают, что для команды предпочтительнее коллективно владеть кодом. Что вы об этом думаете?

Завински: Со мной бывало и так, и так. Оба подхода имеют свои достоинства. Не думаю, что идея коллективного владения кодом так уж практична, поскольку кода бывает слишком много. Людям нужна специализация, иногда необходимы эксперты в конкретных вопросах. Обычно так и получается. Всегда оказывается, что есть код, с которым ты знаком лучше других, так уж вышло, что ты работал над этим модулем больше, чем кто-либо еще. Или оказывается, что какие-то части системы дороги тебе больше всего. Конечно же, хорошо, когда кто-то еще знаком с твоим кодом, если только ты не собираешься поддерживать свою часть системы вечно. Так или иначе, приходится кому-то доверить свой код. Хорошо, когда знание распространяется. Но также хорошо, когда есть кого винить. Если за что-то отвечают сразу все, значит, ответственного нет.

Сейбел: Вы когда-либо были руководителем?

Завински: Не совсем. Когда я работал над Emacs в Lucid, в Lucid Emacs было много модулей, написанных другими ребятами. Формально они на меня не работали, но в каком-то смысле приходилось руководить. Многим из них явно не хватало опыта, они просто делали то, что хотели, а мои указания сводились к следующему: “Так, мне нужно вот это, но вначале мне нужно вот это и это и отсюда вот это”.

Сейбел: И вы давали им свободу действий? Говорили им, что вам нужно А, Б и В, а они уже сами решали, как это сделать?

Завински: Да. Когда мне нужно решить, включать данный модуль в конечный продукт или нет, я формулирую требования к нему. Главное, чтобы эта чертова штука работала. И я мог дать им совет: “Думаю, у вас будет больше шансов, если вы поступите так, а не иначе”. Но я хотел: 1)