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

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

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

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

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

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

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

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

Подобные ошибки в спецификации — действительно очень и очень серьезная проблема. У нас есть такие проблемы в мире Ajax. Основные трудности, связанные с Ajax, заключаются главным образом в отличиях на уровне браузеров. Разработка кроссбраузерных приложений значительно сложнее, чем могла бы быть, именно из-за отсутствия полноценной спецификации Сети, а также из-за существенных различий в реализациях.

В последние пять лет ситуация значительно улучшилась, особенно с появлением Ajax-библиотек. Большинство из них делают очень полезные вещи, хотя и не все, что нужно, но достаточно для повышения вашего уровня как программиста. Теперь не нужно копаться во внутренностях браузера, для этого у нас есть нечто вроде виртуального слоя, на основе которого можно разрабатывать весьма гибкие и переносимые приложения. Здесь, в Yahoo!, у нас есть команда, основная задача которой — работа с проблемами, связанными с браузерами. Хорошая работа этой команды значительно облегчает жизнь другим нашим разработчикам.

Сейбел: С другой стороны, переписывание системы не всегда срабатывает. Ранее вы упомянули эффект второй системы, а в другом интервью назвали это явление в действии «душераздирающим зрелищем». Когда это случилось?

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

Сейбел: Речь шла о переделке Habitat?

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

Сейбел: Как вы думаете, тот совет, который вы дали чуть раньше, — быть достаточно дисциплинированными, чтобы реализовать заново только то, что действительно понимаешь, — мог уберечь от беды?