Ошибочно считать, что во второй раз будет затрачено столько же времени, сколько и в первый раз, хотя есть и противоположные примеры. Это так называемая проблема второй системы: когда те, кто уже чего-то достиг, получают задание начать все с чистого листа и делать то, что считают нужным. Обычно это ведет к провалу, поскольку люди становятся слишком амбициозными в своих целях и не видят границ. В результате вы не получаете ничего. Нужна невероятная дисциплина, чтобы можно было сказать: «Нет, мы не начинаем с чистого листа, а заново реализуем то, что уже сделали ранее; давайте делать то, что мы уже знаем».
Одна из главных трудностей программирования в том, что мы обычно занимаемся тем, чем никогда прежде не занимались. Если мы имеем дело с чем-то, что уже делали, то используем это повторно. Но в основном мы делаем то, чего никогда раньше не делали. А создавать что-то, чего никогда не делал, сложно. Заниматься этим очень интересно, но весьма непросто. Особенно когда работаешь по классической методике и должен классифицировать систему, которую до конца не понимаешь. В этом случае очень высока вероятность сделать неправильную классификацию.
Сейбел: Под «классической» методикой вы подразумеваете применение классов?
Крокфорд: Да. Мне кажется, что в мире прототипирования проблем гораздо меньше, поскольку там делается акцент на экземплярах. Найдешь экземпляр, типичный с точки зрения решаемой задачи, и готово. В таком случае решение не приходится адаптировать. Но в классических системах это невозможно — там всегда идешь от абстракций к экземплярам. И очень непросто создать правильную иерархию. Так что зачастую приходится возвращаться и перерабатывать свое решение, когда в конце концов лучше поймешь проблему. Но это может серьезно повлиять на код, особенно если он разросся по сравнению с первоначальной концепцией. Поэтому не делаешь ничего серьезного, пытаясь прикрутить что-то новое поверх уже существующей иерархии, и все еще больше запутывается и ухудшается.
Сейбел: Но ведь вы считаете рефакторинг кода полезным, раз советуете посвящать ему каждый седьмой цикл? И тогда необходимость в серьезном переписывании отпадает.
Крокфорд: Да, я считаю его полезным. Можно подумать о том, чтобы выкинуть все и начать сначала, только в том случае, когда это писал не ты или сделал это плохо, что-то пошло не так, и в результате получилась база кода, с которой невозможно работать. Всегда можно прикинуть, что быстрее — переписать все заново или вносить исправления.
Сейбел: А как быть с проблемой, когда не полностью понимаешь назначение того кода, который собираешься переписывать? Ведь каждый фрагмент кода несет в себе кусочки знаний — маленькие, неприметные кусочки, которые на самом деле являются частицами дорого доставшейся функциональности, о которой не думаешь, решая все переписать.
Крокфорд: Да, это серьезная проблема. Одна из причин, почему в Сети творится такая неразбериха, — отсутствие спецификаций. Спецификации были неполными, при этом еще и трактовались зачастую неверно, и многие из-за неверного понимания стали частью общепринятых правил. Все эти системы значительно сложнее, чем могли бы быть, именно благодаря историческим причинам. Работая на этом уровне, я, конечно, тепло отношусь к этим недокументированным знаниям, которые содержит исходный код.
У Microsoft аналогичная проблема с операционными системами: они годами выпускали лажу, делая ее совместимой с прежней лажей, основанной на всей лаже, созданной раньше. Поэтому ограничения, которые накладывают старые системы при проектировании новых, просто ужасны. В такой обстановке действительно сложно двигаться вперед. В конце концов они могут обнаружить, что двигаться вперед просто невозможно.
Подобные ошибки в спецификации — действительно очень и очень серьезная проблема. У нас есть такие проблемы в мире Ajax. Основные трудности, связанные с Ajax, заключаются главным образом в отличиях на уровне браузеров. Разработка кроссбраузерных приложений значительно сложнее, чем могла бы быть, именно из-за отсутствия полноценной спецификации Сети, а также из-за существенных различий в реализациях.
В последние пять лет ситуация значительно улучшилась, особенно с появлением Ajax-библиотек. Большинство из них делают очень полезные вещи, хотя и не все, что нужно, но достаточно для повышения вашего уровня как программиста. Теперь не нужно копаться во внутренностях браузера, для этого у нас есть нечто вроде виртуального слоя, на основе которого можно разрабатывать весьма гибкие и переносимые приложения. Здесь, в Yahoo!, у нас есть команда, основная задача которой — работа с проблемами, связанными с браузерами. Хорошая работа этой команды значительно облегчает жизнь другим нашим разработчикам.