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

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

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

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

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

Ситуация, когда разные входные данные дают одинаковое хеш-значение.

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

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

Сохранённый снимок изменений в репозитории с коротким сообщением о том, что и зачем изменено. Также глагол: зафиксировать изменения.

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

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

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

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

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

В Git — переключить рабочие файлы на ветку или коммит, чтобы просмотреть эту версию кода или работать с ней.

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

В Git переместить коммиты своей ветки так, чтобы они начинались от более новой точки, обычно от актуальной main; история становится линейнее.

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

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

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

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

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

Центральная ветка репозитория с официальной актуальной версией кода. От неё создают другие ветки и обратно в неё сливают изменения.

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

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

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

В Git — временно сохранить незавершённые изменения и очистить рабочую копию, чтобы переключиться на другую задачу и позднее вернуть их.

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

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

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

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

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

Объединить несколько коммитов в один, обычно чтобы упростить историю ветки перед слиянием или проверкой.

Состояние Git, в котором HEAD указывает непосредственно на коммит, а не на имя ветки.

Локальная история изменений ссылок Git, например прежних позиций HEAD или ветки.

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

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

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

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

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

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

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

Сокращение от looks good to me: короткий комментарий проверяющего, означающий, что изменение кода его устраивает и его можно слить.

Небольшой необязательный комментарий при проверке, например об имени, пробелах или формулировке, который не должен блокировать изменение. Часто сокращают до nit.

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

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

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

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

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

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

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

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

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

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

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

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

Сокращение от Don't Repeat Yourself: принцип, согласно которому каждая часть знания или логики должна быть в одном месте, а не дублироваться в коде.

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

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

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

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

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

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

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

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

Небольшой автоматизированный тест отдельной функции или класса, без базы данных, сети и остальной системы.

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

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

Сокращение от quality assurance — работы по проверке соответствия ПО требованиям и его правильной работы. Также так называют людей или команду, выполняющих эту работу.

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

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

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

Поддельная версия реального объекта или сервиса для тестов, поведение которой можно контролировать. Также глагол: имитировать сервис.

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

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

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

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

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

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

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

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

Сокращение от test-driven development: сначала пишут падающий тест, затем код, который его проходит, после чего улучшают код; цикл повторяют.

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

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

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

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

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

Большое разнообразие устройств, размеров экранов, аппаратных характеристик и версий ОС, на которых должно работать приложение; оно усложняет тестирование, особенно на Android.

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

Более быстрый, чем обычно, расход заряда из-за приложения, например при постоянном отслеживании местоположения, частых сетевых запросах или фоновых задачах.

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

Application Not Responding — ошибка Android, возникающая, когда главный поток приложения слишком долго заблокирован, например около пяти секунд не реагирует на касание.

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

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

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

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

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

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

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

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

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