Джон Кармак о науке и искусстве разработки ПО

http://blogs.uw.edu/ajko/2012/08/22/john-carmack-discusses-the-art-and-science-of-software-engineering/
  • Перевод
От переводчика

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

Также прошу прощения за отсутствие перевода словосочетания “computer science”. В русском языке нет адекватного ему словосочетания. Всякие «информатики» и «компьютерные науки» — это либо дискредитировавшие себя понятия, либо бессмысленные переводческие суррогаты. Английское понятие “computer science” содержит историческую игру слов, которая в переводе на русский язык должна выглядеть как-то так: «науки о вычислениях, обработке информации и вычислительных устройствах». Думаю, лучше оставить оригинальное “computer science”. Во всяком случае, в таком виде это словосочетание позволит вам самим подобрать нужный контекст из всего многообразия, представляемого им в оригинале.

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


От автора транскрипции, Эндрю Ко

Я не особо увлекаюсь компьютерными играми, но, тем не менее, обязан им моим увлечением программированием (оно начиналось с алгоритмов отрисовки). Поэтому, когда я увидел в своей ленте выступление Джона Кармака на QuakeCon 2012, я подумал, что надо бы его послушать. Вдруг узнаю чего нового о создании компьютерных игр?

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

Ниже — моя транскрипция этого выступления. Заранее прошу прощения за ошибки.

Выступление Джона Кармака


В стремлении делать игры быстрее (а это, собственно, то, что заставляет нас двигаться вперёд) мы наделали в коде Doom 4 много ошибок. Пусть. Эти ошибки, так или иначе, останутся в прошлом. Но само стремление делать игры быстро — необходимо. Потому что нельзя выпускать новую игру раз в шесть лет.

Если говорить про разработку ПО… Вы знаете, я на выставке E3 дал одно интервью, в котором упомянул, что постоянно учусь и в каждом новом году я расту над собой прошлогодним с профессиональной точки зрения. Интервьюер ещё удивлялся — как это мне удаётся расти над собой в течение 20 лет? А, ведь, на самом деле, я рос над собой достаточно слабо — как с точки зрения собственного мастерства, так и с точки зрения понимания динамики командного процесса разработки ПО. Возможно, я сознательно годами не обращал внимания на этот момент, потому что, знаете, появляется соблазн представлять себя этаким учёным и инженером, безапеляционно заявляющим, что вон там — абстрактное понятие, там — доказуемое, а вот там — объективное. Это же “computer science”. Наука.

Сейчас, объясню, что это за момент.

В реальности всё не так. В “computer science” вы учёный в том случае, когда вы говорите об алгоритмах, как о «вещи в себе». Когда вы оптимизируете алгоритмы — вы становитесь инженером. Но и алгоритмы (научная часть) и оптимизация (инженерная часть) — мелочи по сравнению с самим процессом программирования.

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

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

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

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

Тут можно, например, начать говорить о функциональном программировании, лямбда-счислении, монадах — это всё красиво и очень наукообразно. Но всё это не влияет на то, что конкретно и как конкретно вы разрабатываете. Да, эти «методики» и полезные штуки позволяют ликвидировать определённые классы ошибок, допускаемых абстрактными разработчиками. Но, знаете, всё то, что я могу сделать с использованием чистого функционального языка (а это, как известно, самый академичный, научный и строго формализованный способ решения задач) — всё это будет преобразовано точно в такой же ассемблерный код, в который будет преобразовано аналогичное решение, реализованное на каком-нибудь BASIC или на чём-нибудь другом на ваш выбор.

Касательно этого я бы хотел привести пример с моим старшим сыном — он как раз сейчас учится программированию. У меня, на самом деле, появлялись мысли — а не научить ли его в семь лет чему-то типа Haskell? Хорошо, что мне хватило здравого смысла не давать этим мыслям дальнейший ход. И не потому, что я знаю Haskell настолько плохо, что не смог бы обучить другого человека, изучающего программирование с нуля. Нет.

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

Даже если вернуться от функционального программирования к структурному — вся эта смысловая вата из курса программирования от циклов while и for до объяснения того, как работает компьютер ни что иное, как смысловая надстройка, например, над блок-схемами.

«Если это, то то, иначе то, а не это». Объяснение причины использования в конкретном месте для конкретной цели цикла while или цикла for. Это условности, помогающие людям избегать типичных ошибок при разработке любого ПО. При этом все такие соглашения и разъяснения не имеют никакого отношения к тому, что на самом деле происходит внутри компьютера. Они предназначены только для того, чтобы люди перестали делать типичные ошибки. Те ошибки, которые делаются всеми, постоянно и упорно.

До меня особенно долго доходило, что программисты обязательно, с некоторой периодичностью, делают ошибки. Я в прошлом году много говорил о том, что мы познакомились со статическим анализом и прогнали через него весь наш код, в результате получив сотни и тысячи выявленных проблем. И это очень круто — ведь теперь можно поднять историю, сказать «Смотри, вот тут я допустил ошибку» и показать всем место, где была допущена ошибка. Все посмотрят и для себя отметят: «О, как оно может быть! Хм, постараюсь такого не допускать». Это хорошо, но проблема-то не в следствии, а в причине. Если синтаксис позволяет что-то реализовать некорректно, то это «что-то» будет некорректно реализовано. Именно поэтому, кроме ввода статического анализа я бы хотел сильнее ограничить выразительность языковых средств и тем самым оградить программистов от совершения ошибок.

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

Кроме того, в некоторых неочевидных случаях (например, в случае размещения спецификатора const у параметра функции) есть возможность объективно разъяснить свою точку зрения («это перенаправление — список для кэширования», «такое отсутствие спецификатора будет нам стоить таких-то вычислительных ресурсов», «мы можем измерить эти ресурсы») — и при этом сделать такое разъяснение максимально аргументированным. Ведь часто бывает так, что вы, в силу опыта и многих лет работы с какой-то предметной областью, сталкивались с проблемой и рассказываете о ней. А люди, в ответ на ваши слова, говорят «Нет, я такого не встречал. Нет, для меня это не проблема. Я не делаю таких ошибок».

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

Я трачу всё больше и больше времени на поиск этих способов. Например, просматривая отчёты лаборатории разработки ПО NASA, я так и не понял ценности и предназначения большинства разрабатываемых продуктов. Все более-менее ценные продукты были полностью автоматизированными, проводили анализ или вычисления без участия человека, либо принимали какие-то решения. Сначала я думал, что по мере роста наших проектов они всё больше и больше приближаются по объёму кодовой базы к продуктам NASA и надо бы нам использовать те же методологии, что используют NASA. Но, к сожалению, если взглянуть на отчёты NASA и на объём кодовой базы их проектов, то там «большими» называются проекты с трёмя-четырьмя сотнями тысяч строк кода. В наших игровых движках кода гораздо больше. Вообще, весело понимать, что игровые движки (то, что оживляет компьютерные игры) устроены внутри сложнее, чем то ПО, что контролировало полёт людей на Луну и обратно, управляло шаттлом, заставляло работать SkyLab или работало на орбитальной станции.

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

Мы знаем, зачем и как живёт наш код. Серьёзно, мы смотрим вперёд на десятилетие. Я говорю ребятам, что код, написанный ими сейчас (если он, конечно, не ориентирован на какую-нибудь конкретную игру), может и, скорее всего, будет жить десять лет. И этот код будут использовать сотни программистов. Они будут читать его, обращаться к нему каким-нибудь образом, и это — серьёзная ответственность. Я твёрдо уверен, что мы обязаны предъявлять очень жёсткие требования к анализу и отделению того, что останется в прошлом от того, с чем мы будем жить дальше. К сожалению, кроме этого есть огромное количество нюансов в разработке разноуровневого API, есть огромное количество других неочевидных вещей — и все они требуют мастерского, творческого подхода. Мне хочется, чтобы появилось больше инструментов для работы именно с такими, тонкими материями. И я трачу много времени на то, чтобы такие инструменты у нас появлялись.
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 39
    +1
    Большое спасибо за перевод! :)
    Искал пару дней назад транскрипцию, Кармака уважаю очень, 42 года ему стукнуло на днях.
      +5
      Уважение по отношению к Кармаку, наверно, уже давно можно считать константой. Он очень много сделал и делает для мира разработки игр.
        0
        Не только для разработки игр. Меня и многих моих знакомых он вдохновляет своим упорством. Он молодец и любит то, чем занимается.
      +6
      Почему я решил прочитать эту статью? По этой причине: «Почему я решил перевести этот текст (ведь он короткий и не особо насыщенный откровениями)? Потому, что это выступление Кармака.» Знал ли я кто такой Кармак? Нет. Но в приведённой выше фразе это сказано, так, как будто авторство статьи решает (и оно действительно решает).

      И о чем же статья? Коротко — ни о чем. Видимо авторы такого масштаба мыслят на столько масштабно, что для них фразы типа «К сожалению, кроме этого есть огромное количество нюансов в разработке разноуровневого API» (почему об этом надо сожалеть? огромное, это какое? 100? 200? 1000? есть ли список?), «есть огромное количество других неочевидных вещей» (других? для кого неочевидных? для автора? какие они из себя?), «и все они требуют мастерского, творческого подхода» (это вообще, как? творческий подход от слова творение? мастерский значит работа мастера? какого уровня? 1-ого? 2-ого? что это за уровни такие?)… «Мне хочется, чтобы появилось больше инструментов» (больше это сколько? еще 100? 1000? миллион?). И такими изречениями насыщена вся статья.

      Не, ребят. Я не хочу никого задеть, в особенности фанатов (людей, за заслуги уважающих) автора. Но статьи такого рода только ломают голову, разламывая мышление кучей абстрактных стереотипов, основанных только на авторитетности автора и больше ничем (реально — ничем, ни одного подтвержденного факта).

      И если хоть кто-нибудь в двух словах сможет объяснить, буду вам благодарен. К слову, приму минусы за форму «ты не прав, думай почему сам», и не обижусь. Спасибо.
        0
        не договорил начатую мысль «фразы типа...» — заканчиваю: «имеют конкретное значение» :)
          +16
          Кармак — это вот.

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

          Я перевёл транскприпцию не для того, чтобы в ней искали какие-то указания к действию. Я постарался чуть-чуть передать характер гика, который вырос из любви к коду, как к самоцели.

          В его речи, на самом деле, цифры — это ненужная мишура. Квалиметрия и её результаты нужны там, где есть посыл к конкретике для его (посыла) валидации.

          В этом переводе нет такого посыла. Речь Кармака — это ширма, за которой показан увлечённый гик, столкнувшийся с тем, с чем сталкивается любой разработчик, который начинает руководить — с переосмыслением своей деятельности.

          На том же ХабраХабре есть куча статей про методологию программирования, GTD, серебряные пули — но очень мало примеров, которые иллюстрируют применение всего этого в реальной жизни. Мнение Кармака для многих программистов — это, несмотря на профессиональный нигилизм, достаточно весомое мнение. Реально подкреплённое кучей кода. И культурным наследнием.

          Как-то так :)
            0
            *транскрипцию, конечно же.
              +1
              Теперь понял. Мой комментарий как раз и является концентратом мысли о бессмысленности, скрывающейся за многословностью и подтверждающихся авторитарностью автора. Сейчас я вижу, что выстрел был, что называется, не в кассу.

              Понял, что это просто мысли увлеченного уважаемого дядьки :)
              Спасибо, что разъяснили!
                0
                И, кстати, на самом деле — спасибо за знакомство с этим человеком, действительно весьма интересная личность.
                  0
                  Здесь, в выступлении Кармака, мне кажется, есть ещё один сильный аспект: человек оглянулся, пересмотре свой путь, взглянул со стороны, и делится размышлениями об ОТВЕТСТВЕННОСТИ программиста.
                  Жаргонно, думаю, аналогично высказыванию «за базар нужно отвечать». Так и с программами.
                +1
                Имеются ввиду инструменты для разработки ПО в конкретных областях, например применительно к геймдеву. Чтобы отлавливать неочевидные баги, типа рассинхронизации мультиплэйера. Люди не в теме говорят «а у меня такого не бывает», а те кто уже напоролся не задумываются над созданием правил позволяющих избежать такой фигни и продолжают напарываться. У Кармака же достаточно опыта чтобы попробовать формализовать подход.
                Мне статья показалась монолитной и по делу.
                  +1
                  На самом деле я давно уже жду появления прикладной дисциплины «Разработка компьютерных игр». С профильной научной литературой, нормальной теоретической и практической базами. И человека, который бы систематизировал и обобщил накопленный индустрией опыт.

                  Ну и это, хочется почитать про superscript от id software.
                    0
                    +1.
                    Подписался на тебя :)
                  +1
                  Кармак здесь не дает ответ на какой-то конкретный вопрос. Более того — не формулирует какой-то отдельно взятый вопрос.
                  Скорее он здесь указывает направление, область для размышлений. Можно считать это приглашением — вот поле не паханное, присоединяйтесь кому интересно.
                    +1
                    «Человек часто не понимает определенных вещей не потому что он глуп, а потому, что эти вещи не входит в круг его понятий.»
                    Ты просто не дорос до уровня проблем, которые решает Джон. Надеюсь что только пока не дорос… То о чем он говорит, вполне конкретные вещи. Это проблемы программирования, которые остаются за гранью научного подхода. То, что влияет на процесс разработки на столько, что всем научным методам не удается свести к нулю ошибки возникающие в следствие этого.

                    Думаю можно привести аналогию со спортсменом. Есть тело, есть разум. И есть что-то еще, что в один из дней подвигает человека ставить мировые рекорды, а в другие дни постыдно проигрывать новичкам. Методики тренировок отработаны, психофизика спортсменов тоже развивается, но вот оставшее Х гарантирует нам то, ради чего все смотрят футбол и другие спортивные соревнования…
                    0
                    Типа язык что ль задумал свой создать?
                    А речь такая себе… высокоинтеллектуальная, да.
                      0
                      Истина где-то рядом, но точно не в методологиях NASA. Если использовать их подходы, то можно получить очень корректный код, но — ценой очень низкой продуктивности.


                      Так а какие подходы использует Кармак?
                        0
                        Боюсь, об этом он расскажет в мемуарах.

                        Можете почитать тут ­— по ссылке обсуждение оригинального выступления и немного косвенно относящейся к id software информации.
                        0
                        А что за статический анализ, через который они прогнали код и выявили тысячи ошибок?
                        0
                        если взглянуть на отчёты NASA и на объём кодовой базы их проектов, то там «большими» называются проекты с трёмя-четырьмя сотнями тысяч строк кода. В наших игровых движках кода гораздо больше. Вообще, весело понимать, что игровые движки (то, что оживляет компьютерные игры) устроены внутри сложнее, чем то ПО, что контролировало полёт людей на Луну и обратно, управляло шаттлом, заставляло работать SkyLab или работало на орбитальной станции.

                        Комментарий переводчика или транскрибиста? Сравнивать сложность ПО объёмом строк кода — это сильно ;) За ПО NASA стоит огромный объём математики и моделирования различных процессов и ситуаций на суперкомпьютерах.
                        Кармак тоже попал пальцем в небо. Называются они большими, потому что итоговые затраты на разработку и тестирование намного превышают разработку «обычного» софта, пусть и с на порядок большим объёмом кода, но цена ошибки которого не измеряется миллионами долларов.
                          +1
                          Комментарий Кармака. Выделил транскрибист.
                            0
                            А, простите, не так понял.
                            0
                            За хорошими алгоритмами тоже стоит довольно много нередко сложной математики. Для ряда графических задач и физики так же приходится находить и применять упрощенные алгоритмы, для чего так же нужна математика (хотя бы на уровне мат.статистики, линейной алгебры, диф.уров и ТФКП). Разница скорее в том, что здесь задачи типовые и многократно решённые, а там сравнительно оригинальные
                              +1
                              В большом игровом движке математики тоже по самое некуда.
                                +1
                                Cложная математика и сложное ПО это ортогональные вещи.
                                0
                                Наука или искусство?
                                Я все-таки склоняюсь к тому, что искусственное разделение между ними губительно для обеих областей развития человека.
                                Наука позволяет систематизировать и накапливать опыт, передавая его другим.
                                Искусство позволяет создавать неповторимые шедевры, часто локальные, но идеально подходящие под конкретную ситуацию.
                                Искусство позволяет создавать науку. Наука позволяет создавать новое искусство. Здесь нет противоречия.

                                Так что, дорогие мои коллеги, «улыбаемся и машем» :-)
                                  +1
                                  На самом деле Кармак сейчас так глубоко и далеко, что многим из нас его просто не понять )
                                    0
                                    Мы не видим за этими словами ТОГО смысла, который вкладывает в них он
                                      0
                                      Согласен, люди с такой горой опыта за плечами поневоле говорят притчами. Тут уже речь не о реализации алгоритма или клевой практике написания кода. Это частности и суета сует.
                                    0
                                    Извините, я может как-то не внимательно читал, но где собственно ссылка на источник — на оригинальный текст выступления на англ.?
                                      0
                                      Или вы чисто по видео переводили, а на англ. её нет? Может кто-нить подскажет где взять?
                                        0
                                        На транскрипцию — внизу перевода, в стандартном поле для указания источника переводов. Рядом с социальными кнопками.
                                      0
                                      computer science — компьютер наука)
                                      0
                                      Я говорю ребятам, что код, написанный ими сейчас (если он, конечно, не ориентирован на какую-нибудь конкретную игру), может и, скорее всего, будет жить десять лет. И этот код будут использовать сотни программистов

                                      Если не ошибаюсь, движок Source был разработан на основе GoldSource (Half-Life 1), а тот в свою очередь на основе движка Quake.
                                      То есть в таких достаточно современных играх, как Portal 2 или новый CS, вполне вероятно есть код из игры 96-го года выхода! Вот это действительно очень круто осознавать, и поневоле проникаешься уважением к авторам этого кода, и правда, на века писали =)

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое