Кодеры за работой

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

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

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

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

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

Завински:

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

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

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

Сейбел:

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

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

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

Завински:

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

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

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

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

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