Skip to content

Instantly share code, notes, and snippets.

@Bodix

Bodix/README_RUS.md

Last active July 18, 2023 07:00
Download ZIP

Revisions

  1. Bodix revised this gist Jul 18, 2023. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion README_RUS.md
    View file
    Original file line number Diff line number Diff line change
    @@ -55,7 +55,7 @@
    >
    >Таким образом, функционал выделения визуальным контуром можно будет использовать на разных объектах, а также сохраняется принцип единой ответственности: класс объекта содержит только логику этого объекта.
    6. Если какой-то объект становится (или станет в будущем) настолько большим, что с ним неудобно работать, то используйте шаблон проектирования **Composite** чтобы разбить объект на части.
    6. Если какой-то объект становится (или станет в будущем) настолько большим, что с ним неудобно работать, то используйте компонентно-ориентированное программирование в связке с композицией чтобы разбить объект на части.

    >**Например:**
    >Если объект `Soldier` будет достаточно комплексным, то его можно разбить следующим образом:
  2. Bodix revised this gist Jul 4, 2023. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion README_RUS.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    # Методические рекомендации по программированию на движке Unity
    # Методология разработки на движке Unity

    **Автор:**
    Богдан Николаев
  3. Bodix renamed this gist Aug 21, 2022. 1 changed file with 0 additions and 0 deletions.
    0 README.md → README_RUS.md
    View file
    File renamed without changes.
  4. Bodix renamed this gist Aug 21, 2022. 1 changed file with 0 additions and 0 deletions.
    0 README_RUS.md → README.md
    View file
    File renamed without changes.
  5. Bodix created this gist Aug 21, 2022.
    95 changes: 95 additions & 0 deletions README_RUS.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,95 @@
    # Методические рекомендации по программированию на движке 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. Если какой-то объект становится (или станет в будущем) настолько большим, что с ним неудобно работать, то используйте шаблон проектирования **Composite** чтобы разбить объект на части.

    >**Например:**
    >Если объект `Soldier` будет достаточно комплексным, то его можно разбить следующим образом:
    >
    >```text
    >- Soldier
    > - SoldierState
    > - SoldierAnimations
    > - Animator
    > - SoldierPhysics
    > - Rigidbody
    > - Collider[]
    > - SoldierSounds
    > - AudioSource
    > - AudioClip
    > - SoldierAI
    > ...
    >```
    >
    >Конкретная структура композитного объекта всегда будет зависеть от проекта. Проектирование этой структуры - это сложная, но важная задача.
    7. Используйте наследование, только если объект-родитель и объект-наследник семантически находятся в одной иерархии абстракции.
    >**Например:**
    >Вы не можете наследовать класс `Player` от класса `Character`, т. к. игрок является объектом реальной жизни, а персонаж является игровым объектом. Хоть игрок и управляет персонажем, он не является им. В данном случае нужно применить композицию.
    >
    >Таким образом в будущем нам легче будет сделать так, чтобы игрок мог управлять группой персонажей или вообще не персонажем, а другим объектом.
    8. Если вы не можете определиться, что использовать: наследование или композицию - используйте композицию.
    ## Дополнительные рекомендации
    - Выучите и соблюдайте принципы KISS, DRY, YAGNI.
    - Выучите и соблюдайте принципы S.O.L.I.D.
    - Выучите шаблоны проектирования GoF и применяйте их в случае необходимости.
    - Прочтите книгу "Совершенный код" от Стива Макконнелла.
    - Прочтите книгу "Чистая архитектура" от Роберта Мартина.