Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста
- Название:Кодеры за работой. Размышления о ремесле программиста
- Автор:
- Жанр:
- Издательство:Символ-Плюс
- Год:2011
- Город:Санкт-Петербург
- ISBN:978-5-93286-188-2
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста краткое содержание
Программисты - люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они “подсели” на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.
Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.
Кодеры за работой. Размышления о ремесле программиста - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Он был не настолько хорош, чтобы выдавать на 100% идеальный готовый код. Но его код был на 75-80% вполне приличным и в большинстве случаев работал. Когда он ушел в другой проект - TIP, если не ошибаюсь, - мы с Дэйвом продолжали работать над системой IMP, и именно тогда я переписал алгоритм маршрутизации, поскольку не понимал, откуда взялись заложенные в нем константы. Это по-прежнему оставался алгоритм Уилла, но переписанный в моем стиле. И теперь я понимал, как и почему он работает, потому что сам заставил его работать.
Одним из наших главных расхождений с Уиллом - я мог часами работать под его скептическим взглядом - была его убежденность в том, что, переписывая программу, порождаешь больше новых ошибок, чем исправляешь старых. Поэтому его блокнот был полон заплаток. Он до последнего готов был исправлять имеющуюся программу, вместо того чтобы ее переписать. В итоге заплаты ставились на заплаты, и вся система настолько усложнялась, что сам Уилл не мог предсказать, как она будет работать. Тяжело было после этого все наладить, хотя, казалось бы, именно для этого и добавлялись заплатки.
Сейбел:Итак, у вас был листинг оригинального исходника, который нужно было скормить ассемблеру...
Козелл:Да. И запущенный двоичный образ. Затем мы с помощью перфоленты - а порой и вручную - вставляли переход на небольшую область, где три исходные строки кода заменялись на эти пять новых, после чего управление передавалось обратно и работа продолжалась как и раньше. То есть при исполнении этого кода машина обращалась к заплатке, выполняла нужные действия, а потом возвращалась обратно.
Сейбел:Значит, перфолента содержала двоичную версию заплатки?
Козелл:Да. Потом уже я написал маленький интерактивный отладчик, выполнявший функции проверки и помещения заплатки в нужное место. Это существенно облегчало работу: можно было нанести на ленту такую программу: “Перейти по адресу 12785, значение, значение, значение, значение. Пустая строка. Перейти по адресу 12832, значение, значение, значение, значение, значение”. Если надо было загрузить программу с нуля, то сначала загружалась сама программа, потом - лента с заплатками.
Сейбел:Значит, на том этапе у вас не было никакого исходного кода, который ассемблировался бы в текущее состояние запускаемой двоичной программы?
Козелл:Совершенно верно. Одна из проблем состояла в том, что у нас было несколько вариантов текста программы. В одном из них мог быть помечен участок кода, где две строки нужно вычеркнуть, заменив таким-то кодом. Были ли такие пометки во всех вариантах? Хорошо, что Уилл все записывал в свой чудесный блокнот - именно он и был последней инстанцией. Таков был его подход.
Мой же подход состоял в том, что система всегда должна работать сразу. Я не хочу работать с множеством постоянно вносимых исправлений. Придя в проект, я первым делом проделал большую работу, добавив все необходимые заплатки. Мы работали над этим весь день, потом я всю ночь редактировал систему и реассемблировал ее, и утром у нас была готова новая перфолента, с которой можно было работать. После ночной редактуры, как правило, нужно было внести буквально 2-3 изменения, и уже ясно было, каких. Так что сделать это было несложно.
То есть мы почти избавились от такой проблемы, как добавление новых ошибок при исправлении старых, разве что заплатка оказывалась неправильной.
Тут мы с Уиллом здорово спорили, потому что он действительно любил ставить заплатки, стремясь держаться подальше от ассемблера, - отчасти потому, что это занимало много времени, а так он мог, поставив заплатку, работать дальше, а отчасти потому, что не доверял циклу, считая редактирование слишком опасным.
Сейбел:Считаете ли вы работу над IMP одним из своих главных профессиональных достижений?
Козелл:Как ни странно, нет. Да, это был интересный, трудный проект. Но кроме него я написал DOCTOR, программировал на Лиспе, стал “царем больничной компьютерной системы”. По-настоящему важной для меня работой была работа над той революционной системой разделения времени, в которой я так тщательно разобрался. A IMP был просто одним небольшим коммуникационным процессором. Там не было столько каналов прерываний, как на PDP-1. Не приходилось решать проблемы вроде такой: как быть, если у тебя всего 32 слота для своппинга, а в системе авторизовано 40 человек?
Работа с IMP принесла нам известность, это было весело и интересно. Написать и отладить некоторые места было действительно непросто. Но я бы не назвал это вершиной своей карьеры. Это была просто еще одна программа. К тому же система IMP была весьма ограниченна в применении. Работа же PDP-1 была настоящим вызовом. Это была система разделения времени, которую требовалось постоянно развивать.
Самое примечательное в системе IMP - это скорость, с которой мы ее сделали. Ребята официально начали работать над ней в январе, я присоединился в феврале, а в сентябре она была уже готова. Относительно “готова”, потому что мы продолжали вылавливать баги и вносить еще некоторые изменения. Но все же в сентябре программа официально была выпущена. Вскоре Уилл перешел в другой проект, а мы с Дэйвом и еще пара новых ребят продолжили дорабатывать систему.
Должен выразить самую искреннюю благодарность Фрэнку Харту. Не знаю, как ему удавалось руководить нами, при этом всегда позволяя оставаться самими собой. Не припоминаю ни одного собрания программистов. Не припоминаю, чтобы нас хоть раз загрузили бумажной работой, когда наши головы были полностью заняты программой и некогда было отвлекаться на все это. Это был такой уровень доверия и уверенности, когда нам троим просто дали эту работу и оставили в покое. Оглядываясь назад, я понимаю теперь, как это трудно быть менеджером проекта и какую потрясающую работу проделал Фрэнк. Никаких еженедельных собраний сотрудников, никакого рисования PERT-диаграмм на доске. Уилл, конечно, отслеживал текущие задачи, найденные ошибки и прочую проделанную работу, но отсутствие какого-либо систематического надзора над нами поражало. Собрать нас вместе, дать нам поручение и уйти в тень - думаю, для руководителя это был очень смелый поступок.
Другой прием, которым пользовался Фрэнк, - ревизии проекта. Тогда мне казалось, что у него они самые серьезные из всех возможных, и со временем мое впечатление не изменилось. У него на ревизии сотрудники тряслись от страха. Это было нечто вроде защиты диссертации. Он собирал в аудитории несколько человек, и ты должен был представлять свой проект. Тебя слушали со всей доброжелательностью, но при этом Фрэнк всегда сразу понимал, в каком месте ты блефуешь.
Читать дальшеИнтервал:
Закладка: