Длинные имена переменных. Я не сторонник венгерской нотации, но предпочитаю использовать для описаний реальные английские фразы (кроме переменных цикла, там и так все ясно). По возможности, чем больше в них слов, тем лучше.
Сейбел: А что насчет организации кода? В конце концов, организация кода является линейной, но программы по своей сути нелинейны. Вы пишете сверху вниз или снизу вверх?
Завински: Обычно я располагаю элементы нижнего уровня в верхней части файла и стараюсь придерживаться этого порядка. Также в самое начало файла я обычно помещаю то, что нужно для API: высокоуровневые точки входа этого файла, описание данного модуля и так далее. В объектных языках все это делает за вас язык программирования. А с Си приходится больше действовать самостоятельно. На Си я стараюсь, чтобы для каждого .c-файла был соответствующий .h-файл, который содержит все внешние объявления. Все, что не экспортируется из .h-файла, является статическим. Бывает, я возвращаюсь и думаю: «Стоп, мне надо вызвать вот это», — и вношу соответствующее изменение. Но это делается намеренно, а не просто случайно.
Сейбел: Вы помещаете элементы нижнего уровня в начало файла. А код пишете так же? Начиная снизу?
Завински: Не всегда. Иногда я начинаю сверху, иногда снизу, когда как. Иногда я знаю, какие строительные блоки мне понадобятся, и сначала собираю именно их. А иногда сначала вижу решение только в общих чертах и лишь потом начинаю углубляться в детали. Бывает и так, итак.
Сейбел: Предположим, чисто теоретически, что вы собираетесь вернуться к программированию и набираете команду разработчиков. Как вы организуете их работу?
Завински: Думаю, нужно разбить всех на группы, максимум по три-четыре человека, которые будут работать в тесном ежедневном сотрудничестве. Этот вариант отлично масштабируется. Допустим, есть проект, который можно разделить на двадцать пять реально изолированных модулей. Значит, у вас может быть двадцать пять небольших команд — хотя это уже многовато. Скажем, десять команд. Пока они могут координировать работу друг с другом, не думаю, что здесь так уж много ограничений для роста. Просто постепенно это начинает походить скорее на несколько проектов, чем на один.
Сейбел: Итак, у вас несколько команд максимум из четырех человек каждая. Как вы будете координировать их действия? С помощью главного архитектора, который будет управлять зависимостями и выступать посредником между этими командами?
Завински: Здесь требуется согласовать интерфейс между модулями. Для того чтобы такой модульный подход работал, интерфейс между модулями должен быть простым и понятным. Тогда есть надежда, что согласование интерфейса пройдет без лишних воплей и будет проще выполнять обязательства по модулям. Думаю, лучший способ добиться нормального взаимодействия между модулями — сделать это взаимодействие максимально простым. В этом случае будет меньше возможностей для ошибок.
А сам процесс разделения на модули целиком зависит от проекта. Для некоторых типов веб-приложений первая ваша команда будет работать над пользовательским интерфейсом, вторая — над базой данных, третья — над кодом, выполняемым на сервере, четвертая — над кодом, который выполняется на клиентской машине. То же самое для настольного приложения. Форматы файлов, графический интерфейс пользователя, базовая структура команд.
Сейбел: Как вы распознаете таланты?
Завински: Даже не знаю. Я никогда не был тем, кто принимает людей на работу. А если и участвовал в собеседованиях, то мне всегда казалось, что у меня нет никаких идей по этому поводу. После собеседования я мог сказать, смогу или нет работать с этим человеком, но сказать, хороший это работник или нет, всего лишь поговорив с ним, я не мог. Мне всегда казалось, что это трудно сделать.
Сейбел: А если работник плохой? Есть ли надежный способ определить это?
Завински: Когда как. Например, я всегда старался избегать ярых сторонников шаблонов C++. Возможно, зря. Может быть, в том контексте, где они использовались, это было хорошим решением. Что касается тех, с кем я работал, умение отстаивать свою позицию очень ценилось, потому что все мы были большими любителями поспорить. В той обстановке это сильно помогало. Разумеется, на способность программировать это никак не влияет. Все это из области межличностных отношений.
Сейбел: А в другой команде это умение может оказаться очень вредным.
Завински: Само собой.
Сейбел: Складывается впечатление, что в Netscape вы, ребята, разделили все так, что разные люди владели разными частями системы. Одни считают, что это очень важно. Другие полагают, что для команды предпочтительнее коллективно владеть кодом. Что вы об этом думаете?