Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Я бы ничего не узнал о кэшировании и о тенденциях изменений в компьютерной индустрии, и о других подобных вещах, если бы просто шел по накатанной дорожке - черпая знания для своих книг из уже написанных трудов. Пока я писал первые три тома, я не создавал программ, подобных ТеХ, написание которых более характерно для активной программистской деятельности. Я же писал пробные программы. Таким образом, я получал некое представление о числах и величинах.
На самом деле, это потрясающе - осознавать во время процесса написания книги те вещи, которые заставляют тебя использовать то или иное слово. Это поистине тайна — как это все происходит. Это наиболее важное влияние, которое оказал на меня опыт создания
Сейбел: То есть к моменту завершения ТеХ вы были уже значительно лучшим программистом, чем когда начинали его создавать?
Кнут: Да, потому что я стал применять методы литературного программирования.
Сейбел: Понятно, у вас появились более качественные инструменты, но улучшились ли непосредственно ваши навыки?
Кнут: Я узнал очень много нового, пока работал над этим проектом. В частности узнал, как много ресурсов вашего мозга съедает разработка ПО. Это оказалось намного более сложным заданием, чем я ожидал. Я не мог одновременно преподавать на полную ставку и полноценно заниматься разработкой ПО. Но я мог преподавать на полную ставку и полноценно заниматься написанием книг; ПО же требовало невероятного внимания к мельчайшим деталям. Мой мозг был забит только программным обеспечением, так что я не мог думать ни о чем другом. Поэтому я стал с особым уважением относиться к тем, кто работает в крупных проектах по разработке ПО; я бы никогда не узнал, как они работают, если бы сам не занимался схожей работой.
Сейбел: То есть, по-вашему, программировать сложнее, чем писать книги; где-то я читал ваше мнение, согласно которому невозможно сказать, сколько времени займет написание той или иной книги. Значит ли это, что сказать, сколько времени займет написание одной программы, еще сложнее?
Кнут: Да, это так. Это очень верный вывод.
В этом году я написал три крупные программы с помощью методов литературного программирования, код каждой из которых занимает больше 100 страниц формата А4. Две из них взаимосвязаны, так что это скорее две с половиной программы. И еще около 150 небольших программ. Пожалуй, за предыдущий год мне удалось сделать меньше. То есть я очень плотно занимался в этом году созданием небольших программ, но некоторые из них я писал по месяцу или дольше.
Сейбел: И вы с самого начала могли сказать, что будете писать их месяц?
Кнут: Что касается одной из них - да, я ожидал, что на ее создание уйдет месяц. Я знал, что это будет непростое задание, но не мог предположить, насколько у нее богатый потенциал, - я даже добавил несколько дополнительных свойств по ходу ее использования. Я считаю, что это абсолютная истина, которую должен усвоить каждый руководитель отдела разработки: сроки написания программы нельзя спрогнозировать.
Сейбел: Помимо того что вы написали “Искусство программирования” и ТеХ, вы изобрели и всячески продвигали литературное программирование - способ программирования, при котором код гораздо легче прочитать неспециалисту. Вы написали WEB и CWEB, инструменты реализации языков литературного программирования на базе Паскаля и Си.
Кнут: Вы сказали продвигал– да, я люблю поговорить о достоинствах этого метода. Но все же не очень люблю проповедовать или пытаться обращать людей в свою веру. Мне кажется, что программирование очень похоже на религию - и там, и там у людей есть убеждения. Кто-то любит навязывать свои убеждения
Сейбел: Так, может, объясните, почему вы так любите литературное программирование и чем оно отличается от нелитературного программирования?
Кнут: Первое правило пишущего человека - нужно понимать свою аудиторию: чем лучше знаешь своего читателя, тем лучше пишешь; это очевидно. Второе правило, касающееся технического писателя, - говорить все вещи дважды - так, чтобы у читателя была возможность усвоить информацию из нескольких дополняющих друг друга источников.
Поэтому в технических книгах так много избыточных конструкций. Все моменты объясняются и формально, и с помощью разговорного языка. Или даешь определение, а потом добавляешь: “Следовательно, вот такое-то и такое-то утверждения - верны”. И это добавление можно понять только в том случае, если понял определение.
Или можно сказать: “Допустим, что а, равное тому-то и тому-то, - это множество главных элементов”. Таким образом, разговорный термин множество главных элементов дополняется математическим описанием того, как мы создали множество а.
То есть в основе литературного программирования лежит идея, что лучший способ передачи сообщения - совмещение формального и неформального способов. Такой подход обеспечивает естественную основу для переключения между естественным языком - английским - и формальным языком - Си, Лиспом или любым другим языком программирования - и их совмещения. Как мне кажется, такой метод облегчает работу с документацией.
И еще: когда я пишу программу, мне не нужно предоставлять ее в той форме, в какой ее хочет видеть компилятор. Я предоставляю ее в форме, по моему мнению, наиболее доступной для читателя.
Кто-то пишет код снизу вверх, создавая подпрограммы, дающие все более крупные и крупные объекты, и становясь все более уверенным в себе, поскольку теперь может сделать гораздо больше. Другие пишут сверху вниз; они начинают писать и думают: “Так, у меня есть задача, которую нужно решить, - сначала я сделаю вот это, а потом - вот это”.
Если я пишу литературную программу, то могу выбирать между этими способами. И практически всегда в итоге моя программа создается в том порядке, в каком я ее сам продумал. То есть, начиная работу, я думаю: “Ага, у меня есть задача, которую нужно решить, то есть сначала мне нужно решить вот это, а потом я решу вон то”.
Но потом я говорю: “А теперь давай-ка построим кое-какие инструменты снизу вверх”. У нас есть в голове цель, но нам нужно построить несколько инструментов снизу вверх, после чего мы возвращаемся и делаем кое-какую работу сверху вниз. Но в каком порядке мы это делаем? Сначала мне нужно написать то, что я думал в первый день, когда мне пришлось столкнуться с данной задачей. А следующий этап будет посвящен тому, чем я решил заняться дальше.
И я начинаю заниматься тем, что в данный момент волнует меня больше всего, но и тем, что я готов решить в данный момент. Не откладывая этого дела в долгий ящик - если я готов выполнить его прямо сейчас, то прямо сейчас его и делаю. Но это уже совсем другой порядок - ни снизу вверх, ни сверху вниз. Это психологический момент: “Мне нужна задача, выполнение которой принесло бы мне сейчас наибольшее удовольствие и к выполнению которой я сейчас готов”. В этом уравнении не так уж много неизвестных. Таким образом, мне очень важно то, что я без всяких проблем могу создавать программу в подобном человечески понятном порядке.