Ситуация ухудшается еще и тем, что есть и другие пути попадания скрипта на вашу страницу. Архитектура Сети включает несколько языков: HTTP, HTML, язык URL-адресов, CSS и язык сценариев. Все они существуют и могут встраиваться друг в друга, обладая разными правилами цитирования (quoting), экранирования (escaping) и комментирования. Не во всех броузерах все эти правила реализованы одинаково. А некоторые из этих правил могут быть вообще не определены. Из-за этого злоумышленник легко может встроить какой-либо скрипт в URL, вставить его в кусок CSS, который затем вставить в HTML, а тот - в другой скрипт и так далее.
Сейбел: Классические межсайтовые скриптовые атаки, связанные с ошибками в броузере.
Крокфорд: Именно. Это ужасно. Нам нужно что-то с этим делать, потому что оставлять все это так совершенно не хочется.
В конце концов мы открыли мэшапы. Это как раз то, чего мы пытались добиться в области программного обеспечения в течение двадцати лет: компоненты многократного использования, которые можно объединять друг с другом, как детали в конструкторе LEGO, очень быстро создавая новые приложения. Мэшапы действуют аналогичным образом, и получается великолепно: берешь что-то из Yahoo!, что-то из Google, что-то свое, что-то чье-нибудь еще и делаешь из всего этого приложение. Класс! И все это делается в броузере, прямо у тебя перед глазами. Проблема одна: каждый из этих компонентов имеет доступ к тому же, что и другие. Мы сознательно создаем условия для XSS-атак. Модель безопасности броузеров не ожидает от этого ничего хорошего и не предоставляет никаких механизмов взаимодействия при взаимном недоверии. Вся всемирная Сеть построена на сплошных ошибках. Результат - множество неприятностей.
Сейбел: Можно ли из всего этого сделать вывод, что все усилия по принятию стандарта ES4 относятся к альтернативным издержкам и все думают именно об этом, а не о том, как избавиться от имеющихся проблем?
Крокфорд: Именно так. Этот стандарт решает не ту проблему. Он решает проблему, связанную с тем, что люди ненавидят JavaScript. И я могу понять позицию Брендана Айка, поскольку он проделал потрясающую работу, но он торопился, допускал ошибки в руководстве, и в итоге вышла полная ерунда. Его ругали и поносили последние двенадцать лет за его глупость и за то, что он создал глупый язык, но все это не так. Там есть блестящие идеи, и сам Брендан - блестящий парень. Он сейчас пытается оправдаться и доказать, что действительно умен, и показать это всем с помощью языка, который будет содержать все классные возможности, которые он когда-либо видел, объединенные и работающие все вместе.
Не думаю, что именно эту проблему нам нужно сейчас решать. Я думаю, что нужно решить следующее: Всемирная Сеть поломана, и мы должны ее починить. Нам нужно решить, каким путем продвигаться вперед. И мое главное возражение против того, что собирается сделать Брендан, в том, что он всех отвлекает.
Думаю, нужно двигаться шаг за шагом. Если у нас появится модульность или возможность выбирать язык программирования, это уже будет шаг вперед. Это еще не все, что нам нужно, но гораздо больше того, что есть у нас сейчас. Потом есть такие вещи, как Caja и ADsafe, пытающиеся сделать то же самое с помощью сегодняшних технологий. Мы не можем ждать.
ADsafe создает безопасное подмножество языка JavaScript, блокируя доступ ко всему глобальному и опасному. Но даже это подмножество все еще представляет собой полезный язык. У нас все еще остаются лямбда-выражения, а они могут многое. Таким образом, это нестандартный язык. Он не позволяет использовать прототипы так, как мы уже привыкли. Но этот язык остается невероятно мощным, поскольку в нем присутствуют лямбда-выражения.
Сейбел: Возвращаясь к ES4: есть ли в нем хоть что-то, что вам нравится с точки зрения языка?
Крокфорд: В нем исправлены некоторые ошибки языка, чем следует воспользоваться. Но в этом стандарте слишком много неопробованных возможностей. Наш опыт со стандартом ES3 говорит о том, что если ошибка однажды закралась в спецификацию языка, то удалить ее невозможно. Но у нас нет опыта работы с этим языком. Никто пока не написал на нем ни одного крупного приложения.
А он будет стандартизирован и внедрен до того, как мы поймем, что он действительно работает. Думаю, мы слишком торопимся. Я бы чувствовал себя спокойнее, если бы существовали примеры его реализации и полезные приложения, написанные на нем. Вот тогда я бы сказал: "Хорошо, давайте стандартизировать язык, давайте внедрять его по всему миру". А мы все делаем в обратном порядке.
Сейбел: Google Web Toolkit (GWT) позволяет компилировать Java в JavaScript. Многие уже пробовали компилировать другие языки в JavaScript. Это правильный путь?
Крокфорд: Любопытно наблюдать, как JavaScript становится универсальной средой выполнения. Мы никогда не ожидали увидеть его в такой роли.
Сейбел: Но, как вы уже говорили, он везде. Он стал универсальной средой выполнения.
Крокфорд: Что тем более заставляет нас обратить внимание на производительность. Особенно при переходе на мобильные платформы, к которым закон Мура неприменим. Здесь уже имеет большое значение то, сколько времени мы тратим на интерпретацию. Все это дополнительные такты процессора. Так что, думаю, это должно дополнительно улучшить качество среды выполнения.
Я придирчиво наблюдаю за тем, чего достигли GWT и другие средства преобразования. С этими средствами очень трудно работать - если найдете что-нибудь работающее, вам повезло. Лично я опасаюсь использовать их, поскольку боюсь дыр в абстракциях. Если возникнут проблемы с вашим Java-кодом, или с GWT, или со сгенерированным кодом, то у вас может быть, а может и не быть возможности справиться с этим. Особенно в том случае, если предпочтете ничего не знать о JavaScript, поскольку этот язык скрыт от вас. Тогда, если что-то пошло не так, вы столкнетесь с огромными проблемами. Я пока не слышал о подобных случаях, и это значит, что те, кто этим занимается, делают всё правильно. Но такой риск определенно есть.
Сейбел: Каким бы вы хотели видеть JavaScript?
Крокфорд: Думаю, лучший способ усовершенствовать JavaScript - сделать его более компактным. Если бы можно было оставить только те возможности, которые работают действительно хорошо, убрав малозначительные или ненужные, то мы бы действительно получили заметно улучшенный язык. И я думаю, что этот же подход применим и к HTML, и к HTTP, и к CSS. Мне кажется, что работая со всеми этими стандартами, нужно выяснить, что они делают правильно, а чего в них не хватает, и на этом основании переориентировать их, а не просто добавлять новые функции поверх существующих.
Сейбел: Вечное противоречие: маленькие изящные драгоценности и расползающиеся, но полезные комья земли. Маленькую изящную драгоценность легко понять, в ней нет недостатков, но чтобы сделать что-либо, нужно построить что-то еще поверх нее. Поэтому все заново реализуют одно и то же снова и снова, что приводит к различного рода разбуханию и уродству.
Крокфорд: На самом деле все не так. Есть разработчики Ajax-библиотек, которые достигли немалой изощренности во владении языком. А есть сообщества разработчиков, которые делают черт знает что с помощью этих библиотек, и это работает. Для создателя приложений совсем не обязательно знать все свойства лямбда-выражений, чтобы извлекать из них пользу. Совсем не обязательно отказываться от языка, пытаясь исправить его ошибки.
На самом деле проблема в том, что Ajax-библиотек стало слишком много. Это следствие того, что JavaScript - очень мощный язык, потребность в подобных библиотеках очень высока, а создавать их относительно легко. Поэтому в течение какого-то времени все их и писали. Я жду, что их станет меньше, но пока напрасно. Из-за этого у нас сейчас другая проблема - библиотек столько, что разработчики не знают, какую выбрать. Думаю, все же в будущем их количество уменьшится.
Сейчас заметна тенденция сближения функциональности Ajax-библиотек. В j Query можно получить список объектов из DOM с помощью CSS-ceлекторов и затем управлять группой объектов. Это оказалось действительно хорошей идеей - вот пример того, как JavaScript кое-что делает эффективно. Да, интерфейс взаимодействия с DOM просто ужасен, но он скрыт полностью. Разработчики jQuery очень упростили программную модель и сделали это блестяще.
А теперь каждая библиотека делает то же самое - мы наблюдаем сближение функциональных возможностей. Для пользователей проблема встает еще острее, так как все труднее выбрать нужную библиотеку, поскольку все они становятся очень похожими. Но в конце концов они начнут объединяться, и в результате останется всего несколько библиотек, возможно всего одна. Думаю, одним из победителей будет Microsoft с ее библиотекой Atlas, просто потому что Microsoft всегда оказывается среди победителей. Но, по-моему, у них нет достаточной поддержки. Открытые фреймворки, похоже, намного эффективнее. Думаю, в конце концов победит один или два открытых фреймворка.
Сейбел: Сегодня вы архитектор и евангелист языка JavaScript в Yahoo!, поэтому часть вашей работы, по-видимому, в том, чтобы говорить JavaScript-программистам в Yahoo!: "Делайте так-то". Обязаны ли вы также анализировать код и проекты на соответствие общепринятым практикам кодирования и проектирования?
Крокфорд: Я всегда настаиваю на необходимости чтения кода. Думаю, чтение кода - самое полезное, что программисты могут сделать друг для друга: постоянно уделять часть своего времени чтению кода коллег. При управлении проектами программистов часто предоставляют самим себе, затем всю их работу объединяют, и если результат удается скомпилировать, то полученный продукт выпускают на рынок и забывают о нем.
Это приводит к тому, что если у вас в команде есть слабые или неуверенные в себе программисты, то это обнаруживается слишком поздно. В результате возникает риск того, что в проекте будет множество низкокачественных компонентов, которые приведут к срыву сроков, что неприемлемо. Кроме того, у вас могут быть блестящие программисты, которые оказываются недостаточно хорошими руководителями для других членов команды. Чтение кода решает обе эти проблемы.
Сейбел: Давайте поговорим о том, как читают код у вас.
Крокфорд: На каждом совещании есть ответственные за чтение кода: они разбирают и проверяют код под наблюдением остальных. Это отличная возможность для каждого понять, как его фрагменты кода будут согласовываться с фрагментами других.
Мы садимся за стол, перед каждым лежит стопка бумаг. Мы выводим код на экран и комментируем его по ходу чтения. Кто-то говорит: "Я не понимаю этот комментарий" или "По-моему, этот комментарий не описывает этот код". Это очень важно, поскольку как программист вы перестаете читать свои комментарии, не сознавая, что другому что-то может быть непонятно. Прекрасно, когда коллеги по проекту помогают поддерживать ваш код в чистоте - вы находите ошибки, которые никогда бы не нашли самостоятельно.
Думаю, час чтения кода полезнее двух недель работы тестировщиков. Это действительно эффективный способ устранения ошибок. Если у вас есть человек с большим опытом чтения кода, то новички благодаря ему узнают много такого, чего иначе не узнали бы; если же чтением занимаются новички, то код сможет дать им немало очень ценных советов.
И не нужно оставлять это на заключительный этап работы. Раньше мы откладывали чтение кода до завершающего этапа работы над проектом и никто не делал это постоянно, просто потому что мы опаздывали с выпуском проекта. Теперь я считаю, что чтением кода нужно регулярно заниматься в течение всей работы над проектом. Да, на чтение кода уходит время, но это дает множество преимуществ.
В частности, это облегчает контроль выполнения проекта, поскольку мы видим прогресс каждого участника, что позволяет довольно рано заметить, если мы вдруг начнем сбиваться с намеченного пути.
Я управлял проектами, в которых незадолго до срока сдачи люди говорили: "Все практически готово", - а затем я смотрел их код, но там еще ничего не было или была полная ерунда, или он был очень далек от завершения. Жуткое испытание для руководителя проекта, и я думаю, что чтение кода как раз помогает избежать подобных ловушек.
Сейбел: Допустим, мы читаем мой код. Выводим код на экран - и что дальше? Я буквально читаю код вслух?
Крокфорд: Да, строку за строкой, параллельно его комментируя. Именно так все и должно происходить. Когда есть время, мы читаем код построчно.
Сейбел: Вам приходилось обучать людей чтению кода? Думаю, непросто найти хороший компромисс - сделать достаточно критических замечаний и при этом не задеть самолюбие автора кода.
Крокфорд: Да, здесь требуется взаимное доверие между членами команды, и нужны четкие правила насчет того, что допустимо, а что нет. В неслаженной команде чтение кода приведет к тому, что участники просто разорвут друг друга на части. То есть в процессе чтения кода очень быстро выясняется, слаженная команда или нет. При чтении кода вы можете многое узнать и многому научиться. Поначалу процесс может казаться неестественным, но стоит войти в ритм, как это ощущение пройдет.
Другой момент: нужно писать код так, чтобы другие смогли его прочитать. Здесь важны ясность кода и стиль его написания. Благодаря этому будет постепенно улучшаться качество кода и компетентность команды в целом.
Сейбел: Что для вас делает код читаемым?
Крокфорд: Читаемость складывается из нескольких уровней. Самое простое: нужно быть последовательным в оформлении кода, всегда использовать одинаковые отступы, расставлять пробелы во всех нужных местах. У меня есть дурная привычка, приобретенная еще во времена программирования на Фортране: я использую слишком много однобук-венных переменных, а это нехорошо. Я очень стараюсь избавиться от этой привычки, но это трудно сделать.
Сейбел: Насколько это трудно? Вы пишете код, а затем перечитываете его и думаете: "Боже! Только посмотрите на все эти однобуквенные переменные!"?
Крокфорд: Я мыслю однобуквенными выражениями. Кроме того, в JavaScript есть неоспоримый аргумент, связанный с эффективностью: за скачивание лишних символов вы платите, а более короткие имена переменных помогают сделать программу компактнее.
Сейбел: Для этого есть специальные инструменты?
Крокфорд: Да, можно применить gzip - и готово, так что у меня нет оправдания. Если, просматривая свой старый код, я вижу слишком короткие имена, то при наличии времени я их исправляю. Некоторые переменные, вроде счетчиков цикла, я всегда называю i. He думаю, что когда-то стану исправлять и это. Для многих переменных длинные имена просто неоправданны.
Это первый уровень, грамматический. Как в естественных языках, английском или любом другом. Исправляешь пунктуацию, написание заглавных букв, расставляешь запятые в нужных местах. Затем начинаешь обращать внимание на более высокоуровневые вещи, такие как построение предложений, разбивка на абзацы. В языках программирования этому соответствует то, как задача разбита на набор функций или классов.
Сейбел: На какие конкретно вещи должен обращать внимание разработчик, чтобы его код легко читался?
Крокфорд: Действительно важно использовать определенное подмножество языка, особенно в JavaScript, где есть огромное количество неудачных возможностей. Но это актуально для всех языков. Будучи начинающим программистом, я читал руководство по языку программирования и старался понять каждую возможность. И то, как все их использовать. И постоянно использовал все эти возможности. А потом оказывалось, что многие из них были не самыми удачными.
Вспоминается Фортран, но это справедливо для всех языков. Иногда авторы языка допускают ошибки. С моей точки зрения, в языке Си полно ошибок.
Сейбел: Каких, например?
Крокфорд: Например, оператор switch изначально является неудачным, не нужно было делать его таким. У оператора ++ огромные проблемы в смысле безопасности, поскольку он провоцирует вас на разные хитрости и попытки сделать слишком многое в одной строке кода. В результате код становится трудным для понимания, что часто приводит к различным ошибкам, таким как переполнение буфера. Так что большинство проблем безопасности, которые мы наблюдаем в операционных системах последние пять лет, связаны с использованием оператора ++.
Обычно я вообще не использую оператор ++. Бывает, его можно использовать, но чаще нет, и мне трудно различить эти случаи в своем коде.
Сейбел: Но ведь можно возразить, что проблемы безопасности, связанные с оператором ++, возникают не из-за самого оператора ++, а из-за отсутствия проверки выхода за границу массива или из-за проблем с обычными указателями. В Java нет подобных проблем с безопасностью, поскольку если есть оператор ++ и происходит выход за границу массива, то получается исключение.
Крокфорд: Да, в Java это менее опасно. А в JavaScript такой опасности совсем нет, поскольку там отсутствуют массивы. Но в любом случае, отказавшись от этого оператора, я заметил улучшение качества моего кода, просто потому что перестал записывать выражения в одну строку.
Другой пример - оператор continue. Я еще не встретил ни одного фрагмента кода, который не смог бы улучшить, выкинув оператор continue. Да, с его помощью легче создать какую-то сложную конструкцию. Но я заметил, что всегда могу улучшить эту конструкцию, найдя способ выкинуть его. Так что лично я никогда не использую оператор continue. Если же я вижу continue в своем коде, значит, что-то недодумал.
Сейбел: Как вы читаете чужой код?