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

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

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

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

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

На самом деле, в компьютерной науке, единственное, что на самом деле является наукой, это когда вы говорите об алгоритмах. А оптимизация - это инженерия. Но на самом деле, больше всего времени занимает программирование. Знаете, у нас есть несколько программистов, которые тратят много времени на оптимизацию, и некоторые из них занимаются подбором алгоритмов, но 90% программистов занимаются программированием, чтобы все получилось. И когда я начинаю смотреть на то, что на самом деле происходит во всем этом, то действительно нет никакой науки и техники и нет объективности к большинству этих задач. Один из программистов говорит, что он выполняет множество “обезьяньих” задач. И нам нравится думать, что мы можем быть умными инженерами в этом деле, что есть объективные способы делать хорошее программное обеспечение, но по мере того, как я смотрю на это всё больше и больше, меня поражает, насколько это на самом деле не так.

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

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

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

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

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

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

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

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

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

Помогла вам эта статья?

Не нашли ответ на свой вопрос? Возможно, вы найдете решение проблемы на нашем канале в Youtube! Здесь мы собрали небольшие, но эффективные инструкции. Смотрите и подписывайтесь на наш youtube-канал!

Смотреть на Youtube