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

Сейбел:Есть ли базовые навыки, необходимые хорошему программисту? В разных сферах, конечно, разные требования, но есть ли нечто общее в написании кода независимо от сферы деятельности?

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

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

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

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

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

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

Норвиг:Выбор велик, тут можно пойти разными путями. Надо прочесть что-нибудь про алгоритмы - программист не должен становиться только склейщиком программ. Можно взять Кнута, а можно Кормена, Лейзерсона и Ривеста. Есть и другие авторы, например Салли Голдман. В ее последней книге алгоритмы рассматриваются с практической стороны. Довольно интересно написано. Кроме того, что-нибудь про идеи абстракции. Мне нравится труд Абельсона и Сассмана, но он не единственный.

Надо досконально знать свой язык. Читайте справочники. Читайте книги, где объясняется механика языка и одновременно способы отладки и тестирования, - “Beautiful Code” [62] Стивен Макконнелл “Совершенный код”. - СПб.: Питер, 2007. или что-нибудь подобное. Но я бы не стал советовать читать исключительно это, а не что-нибудь другое.

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

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

Еще очень важно понимать, что делаешь. Когда я писал программу для решения судоку, некоторые блогеры комментировали ее в таком духе: “Сравните, вот это написал Норвиг, а это другой парень, один из гуру разработки через тестирование (забыл, как его зовут). Он сказал, что сначала напишет несколько тестов”. Но у него ничего не вышло. Он вывесил пять постов в своем блоге, там было много тестов, но ничего для решения задачи. Он не знал, как ее решать.

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

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

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

Норвиг:Как узнать, чего именно не знаешь?

Сейбел:Вот именно.

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

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

Норвиг:Допустим, я решаю некую задачу в области биологии. Я не знаю, какие алгоритмы применяются при генетическом секвенирова-нии, но знаю, что они есть. И я оглядываюсь вокруг. На другом уровне некоторые из таких вещей довольно фундаментальны - если вы не знаете, что такое динамическое программирование, это большой минус для вас. И это будет постоянно проявляться, если у вас нет представления об этой общей модели поиска - сделать выбор и вернуться, когда надобность отпадет. Это идеи родом из 1960-х. Люди открыли это, когда занимались программированием всего несколько лет. Это то, о чем каждый обязан иметь представление. А идеи годовой давности, конечно, известны не каждому.