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

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

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

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

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

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

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

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

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

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

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

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

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

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

Змінити код так, щоб проблема більше не виникала; як іменник fix означає зміну, що усуває проблему.

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

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

Навмисно повторити помилку за тими самими кроками, щоб побачити її та знайти причину.

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

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

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

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

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

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

Текст, який програма показує, коли щось іде не так: він повідомляє, що не вдалося, а іноді й чому, наприклад File not found або Connection refused.

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

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

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

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

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

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

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

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

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

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

Безперервне збирання й перевірка системних показників, як-от завантаження процесора, частота помилок і час відповіді, щоб швидко помічати проблеми.

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

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

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

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

Час або частка часу, коли система працює й доступна; часто наводять показник, наприклад 99,9 відсотка за місяць чи рік.

Скорочення від service level agreement: договір, що гарантує клієнтам певний рівень послуг, наприклад доступність 99,9 відсотка, і визначає наслідки невиконання.

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

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

Екран, що об’єднує найважливіші метрики й графіки системи, аби інженери могли швидко оцінити її стан.

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

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

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

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

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

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

Скорочення від service level objective: внутрішній цільовий показник надійності служби, наприклад успішне виконання 99,9 відсотка запитів за 30 днів.

Скорочення від site reliability engineering: застосування методів розробки програмного забезпечення для надійної роботи виробничих систем. Також так називають інженера, який виконує цю роботу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перевірене повторно використовуване розв’язання поширеної задачі проєктування коду, наприклад Singleton, Factory чи Observer; це загальний підхід, а не готовий код.

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

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

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

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

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

Приховування складних деталей за простішим інтерфейсом, щоб користуватися чимось, не знаючи внутрішньої реалізації; наприклад, викликати save(), не знаючи SQL-запиту до бази даних.

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

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

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

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

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

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

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

Будь-який вміст гри — наприклад 3D-модель, текстура, звуковий ефект, анімація чи музика, — зазвичай окремий файл, який імпортують у рушій.

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

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

Скорочення від non-player character: персонаж гри, яким керує комп’ютер, а не гравець, наприклад торговець, замовник завдання чи ворожий вартовий.

Скорочення від heads-up display: інформація поверх ігрового зображення під час гри, наприклад здоров’я, боєприпаси, мапа й рахунок.

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

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

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

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

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

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

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

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

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

Двовимірне зображення, накладене на 3D-модель, щоб надати їй колір і деталі поверхні — текстуру дерева, шкіру чи іржу. Додаткові текстури задають блиск, рельєф і шорсткість.

Кількість полігонів, зазвичай трикутників, у 3D-моделі чи сцені. Менша кількість пришвидшує відтворення, але зменшує деталізацію.

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

Розміщувати персонажа, ворога чи предмет в ігровому світі або з’являтися в ньому. Spawn point — місце появи.

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