Английские термины разработки ПО: значения и примеры на русском

Большой игровой мир, который можно исследовать свободно и почти в любом порядке, вместо прохождения фиксированной последовательности уровней.

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

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

Автоматическое создание игрового контента — например карт, подземелий, ландшафтов или добычи — по алгоритмам и правилам, а не вручную.

Упрощенная карта проходимых поверхностей уровня, по которой игровой ИИ прокладывает маршруты и обходит препятствия.

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

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

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

Кадр анимации, в котором аниматор задает важную позу или значение; программа автоматически рассчитывает движение между ключевыми кадрами.

Скрытый скелет из костей и управляющих элементов внутри 3D-модели, которым аниматоры задают позы и движение, словно дергая за нитки марионетки.

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

Графический процессор — чип, который формирует изображение игры, выполняя шейдеры и отрисовывая миллионы пикселей в каждом кадре; процессор CPU выполняет большую часть игровой логики.

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

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

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

Заранее рассчитать ресурсоемкие данные — например освещение, тени или навигацию — и сохранить результат, чтобы не вычислять его во время игры.

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

Подход к проектированию системы, разделяющий обязанности по уровням, например представлению, бизнес-логике и доступу к данным.

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

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

Архитектурный приём, изолирующий пулы ресурсов или компоненты, чтобы сбой одной части меньше влиял на остальные.

Подход, при котором последовательность доменных событий хранится как авторитетная запись, а состояние приложения восстанавливается из этих событий.

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

Проектирование, при котором бизнес-логика отделена от внешних систем и взаимодействует с ними через определённые порты и адаптеры.

Способ постепенной замены устаревшей системы: функции переносят в новую систему и перенаправляют туда соответствующий трафик.

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

Свойство операции, при котором её повторение даёт тот же предполагаемый эффект, что и однократное выполнение.

Последующая бизнес-операция, компенсирующая эффект ранее завершённой операции, если весь процесс завершить не удалось.

Часть функциональности, которую пользователь может видеть или использовать: например, строка поиска, тёмная тема или экспорт отчёта.

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

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

Короткая ежедневная встреча команды, часто на 15 минут, где каждый рассказывает, что сделал, что будет делать и что ему мешает.

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

Упорядоченный список ещё не начатой командой работы: функций, ошибок и улучшений; важные элементы стоят выше.

Примерно определить, сколько времени или усилий потребует задача, прежде чем начать её. Существительное estimate — полученная приблизительная оценка.

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

Краткое описание функции с точки зрения пользователя, часто в форме: «Как [тип пользователя], я хочу [цель], чтобы [причина]».

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

Коротко встретиться или обсудить дела, чтобы обменяться новостями и сверить планы. Также существительное: a quick sync.

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

Популярный фреймворк гибкой разработки, в котором небольшая команда работает короткими фиксированными периодами — спринтами — с определёнными ролями и регулярными встречами для планирования и обзора работы.

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

Решить, какие задачи важнее или срочнее и должны выполняться первыми, особенно если времени на всё не хватает.

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

Единица, которой гибкие команды оценивают объём усилий для задачи с учётом размера, сложности и неопределённости, а не количества часов.

Отправить кому-либо короткое сообщение, обычно в командном чате, чтобы задать вопрос, напомнить о чём-то или привлечь внимание. Технически также означает проверить доступность сервера.

Сокращение от estimated time of arrival. На работе обычно означает, когда, по ожиданиям, будет завершена задача, исправление или доставка.

Способ работы, при котором два разработчика вместе пишут код за одним компьютером или на общем экране: один печатает, другой проверяет и думает на шаг вперёд.

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

Человек или группа, на которых влияет проект или которые могут на него повлиять, например клиенты, руководители, другие команды, юристы или служба поддержки.

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

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

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

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

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

В Scrum — человек, отвечающий за бэклог продукта: он определяет порядок задач, уточняет их и помогает команде сосредоточиться на наиболее ценных.

Конкретная ситуация, в которой человек использует продукт для достижения цели; её описывают пошагово или коротким сценарием.

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

Большой объём работ, который не помещается в один спринт и разбивается на несколько пользовательских историй, например поддержка нескольких валют.

Метод приоритизации, который оценивает идеи по охвату, влиянию, уверенности и трудозатратам, позволяя сравнивать разные предложения.

Метод приоритизации, распределяющий требования по четырём группам: обязательно, желательно, возможно и не входит в этот раз.

Запланированная последовательность и даты основных этапов работы — от начала до запуска.

Проверить с помощью свидетельств — например пользовательских тестов, данных или экспериментов, — верна ли идея, предположение или решение до дальнейших вложений.

Документ с подробным описанием того, как функция должна выглядеть и работать, чтобы дизайнеры и инженеры могли правильно её реализовать.

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

Общий контрольный список условий качества, которым должна соответствовать каждая работа, прежде чем команда назовёт её завершённой: например, тестирование, проверка и документация.

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

Вежливо и с объяснением причин не согласиться с запросом, решением или сроком; также — передвинуть дату на более позднее время.

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

Официально подтвердить, что документ, дизайн или работа приемлемы и можно переходить к следующему этапу.

Краткий регулярный отчёт для заинтересованных сторон о выполненном, следующих шагах, рисках и препятствиях.

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

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

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

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

Быстро рассмотреть поступившие ошибки, запросы или проблемы, оценить срочность и важность и решить, что делать сейчас, позже или не делать.

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

Командный способ оценки, при котором участники одновременно показывают оценки, обсуждают расхождения и оценивают повторно.

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

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

Сокращение от 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-запрос на URL другой системы при событии, например успешной оплате, вместо ожидания запроса.

Предел числа запросов, которые клиент может отправить API за определённое время, например 100 в минуту; он защищает службу от перегрузки и злоупотреблений.

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

Hypertext Transfer Protocol — набор правил, по которым браузеры и серверы обмениваются запросами и ответами в интернете.

Защищённая версия HTTP: она шифрует соединение браузера с сервером с помощью TLS, чтобы посторонние не могли прочитать или изменить данные.