Англійська для розробників Unity

Компонентна архітектура Unity і її особливості продуктивності — піки збирання сміття, Update витрати на петлі, перезаписи префаб — генерують свій власний словник в обговореннях команди. Цей посібник містить інформацію про англійську мову, яку використовують під час обговорення проектів Unity з програмістами, дизайнерами і виробниками.

Ключовий словник

** GameObject ** — базовий контейнер у сцені Unity, який отримує поведінку і вигляд за допомогою приєднаних компонентів, а не за допомогою успадкування. “Не додавайте логіку гри безпосередньо до ієрархії перетворень цього GameObject — розділяйте відповідальність між окремими компонентами, щоб кожен з них залишався перевіряним.”

** Prefab ** — збережений шаблон для GameObject і його компонентів, який можна використовувати повторно, створювати його екземпляри декілька разів і оновлювати його усюди одночасно, коли змінюється сам prefab.

• “Якщо нам потрібні три варіанти цього ворога, скористайтеся готовими варіантами замість дублювання всього готового варіанту — інакше спільне виправлення означатиме редагування трьох окремих активів.” *

** Компонент ** — модульний скрипт або вбудована поведінка (Rigidbody, Collider, нетиповий MonoBehaviour ), що прив’ язано до GameObject, щоб надати йому певну функціональність.

• “Пересунути цю логіку здоров’ я зі скрипту контролера гравця до його власного компонента — зараз дві неспоріднені системи залежать від цього одного великого скрипту.” *

** Coroutine ** — метод, специфічний для Unity, який може призупинити виконання і відновити його пізніше у різних кадрах, зазвичай використовується для послідовностей, що базуються на часі, без блокування головної нитки. “Не використовуйте Thread.Sleep для цієї затримки — використовуйте коротину з yield return new WaitForSeconds, або ви заморозите всю гру.”

** Пік збирання сміття ** — затримка частоти кадрів, спричинена відновленням пам’ яті збиральником сміття. NET, часто викликана частими розподілами у шляхах гарячого коду, таких як Update. “Це з’єднання рядків в Update виділяється кожному кадру — це, ймовірно, джерело GC-шпиків, які ми бачимо на пристроях нижчого рівня.”

** Серіалізоване поле ** — приватне поле, відкрите для інспектора Unity за допомогою [SerializeField], що дозволяє дизайнерам налаштовувати значення без публікації поля у коді. “Зберігати це поле приватним і позначати його [SerializeField] замість того, щоб зробити його публічним — дизайнери все одно отримають це поле в інспекторі, але інші скрипти не зможуть дістатися до нього і змінити його безпосередньо.”

Звичайні фрази

• Чи це виділяється кожен кадр в Update, або це може викликати GC-спайк під навантаженням?
• «Чи повинен це бути готовий варіант замість повного дублікату, так що спільний виправлення потребує тільки одного редагування?»
• «Чи є ця спільна програма насправді правильним інструментом тут, чи буде асинхронне завдання або станова машина яснішою?»
• Чи має це поле бути публічним, чи воно має бути серіалізованим приватним полем?
• «Скільки компонентів дійсно потрібних для цього GameObject — чи краще розділити якусь з цієї відповідальності?»

Приклади висловлювань

Перегляд запиту на звантаження: “Цей Update метод робить виклик GetComponent кожному кадру — кешувати посилання в Awake замість цього, оскільки пошук не є вільним в масштабі.”

Пояснення рішення про проектування: “Ми розділилися поведінку ворога на маленькі компоненти замість одного великого сценарію, тому дизайнери можуть змішувати і збігати здібності без торкання до коду.”

Опис події: “Зависання на мобільному призводить до того, що спільна програма виділяється новий об’ єкт WaitForSeconds кожну ітерацію петлі замість кешування його один раз.”

Професійні поради

• Скажіть “cache the reference” при перегляді повторюваних викликів GetComponent або Find — це стандартна виправлення, яку переглядачі очікують побачити явно названу.
• Розрізняти « prefab » від « prefab variant » точно — об’ єднання їх у розмові спричиняє справжню плутанину щодо того, на який актив має бути спрямовано виправлення.
• Позначте “allocation in Update ” як свою власну категорію проблеми — це добре відомий запах продуктивності Unity, відмінний від загальних коментарів перегляду коду.
• Використовуйте “серіалізоване поле” замість “публічна змінна” при обговоренні даних, відкритих інспектором — це означає, що ви розумієте шаблон інкапсуляції Unity.

Практичні вправи

1. Поясніть у двох реченнях, чому кешування посилання на компонент в Awake краще, ніж виклик GetComponent в Update.
2. Написати коментар перегляду коду у одному реченні, у якому буде позначено призначення кадрів.
3. Опишете вашими словами відмінність між готовим до використання і готовим до використання варіантом.

Науковий ступінь: доктор технічних наук

Ядро ефективного спілкування як розробника Unity не тільки в тому, щоб знати, як використовувати GameObject.SetActive(true) ; це про вираження * чому * ви це робите, і передачі вашого процесу мислення чітко іншим. Це особливо важливо при роботі в командах, де існують різні рівні технічного розуміння. Не-рідні англомовні люди часто знаходять швидкий обмін технічними термінами приголомшливим, що призводить до непорозумінь під час перегляду коду, обговорення дизайну або навіть простих розмов Slack. Ключовим є перехід від перекладу на слово до фразування, що відображає процес мислення професійного розробника - демонструючи не тільки * що * ви робите, але * чому * це має значення.

Одна з найпоширеніших областей тертя виникає при поясненні складної логіки комусь, хто не знайомий з нюансами співпрограм. Просто сказати «Ця програма обробляє асинхронне завантаження» недостатньо. Ефективнішим підходом було б: «Я реалізував цей графік, щоб забезпечити плавний досвід користувача під час завантаження активів. Він використовує WaitForSeconds, щоб уникнути блокування головної нитки і запобігти потенційному зниженню частоти кадрів під час завантаження великих текстур. ” Зауважте додані деталі: визнання * впливу * на користувача, пояснення міркувань, які стоять за вибором методу ( WaitForSeconds ), і підсвічування потенційної проблеми, якої слід уникати — важливий елемент ефективного технічного спілкування. Аналогічно, під час перегляду коду, фрази на кшталт «Це можна було б переробити для кращої продуктивності» вимагають пояснення. Замість того, щоб просто вказувати на неефективність, розробники повинні розробляти: «Я помічаю деякі зайві обчислення тут; переробка цієї секції з мемоізацією значно зменшить навантаження на процесор, особливо на пристроях нижчого рівня»

Інша часте виклик виникає з точності, що вимагається в описах для запитів на захоплення. Просте “Видалити баги” - це жахлива реклама. Замість цього, щось на зразок: «Ця комісія вирішує критичну проблему, коли рух гравця не відповідав після тривалого використання здатності спринту через умову гонки в рамках графіка. Я реалізував механізм блокування, використовуючи lock(), щоб забезпечити безпеку потоку і запобігти цій поведінці. “Детальні пояснення демонструють обізнаність про потенційні проблеми, чітко описують рішення і обґрунтовують зміну.

# Example: Using Unity's Asset Bundle Manager (ABM) command-line tool
# to list all bundles in a project directory.  (Illustrative; not directly used in code review).
abm list -d /Assets/Bundles

Врешті-решт, зосередження на чітких поясненнях і виправданнях створює довіру в команді і запобігає дорогим переробкам через неправильні тлумачення.