Unity development methodology

README_RUS.md

Методология разработки на движке Unity

Автор: Богдан Николаев

Цели

1. Сокращение времени на разработку и поддержку программного обеспечения.
2. Сохранение психического здоровья инженеров программного обеспечения.

Применение

Разработка игр и приложений на движке Unity c использованием объектно ориентированной методологии программирования.

Рекомендации

1. Работая над игровой или бизнес логикой, в первую очередь пишите конкретные объекты игровой или бизнес логики.

   Например: Если у вас в игре будет рыцарь, который убивает гоблинов, то в первую очередь создавайте классы Knight и Goblin.

2. При написании объектов соблюдайте принцип единой ответственности. Ответственность объекта должна быть понятна из названия. Название объекта должно отражать его реальную ответственность.

3. Не используйте в названии классов слова Controller, Manager и System. При необходимости, слово Manager используйте только после консультации с главным инженером.

   Например (1): Создавайте объект GameScene, а не GameController. Создавайте объекты MaterialLoader или CharacterMaterials в зависимости от ответственности объекта, а не MaterialManager.

   Такие слова, как Controller и Manager предоставляют объекту больше ответственности, чем необходимо и эта ответственность не очевидна из названия. К примеру, назвав класс MaterialManager, мы подразумеваем что этот класс занимается управлением материалов, но в термин "управление" может входить множество разных действий, таких как: загрузка, настройка, смена материалов и т.д.. Также такой класс может взять на себя ответственность управлением материалами большого количества разных объектов. И первое, и второе ведет к нарушению принципа SoC и переусложнению класса.

   Например (2): Создавайте объект Player, а не PlayerController. Создавайте объект Ads, а не AdManager. Создавайте объект Inventory, а не InventorySystem.

   Такие слова, как Manager, Controller и System подразумевают что объект чем-то управляет, что-то контролирует, или является множеством связанных между собой элементов, но большинство объектов и так чем-то управляют, что-то контролируют или являются множеством связанных между собой элементов и без этих слов. Зачастую, эти слова только добавляют лишнюю искусственную сложность.

   Исключение: В очень редких случаях отсутствие слова Manager влечет за собой усложнение понимания ответственности объекта. Такими случаями могут быть lifetime-менеджмент какой-то группы объектов или управление каким-то конкретным процессом. Например: ChunksManager или SaveLoadManager.

4. При написании объектов придерживайтесь терминологии предметной области, в которой вы работаете.

   Например: Если вы с командой решили, что у вас в игре будет рыцарь, то называйте класс Knight, а не Soldier или Warrior.

   Таким образом вы минимизируете шанс недопонимания (miscommunication) и облегчите работу для новоприбывших инженеров.

5. Если какой-то один функционал может быть у разных объектов, то выносите этот функционал в отдельный компонент.

   Например: Если при каком то событии игровой объект должен выделяться визуальным контуром - не пишите логику выделения контуром в классе этого объекта. Сделайте отдельный компонент Outline.

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

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

   Например: Если объект Soldier будет достаточно комплексным, то его можно разбить следующим образом:

   - Soldier
      - SoldierState
      - SoldierAnimations
          - Animator
      - SoldierPhysics
          - Rigidbody
          - Collider[]
      - SoldierSounds
          - AudioSource
          - AudioClip
      - SoldierAI
      ...
   

   Конкретная структура композитного объекта всегда будет зависеть от проекта. Проектирование этой структуры - это сложная, но важная задача.

7. Используйте наследование, только если объект-родитель и объект-наследник семантически находятся в одной иерархии абстракции.

   Например: Вы не можете наследовать класс Player от класса Character, т. к. игрок является объектом реальной жизни, а персонаж является игровым объектом. Хоть игрок и управляет персонажем, он не является им. В данном случае нужно применить композицию.

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

8. Если вы не можете определиться, что использовать: наследование или композицию - используйте композицию.

Дополнительные рекомендации

• Выучите и соблюдайте принципы KISS, DRY, YAGNI.
• Выучите и соблюдайте принципы S.O.L.I.D.
• Выучите шаблоны проектирования GoF и применяйте их в случае необходимости.
• Прочтите книгу "Совершенный код" от Стива Макконнелла.
• Прочтите книгу "Чистая архитектура" от Роберта Мартина.