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

• Название: Кодеры за работой. Размышления о ремесле программиста
• Автор: Питер Сейбел
• Жанр: Биографии и Мемуары
• Год: 2011
• ISBN: 978-5-93286-188-2

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

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

---

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

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

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

Сейбел: Вы читали программы Кнута, написанные в этом стиле?

Крокфорд: Конечно.

Сейбел: Как вы их читали? Как роман?

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

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

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

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

Крокфорд: Да. Но на самом деле не так-то просто найти код, который можно читать просто для удовольствия. Кнут написал кое-что. Фрейзер и Хэнсон[42] создали компилятор Си в стиле литературного программирования - он очень классный. Но примеров не так много. Очень жаль. Это может говорить о том, что литературное программирование, возможно, потерпело неудачу.

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

Крокфорд: Все что угодно, кроме последнего. Когда я учился в колледже, то пару месяцев не платил за квартиру, чтобы купить его книги. Я читал их и находил там шутки, например в содержании первого тома, но понимал далеко не все. В некоторых местах Кнут гораздо выше моего разумения, но книги мне очень понравились, кроме того, я часто использовал их в качестве справочников.

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

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

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

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

Мне бы хотелось, чтобы все это было совершенно необходимо программистам, но это не так. Может быть, именно поэтому веб-программирование получило столь бурное развитие и стало доступно многим, именно поэтому JavaScript так популярен. Все это не так сложно. А большинство сложностей - лишние. Если мы чуть-чуть почистим платформу, эта работа станет значительно легче.

Сейбел: Итак, Кнут дал вам эти унылые формулы, а потом - раз! - и появилась цельная картина. Даже если почистить платформу, создание и проектирование больших и понятных систем останется нелегким делом. Как вы проектируете свой код?

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

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

Например, JSLint немало изменился с тех пор, как я начал разрабатывать его в 2000-2001 гг. Да и задачи его существенно изменились: теперь на нем можно делать то, чего я и не представлял, - и во многом благодаря гибкости JavaScript. Я могу вертеть его как хочу, программа может разрастаться, но при этом не становится громоздкой.

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

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

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

Крокфорд: Да, есть от чего встревожиться, но это и хорошо; тревога - это реальность. Это дисциплинирует. В большинстве традиционных языков дисциплину вам навязывает язык. Работая с JavaScript, вы должны дисциплинировать себя сами.

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

Сейбел: Итак, “мягкость” объектов в JavaScript может быть опасной. Но если вы никогда не пользовались возможностью расширения объектов, то с тем же успехом могли бы создавать классы в Java. Как вы полагаете, можно ли структурировать программы на JavaScript, так чтобы извлечь максимальную пользу из гибкости языка?

Крокфорд: Мне потребовались годы проб и ошибок. До работы с JavaScript я ничего не читал об этом языке, просто начал работать и все. Я нашел пример программы, довольно жуткий, и всячески вертел его, пока все не заработало примерно так, как мне было нужно. В общем, я начал программировать на языке, не имея представления о том, что это за язык, как он работает и как на нем думать.

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