Технические костыли, которые спасли наш релиз

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

Это и есть костыль — не халтура, не «потом доделаем», а трезвое решение взрослого разработчика, который понимает цену идеальной архитектуры перед лицом дедлайна. За годы самостоятельных релизов я собрал целую коллекцию таких решений. Часть из них спасла запуски, часть — научила, как делать не надо. Сейчас разберу и те, и другие.

Почему костыли иногда лучше «правильного» решения

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

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

Есть важная граница: костыль допустим, если он:

• снимает риск с релиза;
• не ломает основные сценарии игрока;
• понятен команде и его можно быстро удалить;
• не создаёт скрытый долг, который через месяц обернётся катастрофой.

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

Что мы называем костылём на практике

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

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

Простой пример из нашей практики: вместо полной переделки сохранений можно временно отключить часть нестабильных параметров и сохранить только базовое состояние. Игра теряет немного гибкости, но перестаёт падать у игроков. Мы так делали с системой достижений: часть ачивок не корректно сериализовалась на некоторых версиях Windows, и вместо того чтобы переписывать сериализатор за два дня до сдачи, мы просто исключили проблемные поля из сейва. Игроки даже не заметили, а мы спокойно всё починили в первом патче.

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

Костыли, которые реально спасают релиз

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

Каждый из этих пунктов я применял лично. Отключение проблемной функции — самый частый гость в наших релизных ветках. Упрощение логики — второй по популярности, особенно когда AI начинает вести себя непредсказуемо на специфическом железе. Жёсткий fallback спас нас однажды, когда часть звуков не грузилась на Linux-билде: мы просто подставили тишину вместо краша, и игроки хотя бы могли играть.

Самые частые технические костыли перед релизом

1. Отключение «опасного» контента

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

Это нормально, если:

• элемент не критичен для прохождения;
• игрок не теряет понимание основного цикла;
• вы честно проверили, что исключение не создаёт новых багов.

Типовая ошибка — оставить поломанный контент «на потом», надеясь, что игрок туда не дойдёт. Дойдёт. Я знаю случай, когда студия оставила сломанного босса на дополнительном пути, думая, что его найдут не сразу. Его нашли в первый день, и форумы заполнились баг-репортами. Лучше честно вырезать и добавить в патче, чем получить репутацию «игры, которая падает».

2. Фолбэк вместо полного падения

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

• текстур;
• звуков;
• локализаций;
• иконок;
• конфигов.

Например, если отсутствует локализованная строка, игра должна показать английскую или базовую версию, а не пустое поле и ошибку. Мы в Exiled-Republic всегда закладываем fallback-строки для всех локалей. Это спасло нас, когда переводчик не прислал часть ключей за день до сборки — игроки увидели английский текст вместо пустых кнопок.

С текстурами тот же принцип: лучше показать фиолетовый квадрат (и записать ошибку в лог), чем уронить приложение. Фиолетовый квадрат хотя бы даёт понять, что ресурс отсутствует, а не маскирует проблему под молчаливое падение.

3. Жёсткое упрощение логики

Иногда сложная система ломается из-за слишком умных условий. Тогда перед релизом лучше убрать «умность» и оставить предсказуемую механику.

Что это может быть:

• временное отключение редких веток AI;
• упрощение расчёта столкновений;
• отказ от части процедурной генерации;
• более грубая, но стабильная формула баланса.

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

4. Переключатели и скрытые флаги

Флаги позволяют быстро выключать нестабильные части игры без полноценной пересборки логики. Это полезно, когда:

• проблема проявляется только на части устройств;
• баг зависит от настроек;
• нужно срочно ограничить риск после релиза.

Но флаги требуют порядка. Если у вас десяток временных переключателей без описания, через пару недель никто не вспомнит, что именно отключено и почему. У нас был случай: мы отключили пост-обработку на одной конфигурации через флаг, забыли задокументировать, а через месяц другой разработчик включил её обратно, потому что «флаг выглядел лишним». Баг вернулся, и пришлось разбираться заново.

Правило простое: каждый флаг должен иметь комментарий в коде с датой, причиной и условиями удаления. И задача в трекере — обязательно.

Как понять, что костыль безопасен

Перед тем как оставлять временное решение в релизной ветке, задайте себе шесть вопросов:

• Ломает ли оно основной сценарий игрока?
• Может ли это решение вызвать новый краш?
• Понятно ли, как его удалить после релиза?
• Есть ли запись в баг-трекере или техдолге?
• Проверяли ли вы его на всех целевых платформах?
• Есть ли запасной план, если костыль не сработает?

Если хотя бы на два вопроса ответ «нет», решение слишком сырое для релиза. Я бы добавил седьмой вопрос, который часто упускают: «Поймёт ли другой разработчик, что здесь происходит, через месяц?» Если вы сами сомневаетесь — оставьте комментарий в коде прямо сейчас, пока помните контекст.

Пошаговый алгоритм: как внедрять костыль без хаоса

1. Чётко сформулируйте проблему.
2. Определите, что именно нельзя ломать в релизной версии.
3. Выберите самое простое решение, которое убирает риск.
4. Ограничьте радиус действия костыля: только нужная платформа, уровень или сценарий.
5. Добавьте комментарий в коде и задачу в трекере.
6. Протестируйте не только «починилось ли», но и «не сломалось ли рядом».
7. Назначьте срок удаления костыля.
8. После релиза сразу проверьте, что временное решение не стало постоянным.

Пункт 6 часто игнорируют: проверяют, что баг исчез, но не смотрят, что сломалось по соседству. У нас однажды отключение одной анимации через флаг сломало скрипт перехода между сценами — потому что скрипт ждал события от этой анимации. Хорошо, что заметили на тестах, а не после релиза.

Типовые ошибки, из-за которых костыль становится проблемой

1. Костыль без документации

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

2. Костыль без границ

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

3. Костыль вместо диагностики

Иногда хочется не искать причину бага, а просто «заглушить» его. Это опасно: симптом исчезает, а корень остаётся и позже проявляется в другой форме. Я называю это «лечить температуру, а не инфекцию». Если вы не понимаете, почему падает загрузка текстуры, и просто ставите fallback, проблема может проявиться в другом месте — например, в утечке памяти или повреждении других ресурсов.

4. Костыль в критической механике

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

Когда костыль оправдан, а когда нет

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

Что спасает не хуже самого костыля

Иногда релиз спасает не код, а организационная дисциплина. Я убедился в этом на собственном опыте: самые гладкие релизы у нас были не тогда, когда мы писали идеальный код, а когда соблюдали простые правила:

• ежедневные сборки;
• короткий список блокеров;
• фиксированное окно на тестирование;
• резервная ветка билда;
• быстрый откат последнего изменения;
• логирование, которое реально можно читать.

Без этого даже хороший костыль может не дожить до релиза. Ежедневные сборки — это вообще must-have: если вы собираете билд раз в неделю, вы не знаете, что сломалось в понедельник, и ищете проблему по всему коду за семь дней. Короткий список блокеров дисциплинирует: мы обычно держим не больше пяти критических задач, и если появляется шестая, кто-то из команды должен взять одну из существующих, пока другой разбирается с новой.

Логирование — отдельная боль. Я много раз видел логи, которые пишут «Error: something went wrong» без контекста. Такие логи бесполезны. Лучше потратить час и настроить читаемые сообщения с идентификаторами объектов и состояний, чем потом гадать, что случилось на машине игрока.

Чек-лист перед тем, как оставить костыль в релизе

• Проблема описана в одном предложении.
• Понятно, что именно костыль предотвращает.
• Есть ограничение по платформе, сцене или функции.
• Решение не ломает основной геймплей.
• Добавлен комментарий в код.
• Создана задача на нормальную реализацию.
• Костыль протестирован на целевых устройствах.
• Известно, кто и когда его уберёт.

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

FAQ

Чем костыль отличается от плохого кода?

Костыль — это временное, осознанное решение конкретной проблемы. Плохой код — это неясная, хаотичная реализация без контроля и плана замены. Разница в намерении и документировании: костыль вы ставите с мыслью «это на неделю, вот задача на переделку», плохой код пишете с мыслью «как-нибудь заработает».

Можно ли выпускать игру с костылями?

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

Что делать, если костыль уже начал жить своей жизнью?

Зафиксировать его в техдолге, определить приоритет и либо заменить на нормальное решение, либо удалить, если он больше не нужен. Главное — не игнорировать. Если костыль живёт больше двух месяцев, он уже не временный, а часть архитектуры. Относитесь к нему соответственно.

Какие костыли самые опасные?

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

Вывод

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

За годы работы я перестал воспринимать костыли как что-то постыдное. Это инструмент, такой же как дебаггер или профайлер. Просто у него есть срок годности и правила использования. Если вы знаете эти правила — вы контролируете ситуацию. Если нет — ситуация контролирует вас.