Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Достаточно много времени я потратил на рефакторинг одного проекта, который судя по заявлениям автора проекта был основой для обучения студентов в МФТИ. Выполнен этот проект просто ужасно, учить так студентов — пожалуйста так не нужно.
Весь рефакторинг выполнен онлайн в виде 6 частей, каждая по 2-3 часа стримов на ютубе, ниже я дам только ссылку на затравку, а полные стримы вы сможете найти на том же канале.
Разбор чужого кода — так учат делать Tower Defence
В статье же, будет представлена сухая выжимка — резюме, что было сделано в рефакторинге и подискутируем на тему — почему так не правильно учат? Если же у вас на первый взгляд появится субъективное мнение, что я где-то не прав, это нормально. Но лишь задумайтесь, если я на протяжении порядка 15 часов рефакторингов только и делал то, что удалял лишние сущности и связи между ними, то может все таки в моем взгляде есть что-то?
Конечно, если вы скажете, что можно не соблюдать ООП, то статью можно закрыть — и пусть ваш другой подход будет у вас на вашей совести. Эта статья про то как ООП в Юнити облегчает программирование.
Первое с чего начался рефакторинг — это устранение использования ScriptableObject, которые использовались как некоторые структуры, на основании которых создавались объекты данных. Очень рекомендую очень хорошо подумать, использовать ли вообще ScriptableObject. Дело в том, что в 99% они вам будут просто не нужны. Подавляющее число объектов реального мира помимо состояния, отражаемого данными, всегда имеют в себе свое поведение. И ООП нас учит, что нужно так декомпозировать объекты реального мира на классы, чтобы они содержали бы в себе и состояние, и поведение вместе. В этом по сути базис ООП. А значит использование ScriptableObject может понадобится лишь в исключительных случаях, когда объект вырожден. Например, хороший пример это описание какого-то стиля UI — цвет, фонт, материал и т.п., что потом применяется к некому диалогу в UI. Но если это базовые объекты Enemy, Turret самой игры — нельзя их настраивать через ScriptableObject.
Второе, не используйте доступ к объектам/переменным через static поля/свойства. В данном примере существовал класс Game с набором static полей, и все, кому что-то было нужно, просто брал это через него. Возможно, вы не всегда отдаете себе в этом отчет, но это же все равно, что использовать глобальные переменные, которые вот уже несколько десятков лет так не используют.
Третье, в проекте видимо хотели реализовать MVC. И я уже видел, что почему то некоторые компании даже требуют так реализовывать свои игры. Но первое, ответьте себе на вопрос, что даст вам реализация MVC — в вашем проекте? Если вы посмотрите мой пример рефакторинга на канале, вы заметите, что автору проекта MVC не дал ничего, кроме головной боли и разбиения бизнес-логики на части в разных классах. Напишите в комментариях — для чего вам MVC в проекте юнити? И я уверен почти все ответы будут неправильными :) буду рад, ошибиться.
Четвертое, я периодически сталкиваюсь с мнением, что в Юнити нужно минимизировать использование MonoBehaviour? Но, почему? Как далеко вы готовы зайти, чтобы испортить себе жизнь не используя MonoBehaviour. MonoBehaviour позволяют замечательно использовать редактор Юнити, позволяет обмениваться ссылками между компонентами не написав ни строчки кода, видеть состояние объектов через них во время отладки.
И пятое, когда вы придумываете любую свою архитектуру, не позволяйте своему разуму вводить вас в заблуждение. Если вы вводите лишние сущности, разделяете классы/методы/свойства так, что образуются только лишние связи — ваша архитектура совершенно избыточная и неверная. Если в результате рефакторинга законченного проекта, получается его существенно сократить, не уменьшив функциональности, который этот проект выполняет — это приговор вашей архитектуре. Все другие аргументы померкнут по сравнению с этим. Аналогично принципу бритвы Оккама, архитектура должна проверяться на минимизацию сущностей и связей между ними. И если другой подход позволяет их сократить, он однозначно лучше. И казалось бы такая банальная истина, но очень, очень часто она не выполняется и даже такому учат в университетах. Печально… почему так происходит?
Я наверно все таки дам прямые ссылки на стримы и желающие смогут детально просмотреть как выполнялся рефакторинг, и возможно сам рефакторинг будет полезней обучения на таких курсах:
Часть №1
Часть №2
Часть №3
Часть №4
Часть №5
и заключительная 6 еще в монтаже…
Весь рефакторинг выполнен онлайн в виде 6 частей, каждая по 2-3 часа стримов на ютубе, ниже я дам только ссылку на затравку, а полные стримы вы сможете найти на том же канале.
Разбор чужого кода — так учат делать Tower Defence
В статье же, будет представлена сухая выжимка — резюме, что было сделано в рефакторинге и подискутируем на тему — почему так не правильно учат? Если же у вас на первый взгляд появится субъективное мнение, что я где-то не прав, это нормально. Но лишь задумайтесь, если я на протяжении порядка 15 часов рефакторингов только и делал то, что удалял лишние сущности и связи между ними, то может все таки в моем взгляде есть что-то?
Конечно, если вы скажете, что можно не соблюдать ООП, то статью можно закрыть — и пусть ваш другой подход будет у вас на вашей совести. Эта статья про то как ООП в Юнити облегчает программирование.
Первое с чего начался рефакторинг — это устранение использования ScriptableObject, которые использовались как некоторые структуры, на основании которых создавались объекты данных. Очень рекомендую очень хорошо подумать, использовать ли вообще ScriptableObject. Дело в том, что в 99% они вам будут просто не нужны. Подавляющее число объектов реального мира помимо состояния, отражаемого данными, всегда имеют в себе свое поведение. И ООП нас учит, что нужно так декомпозировать объекты реального мира на классы, чтобы они содержали бы в себе и состояние, и поведение вместе. В этом по сути базис ООП. А значит использование ScriptableObject может понадобится лишь в исключительных случаях, когда объект вырожден. Например, хороший пример это описание какого-то стиля UI — цвет, фонт, материал и т.п., что потом применяется к некому диалогу в UI. Но если это базовые объекты Enemy, Turret самой игры — нельзя их настраивать через ScriptableObject.
Второе, не используйте доступ к объектам/переменным через static поля/свойства. В данном примере существовал класс Game с набором static полей, и все, кому что-то было нужно, просто брал это через него. Возможно, вы не всегда отдаете себе в этом отчет, но это же все равно, что использовать глобальные переменные, которые вот уже несколько десятков лет так не используют.
Третье, в проекте видимо хотели реализовать MVC. И я уже видел, что почему то некоторые компании даже требуют так реализовывать свои игры. Но первое, ответьте себе на вопрос, что даст вам реализация MVC — в вашем проекте? Если вы посмотрите мой пример рефакторинга на канале, вы заметите, что автору проекта MVC не дал ничего, кроме головной боли и разбиения бизнес-логики на части в разных классах. Напишите в комментариях — для чего вам MVC в проекте юнити? И я уверен почти все ответы будут неправильными :) буду рад, ошибиться.
Четвертое, я периодически сталкиваюсь с мнением, что в Юнити нужно минимизировать использование MonoBehaviour? Но, почему? Как далеко вы готовы зайти, чтобы испортить себе жизнь не используя MonoBehaviour. MonoBehaviour позволяют замечательно использовать редактор Юнити, позволяет обмениваться ссылками между компонентами не написав ни строчки кода, видеть состояние объектов через них во время отладки.
И пятое, когда вы придумываете любую свою архитектуру, не позволяйте своему разуму вводить вас в заблуждение. Если вы вводите лишние сущности, разделяете классы/методы/свойства так, что образуются только лишние связи — ваша архитектура совершенно избыточная и неверная. Если в результате рефакторинга законченного проекта, получается его существенно сократить, не уменьшив функциональности, который этот проект выполняет — это приговор вашей архитектуре. Все другие аргументы померкнут по сравнению с этим. Аналогично принципу бритвы Оккама, архитектура должна проверяться на минимизацию сущностей и связей между ними. И если другой подход позволяет их сократить, он однозначно лучше. И казалось бы такая банальная истина, но очень, очень часто она не выполняется и даже такому учат в университетах. Печально… почему так происходит?
Я наверно все таки дам прямые ссылки на стримы и желающие смогут детально просмотреть как выполнялся рефакторинг, и возможно сам рефакторинг будет полезней обучения на таких курсах:
Часть №1
Часть №2
Часть №3
Часть №4
Часть №5
и заключительная 6 еще в монтаже…
