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

Томпсон: Нет. Это отличная идея, но на практике реализовать ее почти невозможно.

Сейбел: Почему?

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

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

Томпсон: Вот вы сделали два варианта. Один из них — реальный, тот, который исполняет машина. А второй — нет. И он нужен, только когда он значительно короче первого. Если же объем одинаковый, то можно читать тот, который работает. Если один вариант значительно короче, менее детализирован и из него можно извлечь все что надо — отлично. Но очень часто его недостаточно, и за деталями приходится обращаться к другому. В зависимости от того, что вам нужно, вы читаете либо один, либо второй. Но пытаться сделать два микроскопических описания алгоритма — на языке программирования и на английском — может, Кнут это и умеет, а я так не могу.

Сейбел: Вы читали какую-нибудь из его литературных программ?

Томпсон: Только то, что было в его ранних статьях. Из недавнего — ничего.

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

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

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

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

Томпсон: Так поступаешь, когда увлечен. Вообще не представляю, чтобы я мог не написать UNIX. Кроме того, когда жена и ребенок рядом, ты прикован к 24-часовому циклу. Когда они уехали, 24-часовой цикл стал для меня менее обязательным. Мне вовсе ни к чему следовать за солнцем. Поэтому я обычно сплю по 6 часов в соответствии с 27- или 28-часовым циклом. В плавающем режиме. Когда я сплю до естественного пробуждения, я в лучшей форме, чем когда просыпаюсь от детского плача.

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

Томпсон: Так сгорают на работе. Когда я был увлечен, то получал от программирования удовольствие и никогда не испытывал стресса.

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

Сейбел: Да, сгораешь на работе, и это, безусловно, плохо, но ведь в итоге работа сделана за более короткое время — может, оно того стоит?

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

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

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

Сейбел: В одном из интервью 1999 года вы сказали, что невысоко ставите Linux, и фанаты Linux приняли это в штыки. Что вы можете сказать сейчас, спустя десятилетие, когда эта система почти что завоевала мир?

Томпсон: Она гораздо надежнее — здесь нет никаких сомнений. И я как-то заглянул в ее код. Не так углубленно, как, например, в Plan 9. Они всегда нас опережали, просто у них намного больше ресурсов для работы с оборудованием. Так что, когда мы работали с каким-то элементом оборудования, я смотрел на драйверы Linux и писал в сравнении с ними драйверы для Plan 9. Сейчас у меня нет причин заглядывать в драйверы, я запускаю Linux. И иногда смотрю в код, но редко, так что не могу сказать, выросло качество или нет. Но надежность, несомненно, значительно возросла.

Сейбел: Вы когда-нибудь читаете код просто ради интереса?

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

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

Томпсон: То и другое. Сначала я пытался разобраться в больших библиотеках, рассматривал основные программы. В Google очень странный стиль программирования. Они берут вызов подпрограммы, запаковывают его как RPC и сохраняют как нечто статичное. То есть каждый может обратиться к нему в любой момент по любому поводу. И потом они вызывают групповой слушающий код и кто-то где-то получает сообщение, идет и находит вот это и выполняет этот вызов подпрограммы.

Сейбел: Это механизм распределенных вычислений.

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

Сейбел: Работая в команде, какую структуру вы предпочитаете?

Томпсон: Просто работать с хорошими и совместимыми людьми.

Сейбел: Работая с совместимыми людьми, предпочитаете ли вы четкое распределение ответственности: «Этот кусок кода пишу я, он мой и я несу за него ответственность», — или коллективную ответственность: «Мы все владеем этим кодом, и любой может делать то, что считает подходящим»?

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