Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста
Нужно быть достаточно уверенным в своих навыках профессионалом, чтобы сказать: “Отлично. Вот моя проблема. Я не знаю, что с ней делать, и когда готовил свой отчет, надеялся, что вы, ребята, этого не заметите и одобрите его”. Естественным ответом на это будет: “Конечно, мы одобрим его, потому что он выглядит хорошо. Теперь давай разберемся с твоей проблемой - наши лучшие парни собрались здесь как раз для того, чтобы ты не бился над этим сам еще неделю или две”.
На самом деле подобные ревизии нужны самому сотруднику, помогая ему убедиться в правильности решений в случаях, когда он знал, как это сделать, или получить совет там, где он сам понимает свою слабость. Когда я понял это — в мои 20 лет или, возможно, годом позже, — мне стало очевидно, что такая помощь старших товарищей чрезвычайно полезна.
Конечно, для клиента составлялся другой отчет, весь в радужных тонах. Но для сотрудника такие внутренние отчеты были реальной возможностью вырасти профессионально. И меня всегда удивляло, насколько многие люди их боятся. Умный парень может уверять себя и других в том, что его отчет будет порван на клочки. Хотя ясно, что не будет, если в нем есть хоть что-то хорошее, и что тут собрались не его враги. Но убеждать в этом такого парня было совершенно бесполезно. Он все равно пытался пустить всей BBN пыль в глаза, рассказывая о том, как все замечательно.
Не менее трудно было объяснить ему, что в другой раз столько хороших специалистов не соберутся вместе только для того, чтобы помочь ему справиться с его проблемой. После этого придется справляться уже самому, и это замечательный опыт.
Сейбел: Как часто проводились подобные ревизии? Один раз в самом начале проекта или периодически на протяжении всего срока работы над ним?
Козелл: Многократных ревизий не было. Обычно она проводилась один раз сразу после того, как ты разработал проект.
Сейбел: Получается, нужно было знать, как будет выглядеть результат, еще до того, как начнешь программировать?
Козелл: Да, точно. Именно так. Наверное, что-нибудь запрограммировать все-таки придется, потому что многим, включая меня, требуется собрать по кусочку кода, чтобы понять, как все в итоге будет работать.
Но обычно мы работаем в жестко заданном цикле: сначала предлагаем какой-то программный продукт, потом делаем его. То есть мы должны показать клиенту, что собираемся сделать, и показать хорошо, потому что после этого он даст нам деньги и время на работу и должен знать, за что он платит. Итак, на этом этапе мы определяемся с требованиями и пишем себе техническое задание. После этого разбираем его внутри компании, чтобы удостовериться, что нам все понятно. Не помню, чтобы Фрэнк вмешивался в уже начатые проекты. Во всех проектах, где я работал, Фрэнк не интересовался промежуточными результатами работы.
Сейбел: Вы упомянули DOCTOR. Что это за программа?
Козелл: Когда я работал над системой разделения времени для PDP-1, Дэн Мерфи с друзьями тоже работали с PDP-1, заканчивая систему на Лиспе. И я надумал выучить Лисп. Той весной Джо Вейзенбаум написал для журнала “Communications of the ACM” статью о своей программе ELIZA (Элиза). Я подумал, что это круто. И еще я был уверен — и пребываю в этой уверенности до сих пор, - что могу сделать на компьютере все, что сумею понять. Он описал, как работает ELIZA, и я сказал себе: “Спорим, я могу написать такую же”. И начал писать программу на PDP-1, на системе Дэна Мерфи в BBN. Телетайп модели 33 в моем компьютерном зале с PDP-1 был подключен к PDP-1 Дэна Мерфи, так что я мог использовать его компьютер из моего компьютерного зала, будто это была моя система. Я писал эту программу, улучшал ее и одновременно работал. Постепенно втянулась практически вся BBN. Ребята оставляли мне комментарии: “Лучше сделай так-то и так-то” или “Я попробовал это, и оно не работает”. Это помогло развить идею Вейзенбаума так, как он и не помышлял. Первоначально программа была написана на Лиспе для PDP-1. Но ребята уже программировали на Лиспе для PDP-6 или, может, даже PDP-10. Лисп получил широкое распространение через ARPANET. И, видимо, DOCTOR вместе с ним.
Я впервые был согрет лучиком славы, когда Дэнни Боброу написал мне: “A Turing Test Passed” (Тест Тьюринга пройден). Это было чуть ли не впервые, когда меня заметили из-за моих дурацких программ: мне пришлось прекратить работу над DOCTOR. Один из директоров BBN зашел в комнату с PDP-1, подумал, что Дэнни на связи, и начал переписываться с ним. Мы, кто был знаком с программами вроде Элизы, легко распознавали их ответы, не замечая, насколько они похожи на человеческие. Но тем, кто не имел дела с такими программами, их ответы казались вполне разумными. К сожалению, он и в самом деле подумал, что это был Дэнни. “Расскажите мне еще о...” - “Помнится, вы сказали, что хотите пройти в комнату для клиентов”. Подобные фразы казались осмысленными в общем контексте, пока в какой-то момент босс не забыл нажать кнопку и отправить очередное сообщение, так что программа не смогла ответить. И он подумал, что Дэнни отсоединился. И позвонил ему домой, наорав на него. А Дэнни даже не понял, что происходит. Но он знал о моем терминале. Так что Дэнни пришел на работу и вынул распечатку из телетайпа, чтобы сохранить ее.
То была очень продвинутая версия программы Вейзенбаума. Мы немного улучшили скрипты. Многие поколения хакеров работали над этим. Как я уже говорил, программа кочевала по Сети. Думаю, сейчас уже есть ее версия, написанная в макросах Emacs. Но тогда она стала моим “боевым крещением” в Лиспе.
Сейбел: Вот интересно - я знаю, что часто авторами самых сложных, запутанных программ становятся люди, способные держать в голове миллионы подробностей. Вы, без сомнения, это можете, но все же стараетесь сделать свой код как можно более простым и ясным.
Козелл: Признаюсь, у меня бывало по-разному. В целом, я стараюсь делать программы простыми. Но это не значит, что отдельные специфические аспекты их функционирования не могут быть сложными. Стремясь к цели, я могу написать очень сложный код, настолько запутанный, что другим его даже трогать не захочется. Но он всегда будет инкапсулирован.
Большая часть плохих программ, из которых я выкидывал неудачные места, переписывая их заново, не были такими. В них не было маленького островка сложности, который можно попытаться понять и исправить, - они были запутанными в целом.
Я выработал пару правил, которые всегда стремлюсь привить людям, особенно недавним выпускникам колледжей, думающим, что они знают о программировании все. Первое заключается в том, что есть совсем немного непреодолимо сложных программ. Если вы смотрите на участок кода и он кажется вам сложным - настолько, что вам даже не понять, для чего он предназначен, - то почти всегда это значит, что вы просто мало над ним думали. И не стоит, засучив рукава, пытаться прямо сейчас его исправить - лучше вернуться на шаг назад и попробовать понять еще раз. Когда вам это удастся, вы увидите, что на самом деле все гораздо проще.
