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

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

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

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

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

Випадок, коли різні вхідні дані дають однакове хеш-значення.

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

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

Збережений знімок змін у репозиторії з коротким повідомленням про те, що й навіщо змінено. Також дієслово: зафіксувати зміни комітом.

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

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

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

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

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

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

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

У Git перенести коміти своєї гілки так, щоб їхньою основою стала новіша точка, зазвичай останній main; це створює чистішу лінійну історію.

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

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

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

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

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

Центральна гілка репозиторію з офіційною актуальною версією коду. Від неї створюють інші гілки, а потім зливають зміни назад.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скорочення від Don’t Repeat Yourself — принцип, за яким кожен фрагмент знань або логіки має існувати в одному місці коду, а не бути скопійованим у кількох місцях.

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

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

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

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

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

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

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

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

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

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

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

Скорочення від quality assurance: робота з перевірки відповідності програмного забезпечення вимогам і його належної роботи; також назва людей чи команди, що цим займаються.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Велика кількість пристроїв, розмірів екрана, апаратних характеристик і версій ОС, з якими має працювати застосунок; це ускладнює тестування, особливо на Android.

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

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

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

Application Not Responding — помилка Android, що з’являється, коли головний потік надто довго заблокований, наприклад не реагує на дотик близько п’яти секунд.

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

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

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

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

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

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

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

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

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