В рамках моих постоянных попыток заниматься благотворительностью и обменом знаниями я выступал на конференции Develop:Brighton в 2015 и 2016 годах.
Я подумал, что пришло время сделать слайды доступными где-нибудь, чтобы их было легко найти, поэтому я разместил ссылки здесь, в блогатроне.
Надеюсь, вы найдете их полезными. Не стесняйтесь спрашивать меня о них в Твиттере, если вам нужна дополнительная информация — @darbotron
2015: Портирование игр Unity на консоли
[ "Скачать здесь" ]
Первый разговор касается переноса игр Unity с ПК на консоль — некоторые мелкие детали в нем изменились за прошедшее время, когда Unity перешла с 4.x на 2017.x, но в целом содержащиеся в нем советы по-прежнему актуальны. теперь как тогда.
Это также содержит множество слайдов, которые мне пришлось вырезать из фактического выступления, чтобы сделать это за 45 минут, которые у меня были…
2016: Как НЕ потерпеть неудачу в программной инженерии
[ "Скачать здесь" ]
Я вмешался в последнюю минуту, чтобы выступить с этим докладом после того, как другой оратор отключился, поэтому в нем немного меньше деталей, чем в предыдущем.
Как человек, который портирует игры и/или помогает исправлять проблемы в играх, которые собираются выпустить, я вижу несколько похожих классов проблем практически в каждой кодовой базе, которую я просматриваю, и многие из них, кажется, имеют одни и те же — предотвратимые — первопричины.
Эти проблемы обычно коренятся в том, что я называю ежеминутным кодом. Недостаточно низкий уровень, чтобы привлечь внимание, чтобы избежать проблем с производительностью, или достаточно значимый с точки зрения архитектуры, чтобы гарантировать детальное планирование. Вид кода, написанный для объединения модулей или интеграции какой-либо новой функции, чтобы уложиться в срок; код «заставьте его работать», который мы не всегда забываем привести в порядок перед передачей в систему управления версиями.
Это работает, но на самом деле никто не «владеет» им. Он строится, изменяется, переназначается, а в худших случаях проникает во всю кодовую базу игры до того, как становится очевидным, что с ним есть проблема. Это такие проблемы, которые обычно становятся очевидными только тогда, когда вы пытаетесь освоить, а затем то, что звучит как простое изменение или легкое исправление ошибки, заканчивается значительным рефакторингом, затрагивающим 30 с лишним процентов кодовой базы. Мы все были там.
В этом выступлении я выступаю за идентификацию и применение минимально жизнеспособной программной инженерии, соответствующей этому уровню программирования, и предлагаю свое мнение относительно отправной точки для нее — набора инструментов, помогающих нам заранее предотвращать эти случайные безвредные кодовые бомбы путем не писать их в первую очередь, а помочь выявить и исправить их до того, как они станут проблемами.
