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

Третье решение заключалось в том, что драйверы должны выполнять основные графические команды, которые вначале сводились к draw-pixmap и fill-rectangle.

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

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

На самом деле, интерпретатор Postscript первого уровня я написал без графики - лишь после я написал первую строку кода графики. Откройте руководство и просто пройдитесь по всем операторам, никак не связанным с графикой, - я реализовал их все до того, как начал разрабатывать графику. Мне нужно было разработать токенайзер; мне нужно было определиться с представлением всех типов данных Postscript и всего того, что, согласно руководству, интерпретатор должен делать. Мне нужно было вернуться и переделать многие из них, когда мы добрались до разработки Postscript второго уровня, в котором была функция сборки мусора. Но именно с этого я начинал.

После чего я стал разрабатывать структуры данных для интерпретатора, просто опираясь на свой опыт работы с языковыми интерпретаторами. Между моментом начала и моментом, когда я мог набрать 3 4 add equals и получить на выходе 7, прошло около трех недель. Это было очень легкой работой. Кстати говоря, среда, в которой я работал, - MS-DOS. MS-DOS с упрощенным Emacs и чьим-то компилятором Си - не помню точно, чьим.

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

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

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

Когда я озаботился проблемой получения авторских прав на код Ghostscript, мне пришлось отправить полный листинг самой первой его реализации. На тот момент уже прошло около десяти лет - мне было интересно взглянуть на первые варианты кода, структуры и названий для разных вещей. Примечательно также то, что около 70-80% структуры и принципов наименования остались теми же - спустя десять лет и после двух серьезных переработок языка Postscript.

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

Сейбел:То есть говоря о написании заголовочного файла, вы имеете в виду создание сигнатуры функций или структур - или и то, и другое?

Дойч:Речь идет о структурах. Это был 1988 год, еще не было ANSI С и не было сигнатур функций. Как только компиляторы ANSI С стали более или менее нормой, я потратил два месяца, прошелся по всей программе и сделал сигнатуры для каждой функции в Ghostscript.

Сейбел:Каким образом ваши идеи о программировании или ваш подход к программированию изменились с того далекого времени?

Дойч:Они изменились очень сильно, поскольку очень сильно изменились те программы, которые мне интересны. Думаю, не погрешу против истины, если скажу, что программы, которые я писал первые пару лет, были всего лишь небольшими фрагментами кода.

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

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

Сейбел:По-вашему, все программисты должны стремиться к работе на подобном уровне?

Дойч:Нет. На самом деле, я буквально на днях прочитал, что мой давний знакомый по работе в Xerox PARC Лео Гуибас только что получил достаточно престижную профессиональную премию. Он никогда не был по-настоящему системным программистом - таким, каким был я; он всегда был алгоритмовым программистом и всегда работал блестяще. Он нашел подход к определенным классам анализа и оптимизационным алгоритмам, который позволил применять их для решения множества различных задач, и создал новые инструменты для работы с этими задачами. Это прекрасная работа. К тому, чтобы работать на уровне Лео Гуибаса, программисты тоже должны стремиться.

Есть некое сходство между архитектурными принципами и теми принципами алгоритмической разработки, которые Лео и программисты его типа применяют для решения сложных оптимизационных и аналитических задач. А разница в том, что принципы работы с алгоритмическими задачами основаны на 5000-10 000-летнем опыте математической науки. В современном же программировании у нас нет подобной базы. Возможно, именно в этом одна из причин того, что сейчас так много плохого ПО; мы не понимаем толком, что делаем.

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