Читаем Кодеры за работой полностью

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

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

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

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

Сейбел:

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

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

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

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

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

Дойч:

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

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

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

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

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

Перейти на страницу:

Все книги серии Профессионально

Кодеры за работой
Кодеры за работой

Программисты — люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они «подсели» на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.

Питер Сейбел

Биографии и Мемуары / Программирование / Прочая компьютерная литература / Документальное / Книги по IT
Человеческий фактор
Человеческий фактор

Немногие книги о компьютерах оказали такое заметное влияние на управление разработкой программного обеспечения, как «Человеческий фактор». Уникальное озарение этой книги, долгие годы сохранявшей свое положение в списке бестселлеров: самые сложные проблемы разработки ПО носят не технологический, а социальный характер. Эти человеческие проблемы решать не просто, однако, решив их, вы увеличите шансы на успех до верхнего предела.В третьем издании появилось шесть новых глав и внесены многочисленные правки в основной текст, так что теперь книга лучше соответствует современным средам разработки и современным проблемам. В частности, обсуждаются патологии лидерства, которые раньше за патологии не считались, эволюционирующая культура собраний, а еще растущее понимание того, что некоторые наши инструменты служат скорее якорями, а не двигателями. Каждый, кому необходимо управлять проектом по разработке ПО или целой организацией такого рода, найдет на страницах этой книги множество ценных советов.

Тимоти Листер , Том ДеМарко

Деловая литература
97 этюдов для программистов. Опыт ведущих экспертов
97 этюдов для программистов. Опыт ведущих экспертов

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

Пит Гудлиф

Программирование, программы, базы данных

Похожие книги