Как вы умственно справляетесь с одним очень длинным кусочком работы [закрыто]

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

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

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

Добро пожаловать в игровую индустрию :)

Итак, вы делаете массивный рефакторинг. Массовый рефакторинг - это зло, но это не тема. Возможно, вам все-таки дали задание проверить свои нервы, так что не сдавайтесь.

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

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

• Вы переписываете этот модуль по причине. Это может быть неочевидно для вас, но если вам дали эту задачу, скорее всего, потому что что-то было настолько дрянным, что люди чувствуют, что лучше начинать все сначала. Спросите вокруг: что это за дефекты ?

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

• Как только вы получите эту основную функцию, вы уже почувствуете себя лучше. Важно видеть результат вашей работы как можно раньше: 1) чтобы ваш моральный дух 2) был в состоянии проверить его. Итак, проверь это, проверь стресс, помучай это . Если это дает сбой или показывает действительно плохую ошибку, исправьте это. Это сердце вашего модуля, поэтому переделайте его немного и почистите, пока не почувствуете себя комфортно с ним.

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

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

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

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

РЕДАКТИРОВАТЬ

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

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

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

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

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

Вы должны разделить свою задачу, но никто не дает совета, как это сделать.

• Новые и старые модули работают вместе? То есть, вы можете скомпилировать свой проект с обоими? Это позволит вам по крайней мере скомпилировать и, возможно, запустить автоматизированные тесты на некоторых этапах.
• Вы пишете новый модуль? Или старый код, которым вы владеете? Перепишите на месте (если внешний API остается прежним). Если вы исправляете по одной функции за раз, вы сможете продолжить использовать комбинированный API Mongrel, до некоторой степени.
• Есть ли в компании другие проекты, которые будут осуществлять подобный переход? Напишите обертки вокруг этих модулей, чтобы облегчить процесс в следующий раз. Возможно, стоит сделать это в то же время.
• Можете ли вы закомментировать или избежать компиляции фрагментов вашей цепочки зависимостей? Если у вас есть полмиллиона строк кода, возможно, вы можете разделить его на двадцать кусков, которые компилируются независимо, получают один за пару недель, а затем переходите к следующему. Может быть, не полностью независимые куски все время, но тогда вы можете сделать это в порядке зависимостей.

Также: спросите совета у своего менеджера. Вероятно, я бы начал с описания проблемы: для правильной компиляции требуется так много времени, что сложно отслеживать изменения, которые усложняют отладку, когда у вас есть что-то, что вы можете протестировать. Затем я бы упомянул потенциальное решение и спросил: «Как вы рекомендуете реализовать это решение или есть ли лучший способ сделать это полностью?»