Сейбел: Вечное противоречие: маленькие изящные драгоценности и расползающиеся, но полезные комья земли. Маленькую изящную драгоценность легко понять, в ней нет недостатков, но чтобы сделать что-либо, нужно построить что-то еще поверх нее. Поэтому все заново реализуют одно и то же снова и снова, что приводит к различного рода разбуханию и уродству.
Крокфорд: На самом деле все не так. Есть разработчики Ajax-библиотек, которые достигли немалой изощренности во владении языком. А есть сообщества разработчиков, которые делают черт знает что с помощью этих библиотек, и это работает. Для создателя приложений совсем не обязательно знать все свойства лямбда-выражений, чтобы извлекать из них пользу. Совсем не обязательно отказываться от языка, пытаясь исправить его ошибки.
На самом деле проблема в том, что Ajax-библиотек стало слишком много. Это следствие того, что JavaScript — очень мощный язык, потребность в подобных библиотеках очень высока, а создавать их относительно легко. Поэтому в течение какого-то времени все их и писали. Я жду, что их станет меньше, но пока напрасно. Из-за этого у нас сейчас другая проблема — библиотек столько, что разработчики не знают, какую выбрать. Думаю, все же в будущем их количество уменьшится.
Сейчас заметна тенденция сближения функциональности Ajax-библиотек. В j Query можно получить список объектов из DOM с помощью CSS-ceлекторов и затем управлять группой объектов. Это оказалось действительно хорошей идеей — вот пример того, как JavaScript кое-что делает эффективно. Да, интерфейс взаимодействия с DOM просто ужасен, но он скрыт полностью. Разработчики jQuery очень упростили программную модель и сделали это блестяще.
А теперь каждая библиотека делает то же самое — мы наблюдаем сближение функциональных возможностей. Для пользователей проблема встает еще острее, так как все труднее выбрать нужную библиотеку, поскольку все они становятся очень похожими. Но в конце концов они начнут объединяться, и в результате останется всего несколько библиотек, возможно всего одна. Думаю, одним из победителей будет Microsoft с ее библиотекой Atlas, просто потому что Microsoft всегда оказывается среди победителей. Но, по-моему, у них нет достаточной поддержки. Открытые фреймворки, похоже, намного эффективнее. Думаю, в конце концов победит один или два открытых фреймворка.
Сейбел: Сегодня вы архитектор и евангелист языка JavaScript в Yahoo!, поэтому часть вашей работы, по-видимому, в том, чтобы говорить JavaScript-программистам в Yahoo!: «Делайте так-то». Обязаны ли вы также анализировать код и проекты на соответствие общепринятым практикам кодирования и проектирования?
Крокфорд: Я всегда настаиваю на необходимости чтения кода. Думаю, чтение кода — самое полезное, что программисты могут сделать друг для друга: постоянно уделять часть своего времени чтению кода коллег. При управлении проектами программистов часто предоставляют самим себе, затем всю их работу объединяют, и если результат удается скомпилировать, то полученный продукт выпускают на рынок и забывают о нем.
Это приводит к тому, что если у вас в команде есть слабые или неуверенные в себе программисты, то это обнаруживается слишком поздно. В результате возникает риск того, что в проекте будет множество низкокачественных компонентов, которые приведут к срыву сроков, что неприемлемо. Кроме того, у вас могут быть блестящие программисты, которые оказываются недостаточно хорошими руководителями для других членов команды. Чтение кода решает обе эти проблемы.
Сейбел: Давайте поговорим о том, как читают код у вас.
Крокфорд: На каждом совещании есть ответственные за чтение кода: они разбирают и проверяют код под наблюдением остальных. Это отличная возможность для каждого понять, как его фрагменты кода будут согласовываться с фрагментами других.
Мы садимся за стол, перед каждым лежит стопка бумаг. Мы выводим код на экран и комментируем его по ходу чтения. Кто-то говорит: «Я не понимаю этот комментарий» или «По-моему, этот комментарий не описывает этот код». Это очень важно, поскольку как программист вы перестаете читать свои комментарии, не сознавая, что другому что-то может быть непонятно. Прекрасно, когда коллеги по проекту помогают поддерживать ваш код в чистоте — вы находите ошибки, которые никогда бы не нашли самостоятельно.