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

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

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

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

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

У меня страшная аллергия на всякого рода эзотерические решения, шаблоны проектирования, доступные немногим. Питер Норвиг, работая в Harlequin, сказал о том, что шаблоны проектирования - всего лишь дефекты в вашем языке. Возьмите язык получше! И он был абсолютно прав. Что это такое - молиться на шаблоны, постоянно думая, какой бы из них применить!

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

Айк: Так бывает и нередко. Иногда очень сложно отказаться от кода и вернуться, чтобы начать все заново, - попадаешь в ловушку обязательств. У меня было такое с JavaScript. Я написал интерпретатор байт-кода в страшной спешке, и делая это, я уже понимал, что кое о чем пожалею. Но то было решение, понятное для других, и я надеялся, что другие помогут мне с этой программой. Поэтому о проектном решении я думаю всегда - не каждый раз мы можем позволить себе роскошь пересматривать фундаментальные основы кода. А именно это случается при масштабном переписывании.

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

Айк:В Netscape хотели, чтобы приобретенная ими компания, потрясавшая известной книгой о шаблонах проектирования, вывела их на первое место благодаря новому движку рендеринга, который стал бы для всех ориентиром. Сверху это смотрелось хорошо: там использовались C++ и шаблоны проектирования. Но было множество проблем.

А вот вторая причина того, что мы взялись за переписывание: я трудился в mozilla.org и был сильно недоволен Netscape, как и Джейми, - тот вообще собирался уходить. Я считал, что нужно пустить на наше поле новых работников, а со старым запутанным кодом, сделанным на коленке в 1994 году, сделать это было нельзя. И с моим прекрасным кодом интерпретатора в стиле ядра UNIX.

Нам нужна была большая перезагрузка. Четыре года с момента выпуска программы! Не говоря ничего такого топ-менеджерам, поскольку они и слушать об этом не желали, мы стали искать оптимальное решение за них. В итоге полетело несколько топ-менеджерских голов. Правда, менеджеры, в отличие от меня, все равно сказочно заработали на опционах. Но для Mozilla это было выгодно.

Сегодня можно назвать это удачей, поскольку развитие Сети ускорилось. Видимо, Microsoft - некоторые утверждают, что это было связано скорее с антимонополистскими расследованиями, чем с желанием его руководителей, - хотела плотно оседлать Сеть и не допустить ее эволюции. Это дало нам возможность заняться переписыванием, размахивая знаменем стандартов (довольно сомнительный ход, особенно с учетом качества стандартов). Как и Джоэл, я скептично смотрю на переписывание. Трудно примирить все интересы, найти деньги и при этом правильно отреагировать на требования рынка. Исключений единицы.

Те случаи переписывания, о которых я говорил раньше, связаны с прототипами. Это крайне важно, а объем работы намного меньше. Можно порезать кучу кода, не очень много по числу строк, но с большими последствиями, и удовлетворить всем нужным инвариантам. Или это компиляция “на лету”, или еще что-то, что позволяет решить задачу.

Сейбел:Вы занимались литературным программированием в духе Кнута?

Айк:Я делал кое-что наподобие его первоначальных программ - просто классно, мне очень нравилось. Это было извлечение слов. Там было некое подобие древовидного хеша, программирование было целиком литературным. Потом Дуг Макилрой сделал все то же самое, только с конвейером.

Наши программы подробно откомментированы, но нет средства изъять из них прозу и проверить ее - хотя бы вручную - относительно кода. Разработчики Python сделали в этом смысле кое-что интересное. Все что я сделал - не более чем подробное комметирование. Я периодически обновляю старые комментарии, но это тяжело, и иногда мне это не удается, и я жалею, что кто-то из-за меня получил неверную информацию.

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

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