Руководство по UI дизайну для программистов

       

По главной улице без оркестра


Joel on Software   Джоэл о программном обеспечении

 

По главной улице без оркестра



Автор: Джоэл Сполски

Переводчик: Маргарита Исаева

Редактор: Дмитрий Жемеров

2 декабря 2000

До недавнего времени лицензия нашей компании на программу запрещала её "разборку" (reverse engineering), т.е. попытки взглянуть на исходный код или модифицировать его каким-либо образом. Разные честные пользователи спрашивали, сколько мы хотим за лицензию на исходный код, чтобы они могли подправить пару вещей под свои задачи.

Хм... А почему вообще лицензия запрещает трогать исходники? Я не мог привести ни одного аргумента "против". Наоборот, я нашел достаточно аргументов "за" и немедлено изменил лицензионное соглашение. Так что теперь сидите и слушайте "историю старого ворчуна" из моего прошлого опыта.

Некоторое время тому назад, в 1995 году, я работал в Viacom'е, где наша небольшая группа отважных первопроходцев строила веб сайты для разнообразных Viacom'овских надобностей.

В те дни серверов приложений еще не было. Ребята из Sybase, когда вы говорили, что хотите использовать их БД в Интернете, настолько не въезжали в тему, что предлагали вам приобрести 150-долларовую лицензию для каждого пользователя, который подключается к вашему сайту. Netscap'овскому веб-серверу оставалось совсем чуть-чуть до версии 1.0.

И тут бравая компания Illustra стала всем объяснять, что ее СУБД прекрасно подходит для Веба. Illustra, знаете ли, позволяла легко добавлять новые типы данных путем написания кода на Си и подключения его к их СУБД. (Любой программист, который работал с СУБД, скажет вам, что это уже звучит достаточно подозрительно и опасно. Программа на Си? Которая вызывается из СУБД? Ой). Изначально все это задумывалось для таких интересных типов данных, как широта/долгота, временные ряды и т.п. А потом случился Веб. Illustra написала нечто под названием "Web Blade" и прилинковала его куда надо. "Web Blade" была недоделанной системой, которая якобы позволяла извлекать данные из БД и создавать динамические страницы "на лету", что в 1995 году было для всех главной проблемой.

Один мой коллега отвечал за построение сайта, посредством которого Blockbuster мог бы продавать — я не шучу — CD через Интернет. (Ведь именно это проходит в голову, когда думаешь про Blockbuster, правильно?) Короче, он решил, что Иллюстрa превосходно подойдет для этой задачи. Однако Иллюстра стоила что-то около 125 тыс. долларов, и вытрясти такую кучу денег из Viacom'а — это все равно что уговорить верблюда пройти через игольное ушко, т на это ушло определенное время. Мой коллега завел у себя в кабинете бумажный стаканчик с надписью "В фонд Иллюстры" и таким образом собирал по нескольку долларов в день. Босс вел тяжелые, продолжительные переговоры с Иллюстрой, и в конце концов соглашение было достигнуто. Мы инсталлировали Иллюстру и принялись за работу.

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

"Только пожалуйста, можно без Иллюстры"? — взмолился я.

"Ээээ... ну хорошо, но что же ты собираешься использовать взамен?" Никаких других серверов приложений в те дни не было. Не было ни PHP, ни AOLServer с TCL, Perl запускал по процессу на каждый запрос, и пенициллина у нас тоже не было, и вообще жизнь была ужасна.

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

Вот тогда я и получил один из главных уроков в области программной архитектуры: для наиболее ответственных, критических задач вы должны использовать инструмент одним уровнем абстракции ниже, чем это было бы в идеале. Например, если вы пишете крутую трехмерную стрелялку (такую, как Quake, который вышел примерно тогда же) и вы планируете оставить конкурентов далеко позади с помощью крутейшей трехмерной графики, не используйте первую попавшуюся графическую библиотеку. Пишите свою собственную, потому что это фундамент вашей работы . Те, кто использует 3D библиотеки, такие как DirectX, делают это, потому что они пытаются выиграть на чем-то другом, отличном от качественной графики (может быть, на сюжете игры).

Именно тогда я решил больше не доверять никакому промежуточному серверу приложений, а написать мой собственный, на С++, используя библиотеку низкого уровня Netscape сервера. Потому что, по крайней мере, я знал, что если что-то пойдет не так, то проблема в моем коде, и я в состоянии ее устранить.

И это одно из самых важных преимуществ программ с открытым кодом (open source/free software), даже если вы можете себе позволить отвалить 125 тыс. долларов за Иллюстровский оркестр: по крайней мере, если что-то пойдет не так, вы сумеете это дело исправить хоть как-то, и вас не уволят, и все эти замечательные-хотя-и-слишком-активные ребята из MTV не будут на вас коситься.

Когда я сажусь проектировать систему, я должен решить, какие инструменты использовать. И хороший проектировщик использует или те инструменты, которым можно доверять, или те, которые можно починить. "Которым можно доверять" не означает, что они произведены какой-нибудь большой фирмой вроде IBM, которой положено доверять — это значит, что вы знаете точно, что они будут работать так, как надо. Я, например, знаю, что сегодня большинство Windows программистов доверяет Visual C++. Они могут не доверять MFC, но MFC поставляются с исходным кодом, так что если даже им нельзя доверять, их можно исправить, когда вы обнаружите, на какие зверства способна библиотека асинхронных сокетов. Так что поставить карьеру на карту MFC тоже можно.

Можно довериться Oracle DBMS по одной простой причине: она работает, и это всем известно. Вполне можно рассчитывать и на Berkeley DB, потому что, если Berkeley DB напортачит, вы идете и правите исходники. Но не стоит рисковать карьерой, используя не слишком известный инструмент с закрытым кодом. Такие программы вы можете использовать для экспериментов, но не как краеугольный камень своей карьеры .

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

Другой риск модификации исходного кода, который вы купили у производителя, связан с тем, что когда производитель обновляет свою версию, вы можете потратить кучу времени, перенося свои изменения в эту новую версию. Здесь я тоже могу кое-чем помочь: если вы нашли ошибку и послали мне исправление, я включу ваше исправление в следующую версию. Это делается с целью убедить людей, в том, что a) FogBUGZ работает; b) если он не работает в каком-то очень важном для них аспекте, они могут внести исправления и не быть уволенными, и c) если уж так случится, что им придется исправлять ошибки, и исправления эти разумны, они попадут в код следующей версии и жизнь будет уже не такой собачьей.

И тут я уже слышу голоса поборников движения "открытый код": " Балда! Да просто сделай свою программу открытой — и все дела! У открытого кода этих проблем вообще нет!". И это замечательно. Только вот, чтобы моя крохотная компания с тремя программистами работала, нужны 40 000 долларов в месяц. Так что мы берем деньги за наши программы, и мы не извиняемся, потому что они того стоят. Мы не бежим, задрав штаны, за "открытыми сорцами", но мы заимствуем у них два-три принципа, чтобы выбор FogBUGZ был безопасным решением.

--------------------
1) Здесь автор иронизирует. "Blockbuster" — сеть салонов по прокату видеофильмов в США, и те, кто хотел бы проиобрести CD через Интернет, в те годы не стали бы искать их на сайте компании Blockbuster.
2) В оригинале "herding cats", т.е. пасти кошек — идиоматическое выражение, означающее трудную задачу.
3) Практически все языки программирования (такие как Fortran, Pascal, C, Java и т.д.) являются "эквивалентными по Тьюрингу" (Turing-complete). Язык, который не является "эквивалентным по Тьюрингу", не обладает достаточной мощностью (например, в нем может отсутствовать оператор цикла, как в раннем SQL), так что определенные классы задач не могут быть на нем запрограммированы.



В английском оригинале статья называется  

Джоель Спольски - основатель , небольшой компании по
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.

Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

| | |



Содержание раздела