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

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

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

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

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

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

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

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

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

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

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

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

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

При подобном инкрементальном подходе, думаю, нас бы ждал успех. Но мы попытались сделать все одновременно, и это оказалось слишком сложной задачей.

Сейбел: Думаете, вы решили делать все одним этапом именно потому, что уже знали крупные куски будущей программы?

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

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