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

Сейбел Питер

Сейбел: Каким бы вы хотели видеть JavaScript?

Крокфорд: Думаю, лучший способ усовершенствовать JavaScript — сделать его более компактным. Если бы можно было оставить только те возможности, которые работают действительно хорошо, убрав малозначительные или ненужные, то мы бы действительно получили заметно улучшенный язык. И я думаю, что этот же подход применим и к HTML, и к HTTP, и к CSS. Мне кажется, что работая со всеми этими стандартами, нужно выяснить, что они делают правильно, а чего в них не хватает, и на этом основании переориентировать их, а не просто добавлять новые функции поверх существующих.

Сейбел:

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

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

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

Сейчас заметна тенденция сближения функциональности Ajax-библиотек. В j Query можно получить список объектов из DOM с помощью CSS-ceлекторов и затем управлять группой объектов. Это оказалось действительно хорошей идеей — вот пример того, как JavaScript кое-что делает эффективно. Да, интерфейс взаимодействия с DOM просто ужасен, но он скрыт полностью. Разработчики jQuery очень упростили программную модель и сделали это блестяще.

А теперь каждая библиотека делает то же самое — мы наблюдаем сближение функциональных возможностей. Для пользователей проблема встает еще острее, так как все труднее выбрать нужную библиотеку, поскольку все они становятся очень похожими. Но в конце концов они начнут объединяться, и в результате останется всего несколько библиотек, возможно всего одна. Думаю, одним из победителей будет Microsoft с ее библиотекой Atlas, просто потому что Microsoft всегда оказывается среди победителей. Но, по-моему, у них нет достаточной поддержки. Открытые фреймворки, похоже, намного эффективнее. Думаю, в конце концов победит один или два открытых фреймворка.

Сейбел: Сегодня вы архитектор и евангелист языка JavaScript в Yahoo!, поэтому часть вашей работы, по-видимому, в том, чтобы говорить JavaScript-программистам в Yahoo!: «Делайте так-то». Обязаны ли вы также анализировать код и проекты на соответствие общепринятым практикам кодирования и проектирования?

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

Это приводит к тому, что если у вас

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

Сейбел: Давайте поговорим о том, как читают код у вас.

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

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

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

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

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

Я управлял проектами, в которых незадолго до срока сдачи люди говорили: «Все практически готово», — а затем я смотрел их код, но там еще ничего не было или была полная ерунда, или он был очень далек от завершения. Жуткое испытание для руководителя проекта, и я думаю, что чтение кода как раз помогает избежать подобных ловушек.

Сейбел: Допустим, мы читаем мой код. Выводим код на экран — и что дальше? Я буквально читаю код вслух?

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

Сейбел: Вам приходилось обучать людей чтению кода? Думаю, непросто найти хороший компромисс — сделать достаточно критических замечаний и при этом не задеть самолюбие автора кода.

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