Пол Грэм: «The Other Road Ahead», часть 1

«Для Viaweb мы часто делали три-пять версий в день.»
— Пол Грэм, разработчик, инвестор, эссеист.

Мне было любопытно познакомиться с прогнозом основателя самого влиятельного бизнес-инкубатора кремниевой долины (Y combinator). Спустя 15 лет с момента публикации эссе Пола Грэма, благодаря компании Edison и отличным людям с Хабра, руки дошли до перевода. Для тех, кому интересно, как происходило зарождение нового продукта и как три программиста бодались с гигантами индустрии, добро пожаловать под кат.

Пол Грэм, Роберт Моррис и Тревор Блэквел в 1995

Очередная глава книги «Хакеры и художники» (которая уже почти полностью переведена на русский)

Другая дорога в будущее

Сентябрь 2001
Оригинал — The Other Road Ahead
(За перевод плюсик в карму knagaev)

(Эта статья объясняет почему многое в ПО следующего поколения может быть реализовано на серверной стороне, что это будет значить для программистов, и почему этот новый вид ПО будет хорошей возможностью для стартапов. Источниками статьи были диалоги в BBN Labs.)

Летом 1995-го я со своим другом Робертом Моррисом (Robert Morris) решили запустить стартап. PR-кампания перед IPO Netscape тогда шла полным ходом, и в прессе было полно разговоров об электронной коммерции. На тот момент в сети уже было порядка тридцати реальных электронных магазинов, и все они были сделаны вручную. Если в скором времени в сети должно было появиться множество онлайн-магазинов, была потребность в ПО для их разработки, и мы решили такое написать.

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

Оказалось, что это был отличный план. Теперь, как Yahoo Store, это ПО является самым популярным конструктором онлайн-магазинов, с ним работает порядка 14 тысяч пользователей.

Когда мы начинали разработку Viaweb, почти никто не понимал что мы имеем в виду, когда говорим, что ПО будет работать на сервере. Так было до тех пор, пока через год не запустился Hotmail, и люди начали его использовать. Теперь все знают, что это разумный подход. Теперь есть название для того, чем мы тогда были: провайдер приложений (Application Service Provider или ASP).

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

Новое устройство?

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

Компьютеры сейчас на таком же этапе развития. Для того, чтобы пользоваться персональным компьютером, вы вынуждены изучить намного больше, чем вообще хотите знать что происходит внутри него. Однако компьютерами владеют более половины домохозяйств в Штатах. Моя мама пользуется компьютером для переписки по электронной почте и ведения счетов. Около года назад она была встревожена, когда получила от Apple письмо, в котором ей предлагали скидку при покупке новой версии операционной системы. Очевидно что-то не в порядке, если шестидесятипятилетняя женщина, которая хочет пользоваться только электронной почтой и счетами, вынуждена думать об установке новых версий операционной системы. Обычные пользователи не должны даже знать о терминах «операционная система», не говоря уж о «драйвер устройства» или «патч».

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

С веб-приложениями большинство пользователей не будут должны думать о чём-то ещё, кроме самих приложений. Все сложные и меняющиеся составляющие будут находиться где-то на сервере и обслуживаться специально обученными специалистами. И более того, вам вообще может быть не нужен компьютер, чтобы пользоваться приложением. Всё, что вам потребуется, это что-то с клавиатурой, экраном и веб-браузером. Возможно с беспроводным доступом в Интернет. Возможно этим будет ваш мобильный телефон. Чем бы это ни было, это будет бытовой техникой: будет стоить около $200, и выбирать будут, исходя из внешнего вида. Вы будете больше платить за доступ в Интернет, чем за оборудование, так же, как сейчас это происходит с телефонами [1].

Время отклика сервера на действие пользователя составляет порядка десятой доли секунды, поэтому пользователи тяжёлого интерактивного ПО (например, Photoshop) по-прежнему будут хотеть, чтобы вычисления шли на локальной машине. Но если вы посмотрите для чего большинство людей использует компьютеры, то согласитесь, что время отклика в секунду не будет для них проблемой. Моей маме на самом деле персональный компьютер не нужен, и большинству людей тоже.

Польза для пользователей

Недалеко от моего дома стоит машина с наклейкой «лучше смерть, чем неудобство». Большинство людей в большинстве случаев выбирают то, что требует меньше усилий. Если веб-приложения победят, то это будет потому что они более удобные. Причём как для пользователей, так и для разработчиков.

Чтобы использовать чистое веб-приложение, всё, что вам понадобится, это веб-браузер, имеющий доступ в Интернет. Поэтому вы можете использовать веб-приложение откуда угодно. Когда вы устанавливаете софт на свой ПК, вы можете пользоваться им только на этом ПК. Хуже того, ваши файлы заперты в этом ПК. Неудобство этой модели становиться всё более очевидным для людей, которые пользуются сетями.

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

Сама идея «Вашего компьютера» исчезает и заменяется «Вашими данными». У вас должен быть доступ к своим данным с любого компьютера. Или даже с любого устройства, и устройство не обязательно должно быть компьютером.

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

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

Посколько установка не требуется, попробовать софт перед покупкой станет легко и просто стандартным подходом. Должно стать возможно бесплатно потестировать приложение просто зайдя на сайт, где оно продаётся. Сайт Viaweb можно представить как один большой указатель на предложение пользователям тест-драйва.

После демо-версии подписка на сервис не должна потребовать ничего, кроме заполнения короткой формы (чем короче, тем лучше). И это должно быть последнее, что требуется от пользователя. Используя веб-приложения, вы должны получать обновления без доплаты, без каких-либо действий, или даже без уведомлений.

Апгрейды больше не будут такими шокирующими, как сейчас. С течением времени приложения будут незаметно становиться более мощными. Это потребует некоторых усилий со стороны программистов. Они будут должны проектировать приложения так, чтобы обновления не отражались на пользователях. Это новая задача, но пути её решения существуют.

С веб-приложениями все используют одну и ту же версию, и баги могут исправляться сразу после обнаружения. Поэтому веб-приложения должны иметь значительно меньшее количество багов по сравнению с приложениями на ПК. Сомневаюсь, что в Viaweb бывало больше, чем десять багов одновременно. Это на несколько порядков лучше, чем в случае приложений для ПК.

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

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

Ну и последнее, веб-приложения должны быть менее уязвимы для вирусов. Если на терминале не запускается ничего, кроме браузера, меньше шансов получить вирус, и локальных данных, которые можно повредить, тоже нет. А программа, атакующая сами серверы, обнаружит их очень хорошо защищенными [2].

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

Город кода

Для разработчиков самое явное отличие веб-софта от «обычного» в том, что веб-софт не состоит из одного цельного куска кода. Он будет представлять собой набор программ различного типа, а не один большой бинарник. Так что проектирование веб-приложений будет похоже на проектирование города, а не проектирование здания: помимо зданий вам понадобятся дороги, дорожные указатели, ремонтные, полицейские и пожарные службы, а также планы развития и ликвидации катастроф.

В Viaweb программный пакет состояло из сравнительно больших приложений, с которыми непосредственно работают пользователи, из программ, которые используют эти приложения, из программ, которые постоянно работают в фоне для определения проблем, из программ, которые пытаются рестартовать то, что сбойнуло, из программ, которые запускаются время от времени, чтобы собрать статистику или построить поисковые индексы, из программ, которые запускаются вручную для сборки мусора или для перемещения/восстановления данных, из программ, которые имитируют пользователей (для измерения производительности или поиска ошибок), из программ для диагностики сетевых аварий, из программ, выполняющих резервное копирование, из интерфейсов к внешним сервисам, из программ, которые управляют впечатляющей коллекцией циферблатов, показывающих статистику сервера в реальном времени (необходимые не только не только пользователям, но и нам), изменения (в том числе багфиксы) в открытом ПО и из огромного количества конфигурационных файлов и настроек. После того, как мы были куплены Yahoo, Тревор Блекуэлл (Trevor Blackwell) написал эффектную программу для переноса магазинов на новые серверы, расположенные в другой точке страны, без их выключения. Программы посылают нам пейджинговые сообщения, посылают факсы и электронную почту пользователям, собирают транзакции процессинга кредитных карт, и взаимодействуют с другими программами через сокеты, пайпы, http-запросы, ssh, пакеты udp, разделяемую память и файлы. Часть Viaweb даже состоит из «отсутствия» программ, так как один из ключевых принципов безопасности Unix — не позволять запускать лишних утилит, которые можно использовать для взлома серверов.

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

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

Так как программное обеспечение в веб-приложениях будет представлять собой пакет программ, а не единый исполняемый файл, они могут быть написаны на нескольких языках программирования. Когда вы пишете персональный софт, вас практически заставляют писать на том же языке, на котором написана операционная система, то есть С или С++. Поэтому эти языки рассматриваются (особенно нетехническими сотрудниками, например, менеджерами или вице-президентами) как языки для «серьёзной» разработки. Но это является просто стереотипом, сложившимся в сфере разработки персонального софта. Для приложений, размещающихся на сервере, вы можете использовать любой язык какой захотите.[3] Сейчас многие программисты высшего класса используют языки, очень далекие от С и С++: Perl, Python или даже Lisp.

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

Большинство наших конкурентов используют С и С++, что делает их ПО заметно хуже, потому что (помимо других проблем) они не могут работать с отсутствием состояния CGI скриптов. Если вы собираетесь что-то изменить, все изменения должны происходить на одной странице с кнопкой «Изменить» внизу. Так как я использовал Lisp, который многие по-прежнему считают языком для исследований, мы смогли сделать редактор Viaweb похожим на десктопное приложение.

Версии

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

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

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

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

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

Персональный софт воспитывает определенный фатализм по отношению к багам. Вы знаете, что поставляете его с багами, и даже определяете механизмы их устранения (например, патчи исправлений). Так чего ради беспокоиться, что их будет немного больше? И вскоре вы обнаруживаете, что все элементы, о которых вы знаете, не работоспособны. Apple в этом году столкнулась с такой ситуацией. Они чувствовали нажим по отношению к выпуску новой версии операционной системы, который уже четыре раза откладывался, но некоторые составляющие (поддержка CD и DVD) еще не были готовы. И решение? Они выпустили версию без этих составляющих, и пользователи будут устанавливать их позднее.

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

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

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

К тому времени когда нас купили, мы проделали это три раза, и были на версии 4. Версии 4.1, если не подводит память. После того, как Viaweb стал Yahoo Store, острая необходимость в популяризации отпала, и хоть система и продолжала эволюционировать, сама идея с номерами версий была тихо похоронена.

Баги

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

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

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

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

Устранение свежих ошибок намного легче, чем устранение старых. Как правило, значительно легче искать ошибку в коде, который вы только что написали. Когда ошибка появляется, вы часто можете определить что не так даже до того, как полезете в код, потому что это еще находится в подсознании. Исправление бага в коде, который вы написали полгода назад (средний срок, если версия выпускается раз в год), потребует намного больше усилий. И так как вы уже не чувствуете код так же хорошо, скорее всего, вы сделаете исправление не лучшим образом, а то и добавите других багов. [4]

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

В этом помогает техника функционального программирования. ФП значит избегать побочных эффектов. Это что-то, более подходящее для научных исследований, чем для коммерческого ПО, но в случае веб-приложений оно превращается в по-настоящему полезную идею. Целиком программу трудно написать в чисто функциональном коде, но вы можете писать в таком стиле отдельные блоки. Такие части вашего приложения легче тестировать, поскольку у них нет состояния, а это очень удобно в случае, когда вы постоянно делаете и тестируете небольшие изменения. Я написал большую часть редактора Viaweb в таком стиле, и мы создали собственный скриптовый язык RTML как чисто функциональный язык.

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

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

Поддержка

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

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

Так что в Viaweb разработчики всегда были в тесном контакте с поддержкой. Сотрудники поддержки сидели в десяти метрах от программистов, и они знали, что могут в любой момент побеспокоить сообщением о новом баге. Мы могли прервать совещание совета директоров ради исправления серьёзной ошибки.

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

Наша политика устранения ошибок на лету изменила отношения между сотрудниками поддержки и высококлассными программистами. В большинстве компаний в поддержке работают низкооплачиваемые «вахтеры», а программисты — это маленькие копии Бога-Отца, творцы Вселенной. Какова бы ни была процедура сообщения об ошибках, она, скорее всего, направлена в одну сторону: сотрудник поддержки, который получил сведения об ошибке, записывает их в какую-либо форму и через некоторое время пересылает (возможно через службу качества) программистам, которые ставят их в план работы. Это было совершенно не так в Viaweb. В течение минуты после получения сообщения об ошибке от пользователя сотрудник поддержки мог уже стоять рядом с программистом и слышать от него «Черт, ты прав, это баг». Сотруднику поддержки было очень приятно услышать «ты прав» от суперспециалиста. Они привыкли приносить нам баги с тем же выражением лица, которое бывает у кота, несущего вам только что убитую мышь. Это также делало их более осторожными в оценках важности ошибки, потому что их реноме ставилось на карту.

После того, как мы были куплены Yahoo, сотрудники поддержки переехали далеко от программистов. Только тогда мы почувствовали что они были фактически сотрудниками службы качества и в некоторой степени маркетинга. Помимо отлова багов они были хранителями знаний о неясных багоподобных штучках, которые путали пользователей. [6] Еще они были в некотором роде фокус-группой представителей пользователей; мы могли спросить их какую из двух новых фич пользователи хотят больше, и они всегда оказывались правы.

Продолжение следует.

[1] Понимая, что бОльшая доля денег в предоставлении услуг, компании, разрабатывающие тонкие клиенты, обычно пытаются объединять аппаратные решения с онлайн-решениями. Этот подход не очень хорош, частично из-за того, что вам необходимы две различных фирмы, одна из которых будет разрабатывать аппаратную часть, а вторая предоставлять онлайн-услуги, и частично потому что пользователи ненавидят эту идею. Продавать дёшево бритвы и зарабатывать потом на продажах лезвий может себе позволить Gilette, но бритва — это намного меньшее вложение, чем веб-терминал. Компаниям, продающим мобильные телефоны, хватает выручки от продажи устройств, и они не пытаются получить весь доход от телефонной связи. Вероятно это должно быть моделью и для интернет-устройств. Если кто-то просто продаёт красивую маленькую коробочку с веб-браузером, которую вы можете использовать с любым интернет-провайдером, каждый обыватель купит себе такую.

[2] Безопасность всегда боится ошибок, больше, чем любые другие проектные решения, но характер серверного ПО заставляет разработчиков уделять ещё больше внимания защите от взлома. Компрометация сервера может нанести такой значительный ущерб, что провайдеры приложений (которые не хотят прогореть) должны позаботиться о безопасности.

[3] В 1995 году, когда мы начинали Viaweb, Java-апплеты рассматривались как технология, которую все будут использовать для разработки серверных приложений. Нам апплеты казались устаревшей идеей. Загружать для запуска программы на клиента? Проще дойти до логического конца и запускать программы на сервере. Мы немного потратили времени на апплеты, но исчезающе мало по сравнению с другими стартапами, которых заманили в эту смоляную яму. Немногие смогли оттуда выбраться живыми, или Microsoft не смогла сбежать, выбросив поддержку Java из своих последних версий IE.

[4] Эта идея от Тревора Блекуэлла (Trevor Blackwell), который добавил «стоимость создания ПО растет быстрее, чем его размер. Воможно это главным образом по причине необходимости исправления старых багов, и рост стоимости будет ближе к линейному, если все баги будут отыскиваться немедленно.»

[5] Баг, который найти труднее всего, может быть видом составного бага, когда действие одного бага компенсируется действием другого. Когда вы исправляете один баг, другой проявляет себя. Но кажется, что исправление является причиной ошибки, так как это последнее изменение, которое вы сделали только что.

[6] В Viaweb однажды мы устроили соревнование на описание худшей проблемы в нашем софте. Два сотрудника поддержки разыграли между собой первый приз, указав на такие вещи, которые я до сих пор вспоминаю с содроганием. Мы тут же устранили эти ошибки.

---

Хакеры и художники

Автор: Edison

Источник