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

Мы сошлись, и в конце концов он сделал язык TRAC - думаю, можно сказать, что мы его создали вместе. Он в тот момент оказывал мне очень серьезную поддержку.

Другой человек, которого я всегда воспринимал как своего наставника, - это Дэнни Боброу. Мы очень долго дружили. И на протяжении своей профессиональной деятельности я всегда считал его своим наставником.

Но если говорить непосредственно о программировании, о разработке ПО, то никого такого в MIT не было. Никого, по большому счету, не было и в Беркли. В PARC был лишь один человек, который по- настоящему повлиял на то, как я разрабатывал ПО, - и то он даже не был программистом. Это был Джерри Элкинд, менеджер лаборатории информационных технологий в PARC.

Вот его слова, которые значительно на меня повлияли: очень важно всегда проводить количественные оценки; будут моменты - даже больше моментов, чем сейчас кажется, - когда твои убеждения и твоя интуиция окажутся неверны, поэтому все измеряй. Иногда даже нужно измерять вещи, которые, как тебе кажется, и измерять-то не надо. Эта мысль очень сильно на меня повлияла.

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

Сейбел: Вы единственный из тех, к кому я обращался по поводу этой книги, весьма резко отреагировали на слово “кодер” в ее названии. Как бы вы предпочли себя называть?

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

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

Нет ничего плохого в том, чтобы быть кодером. Как нет ничего плохого в том, чтобы быть каменщиком. Чтобы делать то и другое хорошо, требуется множество навыков. Но это лишь очень маленькая часть всего процесса.

Сейбел: Какой же обобщающий термин вас устроит? Разработчик ПО? Специалист в области компьютерных наук?

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

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

Сейбел: А что он не описывает?

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

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

Дойч: Да, именно этим занимается экстремальное программирование (ХР). Я не являюсь большим поклонником этого подхода. Экстремальное программирование ратует за тесную связь с клиентом во время процесса разработки по двум, как мне кажется, причинам. Первая - таким образом нужды клиента можно лучше понять и выполнить. Может быть, это действительно так. Я не обладаю информацией из первых рук, но отношусь к этому с небольшим скепсисом, поскольку клиенты не всегда знают, чего хотят.

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

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

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

Сейбел: Вы можете привести пример неудачного обобщения или специализации из своего опыта?

Дойч: Когда я был на пике своей карьеры, одна из вещей, что удавались мне очень хорошо (не утверждаю, что всегда), - я умел выбирать верную степень универсальности, охватывающую несколько последующих лет развития в абсолютно неочевидных направлениях.

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

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

Если вы взглянете на цветовое изображение, разбитое на пикселы, то поймете, что в памяти его можно представить несколькими способами. Можно представить его в памяти как массив пикселов, где каждый пиксел (точка изображения) содержит данные о цветах из схемы RGB или CMYK. Например, так работают обычные контроллеры дисплеев.

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