Джон Кармак обсуждает искусство и науку программной инженерии

Перевод статьи John Carmack discusses the art and science of software engineering, автор - Andrew J. Ko

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

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

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

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

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

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

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

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

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

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

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

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

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

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