Десять лет назад, когда я только пришёл в большую студию EA SPB, я написал эту заметку и забыл о ней, пока недавно не наткнулся на неё в архивах. Оказалось, советы до сих пор актуальны, разве что объёмы выросли.
Вспоминаю свой первый рабочий день: предыдущие проекты с базой в сотни тысяч строк казались мне гигантскими. А тут я скачал репозиторий, открыл IDE – и она зависла минут на пятнадцать, индексируя все файлы. Моя первая мысль была: «Неужели это нормальная студийная база? Я всё сломал или мне дали древний комп?» Оказалось, это просто промышленный масштаб.
В тот момент команда доводила до ума крупный релиз Sims Mobile, и ресурсов на нормальный онбординг не было. Мне поручили задачу «на разогрев»: сохранить положение и размеры стульев в редакторе дома между запусками. Казалось, дело пяти минут – записал координаты в конфиг, прочитал при старте и готово. Но где лежит система конфигов? Как называются классы, где хранятся сами стулья? Оказалось, готовой системы не было: дома спавнятся только дизайнерские точки, а для режима игры отдельного сохранения вообще не существовало.
В университете нас отлично учили алгоритмам, и два года мы писали «с нуля» ОС по хотелкам преподавателя. На предыдущей работе приходилось клепать ПО для гидроакустики и охранных систем буквально с чистого листа. Но ничто не подготовило меня к тому, чтобы в первую неделю открыть проект на два миллиона строк без какой-либо помощи.
Сегодня большая кодовая база – это норма. Если вы пришли не в маленькую инди-студию, а в серьёзный проект, первым вашим навыком должно стать умение ориентироваться в километрах наследуемого кода, разнообразных паттернах и уникальных фишках, нарисованных десятилетиями. Сначала это похоже на блуждание по незнакомому городу без карты, но методичный подход быстро приведёт в чувство.
Современные игровые движки – это многомиллионные строки. По разным данным:
- Unreal Engine (движок, редактор, плагины) – от 2 до 20 MLoc;
- Unity (ядро на C++ + обвязка) – около 1 MLoc;
- Godot (включая скрипты и ресурсы) – порядка 1 MLoc;
- Dagor (War Thunder и др.) – примерно 2+ MLoc;
- 4A Engine (под конкретную игру) – около 500 KLoc.
Разброс объясняется различными методиками подсчёта, плагинами и системой генерации кода.
Но не забывайте: за этими цифрами стоят обычные люди. Все они начинали с нуля, и никакой магии тут нет – лишь накопленный опыт и десятки билд-систем (premake, cmake, ninja, UBT и др.).
Каждый крупный проект имеет собственный ритуал сборки: скрипты, утилиты и бесчисленные настройки окружения. Документация часто устаревает, а автоматических «кнопок» почти не встречается. Если сборка падает, внимательно изучайте гайды и задавайте точные вопросы: «Где взять OpenEXR?» лучше, чем «У меня всё сломалось».
После того как вы всё-таки соберёте проект, возникнет задача найти конфиг стульев. Здравый подход – спросить у сеньора. Он, не отрываясь от отладки, подскажет: Game/Play/Home/HomeInventory/KesloInventoryIndoor.cpp:2847, не забудьте зарегистрировать обработчик в HomeManager, чтобы изменения работали и вне дома.
Не верьте, что опытные сотрудники помнят всё. Они просто освоили искусство эффективного поиска: IDE, grep, историю коммитов и документацию в коде. Их приоритеты – тушить проблемы в продакшене, ревьюить пул-реквесты и оптимизировать производительность, а не часами искать файлы.
Через пару месяцев вы будете находить нужное за минуты, легко ориентироваться в архитектуре и перестанете бояться «монстра» из миллионов строк. Опыт – это когда по ключевому слову «стул» вы сразу попадаете в Game/Play/Inventory/InventoryHome.cpp.
Умение искать не исключает вопросов. Если вы бьётесь 20 минут безрезультатно, стоит уточнить детали: может, код скрыт в нетипичном месте или назван по-другому (FooBazKreslo вместо FooBazChair). Конкретные вопросы экономят время и развивают навыки.
Полезный приём – искать по тем строкам, что видит пользователь в интерфейсе. Часто UI-имена совпадают с ключами в коде: найдите элемент в редакторе, затем по его названию найдите соответствующие файлы.
История версий – ваш надёжный помощник. Git хранит изменения, авторов и контекст. Прежде чем писать новый код, убедитесь, что похожая функция уже не реализована: дублирование усложняет поддержку.
Кодстайл студии – это культура проекта. Соблюдайте существующие соглашения: эксперименты оставьте для личных проектов.
И помните: единственный источник правды – исходники. Документы устаревают, комментарии не всегда верны, а устаревшие заметки коллег нередко вводят в заблуждение. За ответом «почему» идите к ветеранам, но «что» и «где» вы всегда найдёте в коде.
Постскриптум: уставший сеньор после 73-го вопроса за неделю. Если эта статья была полезна – поделитесь с коллегами, особенно новичками.
PS: приглашаю на вебинар о тонкостях работы с кодом игровых движков: pvs-studio.ru/ru/webinar/25.
