Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста

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

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

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

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

Мы часто применяли это правило на практике. Как-то раз мы работали над одним большим проектом, и чем дальше, тем более запутанным он становился. Тогда мы начали разбираться вместе. Я сказал: “Это кажется слишком сложным”. И тут вдруг выяснилось, что у нас есть блок-схема, изображающая, как все в итоге должно работать. Посмотрев на нее, все были потрясены: мы сразу поняли, как каждый блок должен выполнять свою задачу. Мы не стали утруждаться и расписывать это все на бумаге, и так было понятно, как скоординировать свои усилия и добиться успеха. Я достаточно давно в этой профессии, чтобы понимать: в ней есть сложности. Но их очень немного. И чем напряженнее человек размышляет над проблемой, тем проще она становится, и в конце концов понимаешь, как на самом деле просто запрограммировать ее правильно.

Второе правило состоит в том, что программы должны быть читабельными. Хотя я, каюсь, в молодости писал страницы макросов ТЕСО, но довольно скоро - наверное, когда работал над системой разделения времени для PDP-1, и ее первоначальная сложность начала понемногу сходить на нет, - пришел к убеждению: исходный код программы предназначен для человека, а не для машины. Компьютеру все равно. Мне кажется, очень правильно, что в Perl есть и “если” (if), и “если не” (unless). Потому что если что-то должно быть сделано при невыполнении какого-то условия, по-английски правильнее сказать “unless”, а не “if not”.

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

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

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

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

Сейбел:Ого!

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

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