Компьютеру нужен двоичный код, а текстовый файл нужен мне. Я брал в свои проекты умных людей, действительно хороших программистов, недавних выпускников, лучших на своем курсе. И давал им, этим молодым специалистам, фронт работ. После этого на планерках они спорили со мной: «Почему вы жалуетесь, что я прописал глобальные переменные здесь, что я делаю то-то и то-то, что вам не нравится моя структура подпрограмм? Программа же работает?»

Их удивлению не было предела, когда я отвечал: «Конечно, программа работает. Вас взяли сюда именно потому, что вы умеете писать работающие программы. Написание программ — чисто ремесленный навык, и у вас он есть. А теперь вам нужно научиться программировать». Некоторые из этих ребят, будучи очень хорошими программистами, в жизни не прочли ни строки чужого кода. Фактически некоторые даже свой код не читали и поэтому не понимали, как сильно он потом менялся за какие-то полгода.

Некоторые начинали бунтовать. Они были абсолютно уверены в своих силах, а я для них был просто замшелый старик. Я и сам когда-то удивлялся: если моя программа работает, какие к ней могут быть претензии? Теперь же я сам объяснял другим: «Работающая программа — не оправдание. Это необходимый минимум. Пора переходить на следующий уровень», — а они только охали в ответ. А потом, поговорив с коллегами, понимали, что в BBN это, по сути, стандарт. Ты не можешь создать что-то новое, не усвоив перед этим основы ремесла.

У меня есть свои предпочтения относительно того, как должны быть организованы мои глобальные переменные и подпрограммы. Как-то раз я ввязался в многодневный спор с одним парнем, который говорил: «Ну посмотрите, все же нормально работает». Он был действительно хорошим программистом, настолько, что мне не хотелось пользоваться служебным положением. Я хотел, чтобы он сам понял, что я не стараюсь таким образом самоутвердиться, и увидел причину, по которой я хотел, чтобы он программировал так, а не иначе. Он просто не понимал, как трудна для понимания программа, в которой только подпрограмма на Си занимает 42 страницы кода.

Сейбел: Ого!

Козелл: Я спорил с ним, потому что сам решительно предпочитаю простые, вызываемые один раз подпрограммы. Единственная цель такой подпрограммы — абстрагировать одну небольшую часть родительской подпрограммы. По-моему, если родительская подпрограмма шокирует своим объемом и сложностью, это верный признак того, что все нужно переделывать. Допустим, у меня есть маленькая подпрограммка, в которой говорится: «Отсортируй таблицу и найди лучший путь», и она вызывается всего один раз. Кто-нибудь оптимизирующий код может сказать: «Это не должно быть подпрограммой. Просто добавь ее в код». Но эту маленькую подпрограммку я могу рассматривать изолированно. Сразу ясно, какие у нее входные данные. Ты видишь алгоритм и можешь быть спокоен, потому, что все понимаешь. Тот парень ненавидел, когда я говорил ему: «Твои подпрограммы слишком сложны. Они занимают много места». Он в таких случаях отвечал: «Все в порядке, потому что я могу сделать это все в одной подпрограмме».

Он сопротивлялся, но в конце концов поступал по-моему. Как-то раз ему нужно было взять большой кусок кода, написанный его предшественником, доработать и встроить в новую версию системы. Он потратил на это почти неделю. Программа того парня настолько вывела его из себя, что он пожаловался начальству: мол, в нашем отделе нет достаточно четких стандартов программирования. А тот его предшественник просто программировал так, как считал нужным, в своем стиле. Так мой коллега понял, что бывает, если хороший, серьезный программист уделяет недостаточно внимания ясности. В итоге получилась одна очень длинная программа — не то чтобы спагетти-код, просто слишком много уровней сложности в одном линейном куске. Парень почти достал меня, обратившись к начальству, как я уже говорил, через мою голову и сказав, что наш отдел работает не по стандартам.

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

Козелл: Нет. Это он понял. Но уже изменил свои взгляды. Это тот тип людей, которые, бросив курить, начинают громче всех жаловаться на других курильщиков. Он стал одним из лучших сотрудников в моем проекте. Он сам придирался ко мне, когда я был недостаточно последователен и допускал компромисс в работе. Мой проект стал для него первым проектом подобного рода. Передача данных, реальное время и все, что с этим связано, было ему в новинку. Но он оказался умницей, быстро во всем разобрался и стал очень хорошим программистом, как я и ожидал. Впоследствии я слышал о нем только самые лучшие отзывы. С ним все получалось. Остальные не любили работать со мной, считая меня слишком властным; не могу понять, почему.

Сейбел: Вы придерживаетесь каких-либо правил относительно количества комментариев?

Козелл: Я не добавляю в свой код слишком много комментариев, так как считаю, что он сам по себе должен быть читабельным и ясно выражать твои алгоритмы и мысли. Пишу комментарии к подпрограммам с кратким описанием того, как они действуют и как к ним обращаться — что делать, когда возникают исключения, какова последовательность аргументов и так далее. Но сам по себе код должен ясно выражать, что ты делаешь с его помощью.

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

Я никогда не был фанатом структурированных программ, где каждая подпрограмма сопровождается 18-строчным комментарием и все аргументы идут в строгом порядке. Я не структурирую свои программы настолько тщательно. Какие-то из моих подпрограмм могут быть длинными, другие — короткими. Меня беспокоит общая структура программы, так сказать, расположение фигурных скобок.