Речь в Йельском университете 1
From The Joel on Software Translation Project
Автор: Джоэл Спольски
Переводчик: Вадим Кадученко
В оригинале статья называлась Talk at Yale: Part 1 of 3 и была написана 3 декабря 2007
Перевод 2 части статьи - Речь в Йельском университете 2.
Перевод 3 части статьи - Речь в Йельском университете 3.
Я получил диплом бакалавра компьютерных наук в 1991 году. Шестнадцать лет назад. Сегодня я постараюсь соотнести мою учёбу на факультете компьютерных наук и мою карьеру, которая включала в себя разработку программ, написание статей о программах и основание собственной компании. Конечно, это в некотором роде нелепо. В начале курса "Введение в компьютерную науку" в Массачусетском технологическом университете (MIT) Хэл Абельсон объясняет, что компьютерная наука не о компьютерах и это не наука, поэтому с моей стороны будет немного самонадеянно предполагать, что изучение компьютерной науки готовит к карьере разработчика программ лучше, чем, например, изучение медиа или антропология культуры.
В любом случае, я продолжу. Один из самых бесполезных курсов, которые я выбрал, я бросил после первой же лекции. Ещё одним был курс Роджера Шанка, который настолько презирали на факультете компьютерных наук, что он не мог учитываться в дипломе. Я вернусь к этому через минуту.
Третьим был базовый курс, который назывался CS 322, а сейчас называется CS 323. В мои времена этот курс требовал столько усилий, что оценивался в 1.5 "кредита". В Йельском университете действует правило: дополнительная половина "кредита" может складываться с другими половинами "кредитов" по дисциплинам только с этого же факультета. Конечно, были два других курса по 1.5 кредита, но их можно было выбрать только вместе. Итак, путём такой хитрой уловки, дополнительная половина "кредита" была абсолютно бесполезна, но она соответствовала сложности недельных заданий, на решение которых уходило 40 часов. После нескольких лет непрерывных жалоб студентов, этот курс стал оцениваться в 1 "кредит", название поменяли на CS323, но на недельные задания по-прежнему уходило 40 часов. В остальном ничего с тех времён не изменилось. Мне нравился этот курс, потому что я любил программировать. Самое лучшее в этом курсе то, что он даёт понять многим студентам, что они никогда не будут программистами. И это хорошо. Те, кто всё-таки не извлёк пользы из этих уроков, работают жалкими программистами на Java и выполняют рутинную работу. Кстати, если вы выбрали этот курс и сдали его на "отлично", у нас есть для вас великолепные летние стажировки в компании Fog Creek. Подойдите ко мне после моего выступления.
Насколько я могу судить, основной курс обучения совсем не изменился. 201, 223, 240, 323, 365, 421, 422, 424, 429, кажется, не изменились с тех пор, когда я посещал их 16 лет назад. Число профильных дисциплин выросло с тех пор, когда я учился здесь, хотя их, похоже, несколько меньше, чем в эпоху доткомов. И теперь есть куда больше интересных предметов на выбор, чем в моё время. Итак, продолжу.
Одно время я думал, что получу степень Ph.D. Мои родители профессора, многие их друзья были учёными, поэтому я вырос, предполагая, что все взрослые рано или поздно получают степень Ph.D. В любом случае, я всерьёз подумывал о магистратуре по компьютерным наукам. Ровно до тех пор, пока я не посетил курс динамической логики на этой самой кафедре. Курс вела Ленор Зак, которая сейчас преподаёт в Университете Чикаго.
Я продержался не очень долго, потому что не понимал большую часть того, что происходит. Я понял, что динамическая логика похожа на формальную логику: Сократ человек, все люди смертны, следовательно, Сократ тоже смертен. Разница в том, что в динамической логике значения истинности со временем могут изменяться. Сократ был человеком, теперь он кот, и так далее. В теории это должен был быть интересный способ доказать некоторые вещи о компьютерных программах, в которых состояние, например, значения истинности, со временем изменяются.
На первой лекции доктор Зак представила несколько аксиом и правил преобразований и для начала попыталась доказать простую теорему. Дана компьютерная программа "f := not f," где f типа Boolean, то есть значение бита просто инвертируется. Нужно доказать, что если запустить эту программу чётное число раз, то конечное значение f будет таким же, как и начальное.
Доказательство всё продолжалось и продолжалось. Это было как раз в этой комнате, если я всё правильно помню, даже ковёр с тех времён не изменился, и все эти доски были исписаны формулами. Доктор Зак использовала доказательство методом индукции, методом "от противного", методом изнеможения – занятие было поздно вечером, и мы уже задержались на 40 минут – и, в отчаянии, методом аспиранта, когда она говорила "Я точно не помню, как это доказывается", а аспирант на первом ряду говорил "да, да, профессор, всё правильно". Когда, в конце концов, доказательство закончилось, почему-то получился совершенно противоположный результат. Всё исправил всё тот же аспирант с первого ряда, который заметил, что 63 шага назад один бит был случайно инвертирован из-за грязного пятнышка на доске. На дом она задала доказать обратное: если вы запускаете программу "f := not f" n раз, и конечное значение совпадает с первоначальным, то n чётно.
Я сидел над задачей часами. Передо мной лежало оригинальное доказательство прямого утверждения, которое, после тщательного рассмотрения, содержало множество "тривиальных" шагов, которые совсем не казались мне такими. Я прочитал о динамической логике всё, что смог найти в библиотеке, я бился над задачей поздно ночью. Но всё было безрезультатно, и я всё больше разочаровывался в теоретической компьютерной науке. Мне пришло на ум, что если у вас есть доказательство на много страниц, то более чем вероятно, что есть ошибка или в самом доказательстве, или в наших предположениях о тривиальных утверждениях, которые мы пытаемся доказать. Я решил, что вся эта динамическая логика – не очень эффективный способ доказать что-то о реальных, интересных компьютерных программах, потому что вы скорее ошибётесь в доказательстве, чем в интуитивном предположении о том, что делает программа "f := not f". Поэтому я бросил этот курс, как хорошо, что это был лишь ознакомительный период. Кроме этого, я тут же решил, что магистратура по компьютерным наукам просто не для меня. Таким образом, это был самый бесполезный курс из всех, что я посетил.
Это напоминает мне об одной важной вещи, о которой я узнал в процессе своей работы. Очень часто программисты переопределяют задачи так, чтобы их можно было решить алгоритмически. После переопределения они часто приходят к тривиальной задаче. Исходная задача не решается, так как она слишком сложна. Я приведу один пример.
Вы часто будете слышать заявления о том, что индустрия разработки программ переживает в некотором роде кризис качества. Я не согласен с этим – программы, которые большинство людей постоянно используют, куда качественнее, чем всё остальное, с чем они встречаются в жизни. Но это не имеет отношения к делу. Заявление о "кризисе качества" приводит к ряду предложений и научных изысканий о том, как создавать программы более высокого качества. И в этом вопросе мир делится на гиков и менеджеров.
Гики хотят решить проблему автоматически, с помощью программ. Они предлагают что-то вроде юнит-тестов, разработку через тестирование (TDD), автоматическое тестирование, динамическую логику и прочие способы "доказать", что программа не содержит ошибок. Менеджеры толком не знают об этой проблеме. Пока люди покупают программу, об этом можно не беспокоиться.
На данный момент в битве между гиками и менеджерами побеждают менеджеры, потому что они контролируют бюджет, и, по правде говоря, я не знаю, так ли это плохо. Менеджеры осознают, что к исправлению ошибок применим закон убывающей доходности. Как только программа достигает определённого уровня качества, который позволяет выполнять поставленную задачу, люди будут платить за неё и она будет им полезна.
Также менеджеры шире трактуют понятие "качество". Их определение самое меркантильное из всех, что можно вообразить: качество программы определяется тем, насколько она повысит их годовой бонус. Совершенно случайно это определение качества включает в себя намного больше, чем просто отсутствие ошибок в программе. Например, уделяется больше внимания добавлению в программу новых возможностей, которые позволят большему количеству людей решать больше проблем. Гики высмеивают подобное и называют такой софт "bloatware". Больше внимания обращается на эстетику: программа, которая выглядит круто, продаётся лучше, чем та, что выглядит уродливо. Большое значение имеет и то, нравится ли пользователям работать с программой. По сути, такое определение позволяет пользователям самим определять, что для них "качество", и решать, удовлетворяет ли их нуждам та или иная программа.
Гики интересуются только чисто техническими аспектами качества. Они сосредоточены на коде, а не ждут, что скажут о программе пользователи. Они программисты, поэтому они пытаются автоматизировать всё, в том числе и процесс тестирования. Появляется юнит-тестирование (не поймите меня неправильно, я не вижу в нём ничего плохого) и многочисленные попытки "доказать» автоматически, что программа "корректна". Проблема в том, что всё, что можно автоматизировать, нужно выкинуть из определения качества. Даже если мы знаем, что пользователи предпочитают софт, который круто выглядит, не существует автоматизированного способа оценить, насколько круто выглядит программа. Поэтому в автоматизированном тестировании это никак не учитывается.
По сути, рьяные гики упускают из виду все полезные характеристики качества. У них остаётся только то, что можно доказать автоматически, а именно: удовлетворяет ли программа спецификации. Итак, мы получаем очень узкое, сугубо техническое определение качества: насколько точно программа соответствует спецификации. Выдаёт ли она определённые выходные значения при определённых входных данных.
Эта проблема очень существенна. Чтобы механически доказать, что программа соответствует спецификации, сама спецификация должна быть невероятно подробной. По сути, она должна определять абсолютно всё в программе, иначе ничего нельзя будет доказать автоматически и механически. А если спецификация полностью определяет поведение программы, следовательно, (ну и дела!) она содержит всю информацию, необходимую, чтобы сгенерировать программу! После такого открытия некоторые особо рьяные гики идут в тёмную-тёмную комнату, где они начинают думать об автоматическом компилировании спецификаций в программы, и о том, что они только что изобрели способ программировать компьютеры без написания программ.
На самом деле это эквивалент вечного двигателя. Это одна из тех вещей, которую всегда будут делать ненормальные, неважно, сколько бы им ни говорили о том, что это никогда не будет работать. Если спецификация точно определяет, что будет делать программа, и настолько подробна, что её хватит для генерации самой программы, то возникает вопрос: как написать такую спецификацию? Её написание столь же сложно, как и создание самой программы, потому что и автор спецификации, и программист должны ответить на одни и те же вопросы. Говоря терминами теории информации, спецификация должна иметь столько же бит информационной энтропии, что и сама программа. Каждый бит энтропии – это решение, принятое автором спецификации или программистом.
Итог: если вам действительно нужен механический способ доказательства корректности программы, то всё, что вы сможете доказать – является ли программа идентичной другой программе, которая должна содержать такое же количество энтропии, как и первая. Если это не так, то поведение в некоторых ситуациях будет неопределённым, следовательно, доказать корректность будет невозможно. Таким образом, написание спецификации настолько же сложно, как и написание программы, и всё, что вы сделали – это заменили одну задачу другой и ничего не достигли.
Этот пример может показаться утрированным, но, несмотря на это, поиск священного грааля качества программ завёл в тупик очень многих. Команда, разработавшая Windows Vista – вполне подходящий пример. Скорее всего - правда, это основано лишь на слухах и намёках – Microsoft проводил долгосрочную политику увольнения всех тестеров, которые не умеют писать код, и их замены так называемыми инженерами по тестированию, программистами, которые пишут автоматические тесты.
Раньше тестеры Microsoft проверяли множество разных вещей: совместимость и читаемость шрифтов, грамотность расположения контролов в диалоговых окнах, не мерцает ли экран при определённых операциях, вёрстку пользовательского интерфейса. Они оценивали, легко ли пользоваться программой, насколько согласованны формулировки, они беспокоились о производительности, проверяли орфографию и грамматику во всех сообщениях об ошибках. Они тратили много времени, чтобы убедиться в том, что пользовательский интерфейс выглядит одинаково во всей программе, поскольку с таким интерфейсом куда легче работать.
Ничего из вышеперечисленного нельзя проверить с помощью автоматизированных тестов. И результатом упора на автоматическое тестирование стала крайняя противоречивость и "шероховатость" Windows Vista. Множество очевидных проблем добрались до релиза, и ни одна из них не была "багом" с точки зрения автоматических тестов. Однако все вместе они сформировали ощущение, что Vista – шаг назад по сравнению с XP. "Гиковское" определение качества возобладало над "менеджерским". Я уверен, что прямо сейчас Windows Vista успешно проходит все автоматические тесты в Microsoft, но это не помогает, когда все обозреватели советуют пользователям оставаться на XP как можно дольше. Оказывается, что никто не написал автоматический тест, проверяющий, имеет ли Vista неоспоримые преимущества для пользователей по сравнению с XP.
Я не испытываю ненависти к Microsoft, честно. На самом деле моим первым местом работы после школы был именно Microsoft. В те дни это считалось не слишком хорошей работой. Что-то вроде работы в цирке. Люди как-то странно смотрели на меня. Что? Microsoft? В университете к ним относились как к скучной, консервативной компании, выпускающей плохой софт, что-то вроде электронных таблиц для бухгалтеров или что там эти бухгалтеры делают. Хуже не бывает. И всё это работало на жалкой однозадачной системе под названием MS-DOS, полной дурацких ограничений. Максимум 8 символов в имени файла, никакой электронной почты, ни telnet, ни usenet. MS-DOS уже давно нет, но разница между пользователями Windows и Unix никогда не была столь ощутимой. Это война мировоззрений. Разногласия между ними туманны, но очень существенны. Для Йельского университета Microsoft всегда был местом, где делают игрушечные операционные системы для бизнеса, применяя технологии 30-летней давности. Для Microsoft термин "компьютерные науки" всегда был ругательством, высмеивающим новых работников с их ненормальными гипотезами о том, что следующим общепринятым языком программирования станет Haskell. Приведу небольшой пример противостояния Windows и Unix. Одной из культурных ценностей Unix является отделение функционала от пользовательского интерфейса. Хорошая Unix-программа берёт начало с интерфейса командной строки, и, если повезёт, кто-то возьмёт и напишет красивый интерфейс с тенями, прозрачностями и 3D-эффектами. Но этот красивый интерфейс лишь запускает внутри себя интерфейс командной строки, который выдаёт странные ошибки. Они не обрабатываются этим красивым интерфейсом так, как надо, и он виснет, ожидая ввода, который никогда не произойдёт.
Хорошая новость в том, что интерфейс командной строки можно использовать в скриптах.
В Windows же принято в первую очередь писать графический интерфейс для приложения, а весь базовый функционал безнадёжно сплетается с кодом пользовательского интерфейса. У вас может быть гигантское приложение, наподобие Photoshop, которое идеально подходит для обработки фото. Но если вы программист и хотите использовать Photoshop для ресайза 1000 картинок таким образом, чтобы каждая вмещалась в квадрат 200х200 пикселей, то вы просто не сможете написать такой код, потому что он очень тесно привязан к определённому пользовательскому интерфейсу.
Во всяком случае, противостояние этих двух культур примерно соответствует противостоянию интеллектуалов и серой массы, и, что интересно, это очень чётко отражено в расписаниях факультетов компьютерных наук в ракзличных вузах. В вузах "Лиги плюща» повсюду Unix, функциональное программирование и теория конечных автоматов. Спускаясь вниз по цепочке к вузам, где отбор не так суров, мы увидим, как в расписаниях появляется Java. Спустимся ещё на уровень ниже и увидим курсы по Visual Studio 2005. Спустимся ещё ниже, к колледжам низших ступеней, и увидим курсы вроде "SQL Server за 21 день", точно такие, как в рекламе на кабельном телевидении по выходным. (другим голосом) Пришло время начать карьеру с Java Enterprise Beans!
