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

Стил: Именно так: целую отрасль. Было полно одностраничных статей. Например: “Вот новый эффективный метод хеширования”. Я много читал такого.

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

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

Сейбел: Это ведь то, что делает Кнут?

Стил: Верно. Кнут и такие, как он.

Сейбел: Возможно, те, кто изучает компьютерные науки в колледже, проходят все это. Но многие программисты без официального образования учатся прямо в процессе работы. Что вы можете посоветовать в таком случае? От чего вы отталкиваетесь, как вам удается читать и понимать эти статьи? Может быть, надо прочесть все до единого выпуски “САСМ”, начиная с первых?

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

Во-вторых, как найти хороший материал, тем более что само это понятие меняется со временем? То, что хорошо сегодня, через десять лет устареет. Надо спросить у того, кто в этом разбирается. Что было полезным мне? Кнут, Ахо, Хопкрофт и Ульман. Затем “The Psychology of Computer Programming” Джеральда Вайнберга - она все еще не утратила ценности. Кое-что мне дал “The Mythical Man-Month”1 Фреда Брукса.

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

Ф. Брукс “Мифический человеко-месяц или Как создаются программные системы”. - СПб.: Символ-Плюс, 2000.

В основном учебники по Си и Java. Но если хорошо порыться, найдется немного книг по теории программирования, алгоритмам и так далее.

Сейбел: Есть другое чтение, и я знаю, что вы считаете его важным, - это чтение кода. Как вы ориентируетесь в чужом коде большого объема?

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

Сейбел: Путь исполнения?

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

Сейбел: А что значит “отслеживаете”? Смотрите на код и пытаетесь выполнить его в уме? Или берете отладчик и проходите код шаг за шагом?

Стил: И то и другое. Отладчик применяю в основном для небольших объемов кода 1970-1980-х. Сейчас между запуском программы и моментом, когда она начинает делать что-то интересное, может быть долгая инициализация. Поэтому разумнее найти главный цикл программы или главную управляющую функцию и отслеживать уже оттуда.

Сейбел: И после этого вы зададите точку останова и начнете пошаговое исполнение от нее или просто исполните программу в уме?

Стил: Скорее второе - буду читать код и размышлять над тем, что он делает. Если очень понадобится, я могу засесть за код и начать подробно читать его целиком. Но прежде надо понять, как все вообще работает. Иногда везет, и программисты оставляют документацию или называют все понятными именами, или располагают все содержимое файла в правильном порядке. Если так, код прочесть легко.

Сейбел: А что такое правильный порядок содержимого файла?

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

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

Сейбел: Итак, при написании кода сегодня вы отдаете предпочтение выстраиванию его “сверху вниз”: сначала высокоуровневые функции, затем низкоуровневые, от которых те зависят?

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

В MIT прекрасно было то, что человек мог знакомиться с кодом, написанным довольно умными хакерами, - код не держали под замком. Так я изучил код операционной системы ITS, реализации ТЕСО и Лиспа. И программу структурной печати Билла Госпера для Лиспа. Я освоил их еще в старших классах и попытался воспроизвести кое-что на своей IBM 1130.

Но я бы не смог реализовать Лисп на IBM 1130, не имея доступа к реализациям этого языка для других компьютеров. Я просто не знал бы, что делать. И это было важной частью моего образования. Отчасти проблема сегодня в том, что программы приобрели ценность, что большинство серьезных программ - коммерческие, и у нас не так много хороших примеров кода для изучения. Открытый исходный код отчасти решает эту проблему. Можно, к примеру, посмотреть код Linux. Для меня очень полезным оказалось чтение исходного кода ТеХ, потому что это был хорошо продуманный, хорошо отлаженный код.