Текст книги "Кодеры за работой. Размышления о ремесле программиста"

Автор книги: Питер Сейбел

сообщить о нарушении

Текущая страница: 9 (всего у книги 41 страниц) [доступный отрывок для чтения: 15 страниц]

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

Крокфорд: Да. Но на самом деле не так-то просто найти код, который можно читать просто для удовольствия. Кнут написал кое-что. Фрейзер и Хэнсон[42]42
  Крис Фрейзер (Chris Fraser) и Дэвид Хэнсон (David Hanson), авторы книги «A Retargetable С Compiler: Design and Implementation» (Перенацеливаемый компилятор Си: проект и реализация). – Прим. науч.ред.


[Закрыть] создали компилятор Си в стиле литературного программирования – он очень классный. Но примеров не так много. Очень жаль. Это может говорить о том, что литературное программирование, возможно, потерпело неудачу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В конце концов я выяснил, что классы мне вообще не нужны, – язык сделает все за меня. Вместо того чтобы бороться с языком, я почувствовал, как сам язык придает мне силы.

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

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

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

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

Сейбел: Какими инструментами вы пользуетесь для написания кода?

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

Сейбел: И, разумеется, вы используете JSLint.

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

Сейбел: Значит, вы редактируете код в текстовом редакторе, потом прогоняете его через JSLint и наконец запускаете в браузере. А как насчет отладки?

Крокфорд: Зависит от браузера. Если это Firefox, использую Firebug, если IE – отладчик Visual Studio. Оба эти инструмента очень хороши. У нас в браузерах есть на удивление хорошие отладчики.

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

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

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

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

Крокфорд: Мне нравятся эти методики. Я был разочарован тем, что Eiffel не стал победителем среди объектно-ориентированных языков программирования, уступив первое место C++. По-моему, Eiffel был куда интереснее, мне нравилась его система контрактов на основе предусловий/постусловий. Я хотел бы видеть ее встроенной во все языки, с которыми я работаю. К сожалению, это еще одна из тех идей, которая так и не прижилась.

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

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

На Basic Four мы разработали полностраничный терминал для обработки текста, основанный на процессоре Z80 с 64 Кбайт памяти, чего было недостаточно для экрана такого размера. У нас также было подключение к локальной сети, по которой мы посылали страницы на свой сервер.

И у нас возникла проблема – экран то и дело гас. Архитектура была такая: в памяти хранилась строка текста со специальным символом конца строки, за которым следовал адрес следующей строки. Эти ссылки обрабатывались небольшим DMA-процессором. В какой-то момент ссылка пропадала – видимо, возникало что-то вроде гонок.

С нашей точки зрения, если посмотреть логически, все ссылки были правильными. Но мы не учитывали взаимодействия в реальном времени с тем процессором, который мог обращаться к памяти не одновременно с нами. И я таки разобрался в этом. Помню, в тот день я работал дома и по телефону постоянно созванивался со своей командой. Внезапно меня словно озарило. Я понял, в чем дело, объяснил им, как исправить ошибку, и больше она не появлялась.

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

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

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

Сейбел: Вас когда-нибудь интересовали формальные доказательства корректности ПО?

Крокфорд: В 1970-е я следил за ними с интересом, ожидая, чем все это закончится. Но особого результата так и не увидел. Программное обеспечение – сложная штука, и что-то может пойти не так по разным причинам.

Программное обеспечение – это прежде всего спецификация того, как программа должна работать. И ничто, кроме полной спецификации, не объяснит вам, каким должно быть поведение в конечном итоге. Именно это делает разработку программного обеспечения настолько сложным.

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

Крокфорд: Я скорее стараюсь действовать по обстоятельствам. Это еще один аспект, который я хотел бы изменить в своей работе, но полностью этого еще не сделал.

Сейбел: Речь о JsUnit?

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

В JavaScript тестировать отдельную функцию не слишком разумно, поскольку для ее работы требуется некоторое состояние. Так что я пока не нашел разумный подход к модульному тестированию в JavaScript.

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

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

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

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

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

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

Крокфорд: Скорее писателем. Иногда я пишу на английском, иногда на JavaScript.

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

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

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

Сейбел: У Дейкстры есть известная статья «On the cruelty of really teaching computing science» (О сложности практического обучения компьютерной науке), где утверждается, что программирование – ветвь прикладной математики. Вы согласны с этим?

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

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

Сейбел: Кажется, у Дейкстры есть примерно такое утверждение: «Если не можешь писать на своем родном языке, лучше не берись за программирование».

Крокфорд: Совершенно согласен.

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

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

Но нельзя, чтобы все разбредались и делали каждый что-то свое. Так не получится, от этого никому не станет лучше. Одни должны создавать продукт, остальные – высказываться «за» или «против». JSON – тоже историческая случайность.

Сейбел: Как вы думаете, индустрия ПО – это система блестящих инноваций или омерзительная свалка?

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

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

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

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

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

Сейбел: Но в целом есть прогресс, как вы считаете?

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

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

Сейбел: О каких конкретно системах вы говорите?

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

Сейбел: Я заметил, что нечто похожее происходит и с языками программирования: программы для ПК писались на языке ассемблера, поскольку даже Си был для него слишком высокоуровневым. И только сегодня мы переходим к языкам, по мощности приближающимся к Smalltalk и Лиспу, существовавшим в момент появления ПК. Интересно, программисты задумаются над историческими уроками или так и будем продолжать изобретать велосипед?

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

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

Сейбел: Назовите некоторые из этих технологий.

Крокфорд: Ну, скажем, уже упоминавшиеся Лисп и Smalltalk. Отличные вещи; некоторые из тех идей переходят в современные языки, и мы, работая с JavaScript, стараемся воскресить те старые идеи. Правда, в этом языке уже есть многое из того. Лексические границы и функции высшего порядка – это блестяще! А теперь мы пытаемся понять, как внедрить в него больше полезных свойств Smalltalk и Scheme, не нарушая структуру языка. Можно возразить, что лучше бросить все, над чем мы работаем, и просто вернуться к Smalltalk и Scheme; возможно, так действительно было бы лучше, но такой вариант не рассматривается.

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

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

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

Думаю, очередной скачок – как бы он ни назывался – будет связан с мэшапами, когда мы сможем брать куски разных программ, соединять их и тут же получать новую программу. Уже десятилетия ведутся разговоры о программной модели, в которой программы собирались бы наподобие конструктора LEGO. Этого пока не произошло, но уже начинает происходить в JavaScript – в наименее ожидаемом месте.

Сейбел: Как вы на собеседовании распознаете хорошего программиста?

Крокфорд: Сейчас я определяю это по чтению кода. Я предлагаю соискателю принести фрагмент его лучшего кода и пройтись по нему.

Сейбел: Что конкретно вы в нем ищете?

Крокфорд: Я ищу там качественное представление кода. Хочу понять, чем этот человек гордится. Убедиться в том, что он действительно автор того, что представил. Я понял, что это куда более эффективный способ, чем предлагать головоломки или задавать стандартные вопросы. По-моему, все это бесполезно. А вот коммуникативные способности – это то, что я ищу.

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

Крокфорд: Много читать. Есть масса хороших книг – берите и читайте. А если вы веб-разработчик, зайдите на лучшие сайты и посмотрите их код. Правда, я даю этот совет не без опаски. Большинство веб-разработчиков учились своему делу «глядя в исходники», и до недавнего времени эти исходники никуда не годились. Целое поколение программистов выросло на плохом коде, который они считают образцовым. Сейчас положение исправляется, но плохого кода все еще так много, что я боюсь давать подобный совет.

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

Крокфорд: На их месте я бы сконцентрировался на коммуникации. Учитесь писать, учитесь читать.

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

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

Крокфорд: У меня было такое, скажем, с Windows-программистами. В Windows есть ряд очень сложных API, их можно осваивать годами. И получается, что вы ничего не можете, кроме как написать обработчик оконных сообщений. Без особой необходимости я никогда не ищу таких узких специалистов. В общем случае я предпочитаю тех, кто разбирается во всем понемногу, кто способен освоить некоторый API, а не тех, кто на нем специализируется.

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

Крокфорд: У меня именно такое намерение.

Сейбел: И что из этого выходит?

Крокфорд: Большей частью мы справляемся неплохо. Мир улучшается, хотя при этом он не обязательно двигается вперед. Возьмите, к примеру, международные отношения за последние десять лет – появление Интернета не компенсировало разлагающий эффект от объединения крупных СМИ. Это большое разочарование.

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

Сейбел: Но ведь миллионы блогеров могут сказать: «Мы тут в блогах отслеживаем все, а традиционные СМИ отдыхают».

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