Я нашла классное видео, в формате «как объяснить, что такое технический долг даже ребёнку». Ну, или очень далёкому от этого взрослому. Мне так понравились иллюстрации, что я сделала из этого видео комикс:
Допустим, вы запускаете новый проект и всё идет отлично. Вы пишете код, создаете контент и арты. Но прямо перед самым завершением, когда думаете, что почти закончили, начинается ад.
Ошибки, которые вы планировали исправить за пару минут занимают часы. Каждая известная бага включает две неизвестных.
Контент не сочетается друг с другом. Вообще все ваши ассеты не сочетаются друг с другом. И самое ужасное, что нет ни времени, ни денег, чтобы что-то изменить.
Что произошло?
Наступил срок погашения технического долга.
Технический долг — это то, что происходит, когда проблемы, возникшие на раннем этапе разработки, не решают.
В результате чего их решение становится гооораздно сложнее или дороже.
Потому что технический долг работает так же, как и финансовый долг.
Если кредит не погашен, проценты будут расти, до тех пор, пока долг не окажется намного выше первоначального займа.
С точки зрения разработки игр, небольшая проблема может расти и расти, и никто этого даже не заметит, пока не станет слишком поздно или сложно ее исправлять.
Решение устранить проблему сразу или оставить на потом — вопрос, с которым сталкивается каждая команда разработчиков программного обеспечения.
Это компромисс. На раннем этапе важно быстро наладить работу нового функционала, так дизайнеры и художники могут начать создавать контент. Однако это может привести к тому, что функции будут спроектированы без учёта потенциальных ошибок, которые они могут вызвать.
Это не говоря о том, что технический долго не ограничивается простым написанием кода.
Дизайнеры могу собирать уровень без какой-либо структуры, художники могут отправлять ассеты с чрезмерным количеством полигонов или дефектами текстуры. Когда проект только начинается, на эти ошибки обычно не обращают внимания, т.к. они никому особо не мешают.
Все предполагают, что ошибки обязательно исправят. Потом. Кто-нибудь другой. Этот кто-нибудь обязательно займется проблемами в будущем. Ну, или пока просто никто в команде не знает, как исправить эти ошибки. Всем приходится двигаться дальше.
Это проблема, т.к. стоимость повторного выполнения некоторых работ на поздних этапах проекта растет экспоненциально.
Многие критически важные системы могут опираться на забагованный код. Исправление, которое раньше заняло бы у разработчика 30 секунд, потенциально может поломать всю игру, а на поиски решения могут уйти недели. Может даже программист, который это написал, уже не в команде.
Или на уровнях перемешаны сотни или тысячи объектов с плохими названиями. Когда-то, чтобы найти какой-то объект на уровне у художника или дизайнера уходило несколько секунд, сейчас на это уходят уже минуты. Суммируясь, эти минуты превращаются в часы потраченного впустую производственного времени.
А еще проблема не всегда выглядит как проблема.
Возможно, ваш дизайнер великолепно властвует над хаосом. Но как только в проекте появляются другие люди… им… приходится тяжко. Тоже самое с плохо комментируемым кодом или неорганизованными ассетами.
На организацию всего проекта на позднем этапе могут уйти часы, дни и даже недели.
Другие причины технического долга — планирование.
Когда у разработчика есть жесткий дедлайн для завершения большой фичи, ему придется срезать все углы, чтобы успеть вовремя реализовать функционал. И те решения, которые разработчик в принимает, будет трудно или даже невозможно отменить.
Например, программистам поручают создать вражеский ИИ. Им говорят, что игра только для одного игрока.
Программисты создают систему искусственного интеллекта, полностью ориентированную на реакцию одного игрока-человека.
Теперь предположим, что кто-то над ними принял решение, что игра будет кооперативной и многопользовательской.
Теперь разработчикам, придется переделать всю систему так, чтобы ИИ мог правильно реагировать на нескольких игроков.
Не говоря уже о том, что дизайнеры уровней разместили ИИ на уровнях в соответствии с его изначальным функционалом. Так что теперь им, возможно, придется перепроектировать куски уровней, чтобы компенсировать это.
Как для разработчиков, так и для дизайнеров, решающих проблему спагетти, теперь это — помеха в работе с другими функциями или контентом. Приходится постоянно сдерживать этот поезд, катящийся в Ад.
Технический долг может стать настолько неуправляемым, что релиз игры будет отложен на неопределенный срок или полностью отменён. Иногда разработка настолько запутывается или сбивается с пути, что проще просто выбросить всё и начать сначала.
Но с другой стороны, бывают случаи, когда есть обоснованные причины не сильно заботиться о накопленном техническом долге.
Прототипы игр часто лепят из чего попало, чтобы протестировать ранние концепции и идеи, чтобы оценить, стоит ли детально изучать эти идеи.
Нет смысла создавать идеальные игровые системы для прототипа. Зная, что эти системы, скорее всего, будут списаны после одного игрового теста.
Некоторые студии даже отказываются от прототипов и начинают всё сначала, когда переходят к реальному производству. Иногда у них даже есть отдельные команды для прототипирования и производства.
Иногда ошибки оставляют осознанно, если считают, что слишком дорого их исправлять или они не сильно влияют на игровой процесс.
Ошибку, которая полностью ломает игру каждый раз, когда возникает, важнее исправить, чем странный графический сбой, который случается только время от времени.
Можно легко допатчить игру после выпуска, вы можете удивиться, узнав, как часто игры релизят под девизом: «грузим сейчас, фиксим потом» в связи с праздничными днями или крайними сроками продажи.
Так что не принимайте решения легкомысленно. Все мы знаем, как иногда существующая база игроков может… «реагировать» на эти изменения.
Минимизация технического долга — огромная проблема. Никто не может точно знать, что произойдет в будущем. Лучший способ справиться с тех долгом — просто осознавать, что это скорее всего произойдет. Но есть способы уменьшить потенциальный долг.
Выбирайте хорошие методологии работы в начале проекта. И придерживайтесь их.
Гайды и регулярные код-ревью могут показаться пустой тратой драгоценного времени на раннем этапе. Не говоря уже о том, что программисты будут ворчать по этому поводу. Но несколько минут на порядок или правильную организацию ассетов сэкономят огромное количество часов работы, когда вы будете завершать игру.
Выбирая, как потратить драгоценное время вашей команды на разработку, помните: если у вас нет времени сделать это правильно, у вас не будет времени сделать это заново.
Допустим, вы запускаете новый проект и всё идет отлично. Вы пишете код, создаете контент и арты. Но прямо перед самым завершением, когда думаете, что почти закончили, начинается ад.
Ошибки, которые вы планировали исправить за пару минут занимают часы. Каждая известная бага включает две неизвестных.
Контент не сочетается друг с другом. Вообще все ваши ассеты не сочетаются друг с другом. И самое ужасное, что нет ни времени, ни денег, чтобы что-то изменить.
Что произошло?
Наступил срок погашения технического долга.
Технический долг — это то, что происходит, когда проблемы, возникшие на раннем этапе разработки, не решают.
В результате чего их решение становится гооораздно сложнее или дороже.
Потому что технический долг работает так же, как и финансовый долг.
Если кредит не погашен, проценты будут расти, до тех пор, пока долг не окажется намного выше первоначального займа.
С точки зрения разработки игр, небольшая проблема может расти и расти, и никто этого даже не заметит, пока не станет слишком поздно или сложно ее исправлять.
Решение устранить проблему сразу или оставить на потом — вопрос, с которым сталкивается каждая команда разработчиков программного обеспечения.
Это компромисс. На раннем этапе важно быстро наладить работу нового функционала, так дизайнеры и художники могут начать создавать контент. Однако это может привести к тому, что функции будут спроектированы без учёта потенциальных ошибок, которые они могут вызвать.
Это не говоря о том, что технический долго не ограничивается простым написанием кода.
Дизайнеры могу собирать уровень без какой-либо структуры, художники могут отправлять ассеты с чрезмерным количеством полигонов или дефектами текстуры. Когда проект только начинается, на эти ошибки обычно не обращают внимания, т.к. они никому особо не мешают.
Все предполагают, что ошибки обязательно исправят. Потом. Кто-нибудь другой. Этот кто-нибудь обязательно займется проблемами в будущем. Ну, или пока просто никто в команде не знает, как исправить эти ошибки. Всем приходится двигаться дальше.
Это проблема, т.к. стоимость повторного выполнения некоторых работ на поздних этапах проекта растет экспоненциально.
Многие критически важные системы могут опираться на забагованный код. Исправление, которое раньше заняло бы у разработчика 30 секунд, потенциально может поломать всю игру, а на поиски решения могут уйти недели. Может даже программист, который это написал, уже не в команде.
Или на уровнях перемешаны сотни или тысячи объектов с плохими названиями. Когда-то, чтобы найти какой-то объект на уровне у художника или дизайнера уходило несколько секунд, сейчас на это уходят уже минуты. Суммируясь, эти минуты превращаются в часы потраченного впустую производственного времени.
А еще проблема не всегда выглядит как проблема.
Возможно, ваш дизайнер великолепно властвует над хаосом. Но как только в проекте появляются другие люди… им… приходится тяжко. Тоже самое с плохо комментируемым кодом или неорганизованными ассетами.
На организацию всего проекта на позднем этапе могут уйти часы, дни и даже недели.
Другие причины технического долга — планирование.
Когда у разработчика есть жесткий дедлайн для завершения большой фичи, ему придется срезать все углы, чтобы успеть вовремя реализовать функционал. И те решения, которые разработчик в принимает, будет трудно или даже невозможно отменить.
Например, программистам поручают создать вражеский ИИ. Им говорят, что игра только для одного игрока.
Программисты создают систему искусственного интеллекта, полностью ориентированную на реакцию одного игрока-человека.
Теперь предположим, что кто-то над ними принял решение, что игра будет кооперативной и многопользовательской.
Теперь разработчикам, придется переделать всю систему так, чтобы ИИ мог правильно реагировать на нескольких игроков.
Не говоря уже о том, что дизайнеры уровней разместили ИИ на уровнях в соответствии с его изначальным функционалом. Так что теперь им, возможно, придется перепроектировать куски уровней, чтобы компенсировать это.
Как для разработчиков, так и для дизайнеров, решающих проблему спагетти, теперь это — помеха в работе с другими функциями или контентом. Приходится постоянно сдерживать этот поезд, катящийся в Ад.
Технический долг может стать настолько неуправляемым, что релиз игры будет отложен на неопределенный срок или полностью отменён. Иногда разработка настолько запутывается или сбивается с пути, что проще просто выбросить всё и начать сначала.
Но с другой стороны, бывают случаи, когда есть обоснованные причины не сильно заботиться о накопленном техническом долге.
Прототипы игр часто лепят из чего попало, чтобы протестировать ранние концепции и идеи, чтобы оценить, стоит ли детально изучать эти идеи.
Нет смысла создавать идеальные игровые системы для прототипа. Зная, что эти системы, скорее всего, будут списаны после одного игрового теста.
Некоторые студии даже отказываются от прототипов и начинают всё сначала, когда переходят к реальному производству. Иногда у них даже есть отдельные команды для прототипирования и производства.
Иногда ошибки оставляют осознанно, если считают, что слишком дорого их исправлять или они не сильно влияют на игровой процесс.
Ошибку, которая полностью ломает игру каждый раз, когда возникает, важнее исправить, чем странный графический сбой, который случается только время от времени.
Можно легко допатчить игру после выпуска, вы можете удивиться, узнав, как часто игры релизят под девизом: «грузим сейчас, фиксим потом» в связи с праздничными днями или крайними сроками продажи.
Так что не принимайте решения легкомысленно. Все мы знаем, как иногда существующая база игроков может… «реагировать» на эти изменения.
Минимизация технического долга — огромная проблема. Никто не может точно знать, что произойдет в будущем. Лучший способ справиться с тех долгом — просто осознавать, что это скорее всего произойдет. Но есть способы уменьшить потенциальный долг.
Выбирайте хорошие методологии работы в начале проекта. И придерживайтесь их.
Гайды и регулярные код-ревью могут показаться пустой тратой драгоценного времени на раннем этапе. Не говоря уже о том, что программисты будут ворчать по этому поводу. Но несколько минут на порядок или правильную организацию ассетов сэкономят огромное количество часов работы, когда вы будете завершать игру.
Выбирая, как потратить драгоценное время вашей команды на разработку, помните: если у вас нет времени сделать это правильно, у вас не будет времени сделать это заново.
