Англійська лексика для розробників програмного забезпечення

Великий ігровий світ, який можна вільно досліджувати майже в будь-якому порядку, а не проходити фіксовану послідовність рівнів.

Рання версія рівня з простих сірих форм без фінальної графіки, потрібна для перевірки планування, масштабу, маршрутів і часу до роботи художників.

Найкоротший маршрут через рівень чи гру, яким гравець має пройти для завершення; на відміну від необов’язкових зон, секретів і побічних завдань.

Автоматичне створення ігрового вмісту — мап, підземель, місцевості чи здобичі — за алгоритмами й правилами замість ручного виготовлення кожного елемента.

Скорочення від navigation mesh: спрощена мапа прохідних поверхонь рівня, якою ігровий ШІ користується для пошуку шляху й обходу перешкод.

Об’єкт фізичного рушія, що зберігає форму й рухається під дією сил, як-от тяжіння та зіткнення; приклади — падучий ящик чи кинута граната.

Перевірка, під час якої гра випускає з точки невидиму пряму лінію в заданому напрямку й визначає, у що вона влучила першою; застосовується для стрільби, видимості й перевірки землі.

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

Кадр анімації, у якому аніматор задає важливу позу чи значення; програма автоматично обчислює рух між ключовими кадрами.

Прихований скелет із кісток і контролерів усередині 3D-моделі, яким аніматори рухають для створення поз і анімації, наче нитками маріонетки.

Команда, яку процесор надсилає відеокарті для відтворення групи полігонів з одним матеріалом; надмірна кількість таких команд за кадр може сповільнити гру.

Скорочення від graphics processing unit: чип, що відтворює зображення гри за допомогою шейдерів і малювання мільйонів пікселів кожного кадру; більшу частину логіки гри обробляє CPU.

Візуальні ефекти, що застосовуються до всього зображення після відтворення сцени, наприклад сяйво, розмиття руху, корекція кольору й глибина різкості.

Інструмент для створення ефектів — вогню, диму, іскор, дощу чи магії — через випуск і рух багатьох малих зображень або форм, які називають частинками.

Прийом, за якого модель замінюється простішими варіантами, коли віддаляється від камери, щоб дальні об’єкти мали менше полігонів і гра працювала швидше.

Попередньо обчислити витратні дані, наприклад освітлення, тіні чи навігацію, і зберегти результат, щоб не рахувати його під час гри.

Інструмент, що вимірює використання часу й пам’яті грою кадр за кадром, щоб розробники знаходили причини сповільнення, а не здогадувалися.

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

Архітектурний стиль, за якого можливості системи організовано як окремі сервіси, що взаємодіють через визначені інтерфейси.

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

Проєктне рішення, що ізолює пули ресурсів або компоненти, зменшуючи вплив збою однієї частини на решту системи.

Зберігання послідовності предметних подій як авторитетного запису з подальшим відновленням стану застосунку з цих подій.

Принцип проєктування, що відокремлює операції зміни стану від операцій отримання даних без зміни стану.

Архітектура, що зберігає незалежність предметної логіки від зовнішніх систем, з’єднуючи їх через визначені порти й адаптери.

Поступова заміна застарілої системи: її можливості переносять у нову систему й спрямовують туди відповідний трафік.

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

Властивість, за якої повторення операції має той самий очікуваний ефект, що й одноразове виконання.

Пізніша бізнес-операція, що компенсує наслідки вже завершеної операції, коли весь робочий процес неможливо завершити.

Частина функціональності, якою користувач може скористатися або яку може побачити, наприклад пошук, темний режим чи експорт звіту.

Запис у трекері на кшталт Jira, що описує одиницю роботи — помилку, завдання чи функцію — та показує відповідального й статус.

Визначений період, зазвичай один або два тижні, протягом якого команда бере зобов’язання виконати обраний набір робіт.

Коротка щоденна зустріч команди, часто на 15 хвилин, де кожен розповідає, що зробив, що робитиме далі й чи щось його блокує.

Функція, яку програма має виконувати, або умова, якій вона має відповідати за домовленістю з користувачами, клієнтами чи продуктовою командою.

Упорядкований перелік робіт, до яких команда ще не взялася, наприклад функцій, помилок і поліпшень; найважливіше розміщують угорі.

Приблизно визначити, скільки часу чи зусиль потребуватиме завдання, перш ніж почати; estimate як іменник — така приблизна оцінка.

Проблема, що не дає людині продовжити роботу, доки її не розв’яжуть, наприклад відсутність доступу, відповіді чи справного середовища.

Короткий опис функції з погляду користувача, часто у формі «Як [тип користувача], я хочу [мета], щоб [причина]».

Опис способу роботи короткими циклами з частою доставкою невеликих частин і коригуванням планів на основі відгуків, а не виконанням одного довгого незмінного плану.

Провести коротку зустріч або розмову, щоб обмінятися новинами й переконатися, що всі мають однакову інформацію та план; також іменник quick sync.

Не належить до робіт, погоджених для проєкту, спринту чи тікета, тому зараз не виконуватиметься, навіть якщо це гарна ідея.

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

Зустріч наприкінці спринту або проєкту, на якій команда обговорює, що вдалося, що не вдалося та що варто змінити наступного разу.

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

Перелік конкретних умов, яким має відповідати функція або користувацька історія, перш ніж команда й власник продукту погодяться, що роботу завершено.

Одиниця, якою гнучкі команди оцінюють обсяг зусиль для завдання з урахуванням його розміру, складності й невизначеності, а не кількості годин.

Надіслати комусь коротке повідомлення, зазвичай у робочому чаті, щоб поставити запитання, нагадати про себе або привернути увагу. У технічному значенні — перевірити доступність сервера.

Скорочення від estimated time of arrival — на роботі зазвичай означає, коли, на вашу думку, буде завершено завдання, виправлення чи доставку.

Спосіб роботи, за якого двоє розробників пишуть код разом за одним комп’ютером або спільним екраном: один друкує, інший перевіряє й продумує наступні кроки.

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

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

Людина, яка визначає, що має робити продукт і навіщо, розуміючи користувачів і бізнес та спрямовуючи команду розробки.

Загальний план роботи продуктової команди на найближчі місяці чи квартали з поясненням пріоритетів, але без переліку кожного завдання.

Скорочення від minimum viable product: найпростіша версія продукту, яку можна випустити реальним користувачам, щоб з’ясувати, чи варто розвивати ідею далі.

Скорочення від product requirements document: документ, що пояснює, що має робити функція чи продукт, для кого й навіщо, аби команда працювала за спільним планом.

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

У Scrum — людина, відповідальна за беклог продукту: визначає порядок елементів, робить їх зрозумілими й стежить, щоб команда працювала над найціннішим.

Конкретна ситуація, у якій людина користується продуктом для досягнення мети, описана кроками або коротким сценарієм.

Скорочення від objectives and key results: метод постановки цілей, у якому команда визначає надихальну ціль і від двох до п’яти вимірюваних результатів поступу.

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

Метод пріоритизації, який оцінює кожну ідею за охопленням, впливом, упевненістю й зусиллями, щоб порівнювати різні пропозиції.

Метод пріоритизації, що розподіляє вимоги на чотири групи: обов’язкові (Must), бажані (Should), можливі (Could) і ті, від яких цього разу відмовляються (Won’t).

Запланована послідовність і дати головних етапів роботи від початку до запуску.

Перевірити на доказах — наприклад тестах із користувачами, даних чи експериментах, — чи справді правильні ідея, припущення або рішення, перш ніж інвестувати в них далі.

Скорочення від specification: документ із докладним описом вигляду й поведінки функції, за яким дизайнери та інженери можуть правильно її створити.

Пропозиція клієнта, користувача чи колеги додати нову функцію або змінити наявну.

Спільний перелік умов якості, яким має відповідати кожен результат роботи, перш ніж команда визнає його готовим, наприклад тестування, перевірка й документація.

Регулярна робота, під час якої власник продукту й команда переглядають майбутні елементи беклогу, прояснюють їх, ділять великі на менші й оцінюють, щоб підготувати до спринту.

Не погодитися із запитом, рішенням чи строком або чинити їм опір, зазвичай ввічливо й з поясненням; також означає перенести дату на пізніше.

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

Надати формальне схвалення документа, дизайну чи виконаної роботи, щоб можна було перейти до наступного кроку.

Короткий регулярний звіт для зацікавлених сторін про зроблене, наступні кроки та наявні ризики чи перешкоди.

Формальне рішення, зазвичай на зустрічі незадовго до запуску, чи готовий продукт або випуск виходити, чи його треба відкласти.

Поступово припинити роботу продукту чи функції та її підтримку, зазвичай завчасно попередивши користувачів і допомігши перейти на альтернативу.

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

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

Швидко переглянути нові помилки, запити чи проблеми й розподілити їх за терміновістю та важливістю, вирішивши, що робити зараз, пізніше або не робити.

Практика, коли компанія сама користується власним продуктом, часто до його випуску, щоб знаходити проблеми й особисто розуміти досвід користувачів.

Командний спосіб оцінювання, за якого учасники одночасно показують свої оцінки, обговорюють розбіжності й оцінюють ще раз.

Мінімальна робоча реалізація, що з’єднує основні архітектурні частини невеликим наскрізним сценарієм.

Спільна практика, що залучає бізнесову, розробницьку й тестувальну перспективи для уточнення очікуваної поведінки.

Скорочення від application programming interface: набір правил, за якими одна програма запитує дані чи дії в іншої у визначений і задокументований спосіб.

Конкретна URL-адреса API, що приймає запити певного типу, наприклад GET /users для списку користувачів або POST /orders для створення замовлення.

Скорочення від representational state transfer: поширений стиль веб-API, де ресурси мають URL-адреси й обробляються HTTP-методами GET, POST, PUT і DELETE.

Скорочення від JavaScript Object Notation: простий текстовий формат даних із парами ключ-значення та списками, який використовує більшість веб-API.

Тризначне число у відповіді HTTP, що повідомляє клієнту результат: наприклад 200 — успіх, 404 — не знайдено, 500 — помилка сервера.

Дані, які передає запит, відповідь чи повідомлення, на відміну від заголовків та іншої супровідної інформації.

Процес перевірки, ким є користувач або система, наприклад за паролем, токеном чи відбитком пальця, перш ніж надати доступ.

Створений або наданий зовнішньою компанією чи розробником, а не вашою командою, наприклад платіжний сервіс, бібліотека чи аналітичний інструмент.

Скорочення від software development kit: набір бібліотек, інструментів і документації, що допомагає розробникам створювати програми для платформи чи користуватися сервісом.

Зміна API, бібліотеки чи формату файлу, через яку наявний код, що ним користується, перестає працювати без оновлення.

Повідомлення, яке клієнт надсилає серверу або API з проханням виконати дію, наприклад повернути дані чи зберегти новий запис.

Повідомлення, яке сервер або API надсилає у відповідь на запит; зазвичай воно містить код стану, заголовки й дані, наприклад JSON.

Унікальний секретний код, який програма надсилає разом із запитами, щоб API міг визначити клієнта й вирішити, які дії йому дозволені.

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

Процес перевірки того, які дії дозволені ідентифікованому користувачеві або застосунку, наприклад читання файла чи видалення облікового запису.

Спосіб, у який одна система автоматично надсилає HTTP-запит на адресу іншої системи після певної події — наприклад успішної оплати, — замість того щоб чекати на запит.

Обмеження кількості запитів, які клієнт може надіслати до API за певний час, наприклад 100 за хвилину, щоб захистити сервіс від перевантаження чи зловживань.

Такий, що й далі працює зі старішими версіями, даними або клієнтами після зміни, тож чинним користувачам не потрібно оновлювати код чи налаштування.

Протокол передавання гіпертексту (Hypertext Transfer Protocol) — набір правил, за якими браузери й сервери обмінюються запитами та відповідями в інтернеті.

Захищена версія HTTP, яка шифрує з’єднання між браузером і сервером за допомогою TLS, щоб сторонні не могли прочитати чи змінити дані.