Стратегія налагодження

1. Стратегія налагодження важливіша за магію дебагера

Коли програма поводиться неправильно, у голові легко вмикається режим «паніка й шаманство»: змінити кілька рядків, перезапустити — раптом допоможе. Іноді це справді спрацьовує. А іноді ви лише випадково робите гірше, але баг «ховається» й повертається на заліку або вже в продакшені — тобто саме тоді, коли вам психологічно до цього найменше.

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

Сьогодні наша робоча формула така:

flowchart TD
    A[Відтворити баг] --> B[Ізолювати місце/умови]
    B --> C[Сформулювати гіпотезу]
    C --> D[Перевірити гіпотезу в дебагері]
    D --> E{Підтвердилася?}
    E -- так --> F[Виправити мінімальною зміною]
    E -- ні --> C

2. Крок 1: відтворити баг

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

Відтворити означає зробити так, щоб ви могли знову й знову отримувати неправильну поведінку за зрозумілим сценарієм: одні й ті самі вхідні дані → один і той самий неправильний результат. Це важливо, бо інакше ви не зрозумієте, чи допомогло ваше виправлення, чи вам просто «пощастило» і баг не проявився.

Уявімо, що ми розробляємо навчальний консольний застосунок ExpenseTracker — трекер витрат. Він зберігає витрати в std::vector, уміє додавати нові витрати й обчислювати середнє.

Мініверсія «ядра» — поки що без складного інтерфейсу:

#include <iostream>
#include <vector>

int main() {
    std::vector<int> expenses{100, 50, 150};

    int sum = 0;
    for (int x : expenses) sum += x;

    std::cout << "Sum=" << sum << '\n'; // Sum=300
}

Тепер уявімо, що студент додав «середнє» й отримав дивину: Average=100, хоча очікувалося 100.0. На цьому наборі даних різниця ще не дуже помітна, але на іншому вона вже буде відчутною: наприклад, 100 і 101 дадуть 100 замість 100.5. І саме тут важливо мати маленький сценарій, який гарантовано показує помилку.

Хороший відтворюваний приклад саме для цілочисельного ділення:

#include <iostream>
#include <vector>

int main() {
    std::vector<int> expenses{100, 101};

    int sum = 0;
    for (int x : expenses) sum += x;

    double avg = sum / expenses.size();
    std::cout << "Average=" << avg << '\n'; // Average=100 (а хотілося 100.5)
}

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

Багато що в налагодженні впирається саме в дисципліну відтворення: ви зберігаєте точний ввід, точний набір кроків, фіксуєте «очікувалося/вийшло». Якщо програма інтерактивна, корисно тимчасово замінити ввід на наперед задані дані прямо в коді, щоб не вводити вручну десять разів поспіль одне й те саме.

3. Крок 2: ізолювати причину

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

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

Є два дуже практичні способи ізолювати причину.

Перший спосіб — перетворити велику програму на маленьку: тимчасово залишити лише фрагмент, потрібний для відтворення. Якщо баг — «Average=100 замість 100.5», нам не потрібні ані весь CLI, ані меню, ані обробка команд, ані красиві таблиці. Нам потрібен розрахунок середнього.

Винесемо розрахунок у функцію:

#include <vector>

double average_expense(const std::vector<int>& v) {
    int sum = 0;
    for (int x : v) sum += x;
    return sum / v.size(); // підозріле місце
}

І в main залишимо лише мінімальний виклик:

#include <iostream>
#include <vector>

double average_expense(const std::vector<int>& v);

int main() {
    std::vector<int> expenses{100, 101};
    std::cout << average_expense(expenses) << '\n'; // 100 (очікували 100.5)
}

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

Другий спосіб — ізоляція через шлях виконання: ставимо breakpoint у місці, де проявляється помилка, дивимося call stack, йдемо «вгору» й зʼясовуємо, хто передав хибні дані. Це особливо корисно, коли помилка проявляється в маленькій функції, яка сама по собі коректна, але їй передали неправильні аргументи.

4. Крок 3: перевірити гіпотезу

Тепер — найдоросліша частина процесу: гіпотеза. Гіпотеза в налагодженні — це твердження, яке можна перевірити спостереженням.

Погана гіпотеза звучить так: «дебагер тупить», «vector зламався», «C++ дивний». Хороша гіпотеза звучить так: «у нас відбувається цілочисельне ділення, тому що sum і v.size() — цілочисельні операнди».

Щоб гіпотеза була корисною, вона має відповідати на два запитання: «що саме не так?» і «де я це побачу?».

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

Ключовий момент: ми не намагаємося «вгадати виправлення». Ми намагаємося підтвердити причину. Виправлення — це вже наступний крок, і зазвичай воно стає очевидним, щойно причину підтверджено.

5. Мінікейс: середнє в ExpenseTracker

Уявімо, що в застосунку зʼявилася команда avg, яка друкує середню витрату. Ми написали код і отримали дивні результати.

Ось спрощена версія такого розрахунку:

#include <vector>

double average_expense(const std::vector<int>& v) {
    int sum = 0;
    for (int x : v) sum += x;
    return sum / v.size(); // тут народжується баг
}

Відтворення

Ми вже знайшли мінімальний ввід: {100, 101}. Він має давати 100.5, а дає 100. Це стабільний сценарій.

#include <iostream>
#include <vector>

double average_expense(const std::vector<int>& v);

int main() {
    std::vector<int> expenses{100, 101};
    std::cout << average_expense(expenses) << '\n'; // 100
}

Ізоляція

Ізоляцію вже зроблено: у нас одна функція й один виклик. Жодних меню, рядків, парсингу чи «красивого форматування».

Гіпотеза

«Гіпотеза: sum / v.size() виконується як цілочисельне ділення, тому що обидва операнди цілі, і дробова частина відкидається ще до присвоювання в double».

Перевірка гіпотези в дебагері

Що робимо — у термінах дій, а не гарячих клавіш:

Ви ставите breakpoint на рядок return sum / v.size()();, запускаєте програму під дебагером, доходите до цього рядка й дивитеся на значення.

У панелях watches/locals вас цікавлять три речі: sum, v.size() і результат виразу sum / v.size() прямо «як є».

На зупинці ви побачите приблизно таке:

• sum == 201
• v.size() == 2
• sum / v.size() == 100 (а не 100.5)

Це і є підтвердження гіпотези: ділення вже стало цілочисельним.

Виправлення мінімальною зміною

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

#include <vector>

double average_expense(const std::vector<int>& v) {
    int sum = 0;
    for (int x : v) sum += x;

    return static_cast<double>(sum) / v.size(); // тепер ділення double
}

І тепер — тестовий запуск:

#include <iostream>
#include <vector>

double average_expense(const std::vector<int>& v);

int main() {
    std::vector<int> expenses{100, 101};
    std::cout << average_expense(expenses) << '\n'; // 100.5
}

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

6. Граничні випадки: порожній список і зменшення вхідних даних

Інколи помилка не в математиці, а в граничних випадках. Наприклад, avg викликали, коли витрат іще немає. І програма падає. Це класика: ви про це не подумали, користувач — теж, а реальність подумала.

Ось типовий «наївний» код:

#include <vector>

double average_expense(const std::vector<int>& v) {
    int sum = 0;
    for (int x : v) sum += x;
    return static_cast<double>(sum) / v.size(); // якщо size()==0 → ділення на нуль
}

Відтворення

Нам потрібен порожній ввід. Прямо в main:

#include <iostream>
#include <vector>

double average_expense(const std::vector<int>& v);

int main() {
    std::vector<int> expenses;
    std::cout << average_expense(expenses) << '\n'; // аварійне завершення/сміття
}

Ізоляція

Її вже зроблено: знову одна функція.

Гіпотеза

«Гіпотеза: v.size() дорівнює 0, і ми ділимо на нуль».

Перевірка

Breakpoint на рядку ділення, watch v.size(). На зупинці бачимо 0. Гіпотезу підтверджено.

Виправлення

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

#include <vector>

double average_expense(const std::vector<int>& v) {
    if (v.empty()) return 0.0;

    int sum = 0;
    for (int x : v) sum += x;
    return static_cast<double>(sum) / v.size();
}

І знову відтворюємо сценарій: порожній список → тепер друкується 0.0 (або просто 0, якщо вивід форматується без дробової частини).

Ізоляція через зменшення вхідних даних

Часто ви не можете так просто вирізати половину програми: наприклад, баг проявляється лише за певної послідовності команд або на певних даних. Тоді ізоляція досягається не стільки «видаленням коду», скільки зменшенням вхідних даних.

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

Уявімо, що у вас є пошук «найбільшої витрати», але інколи він дає неправильну відповідь. Код:

#include <vector>

int max_expense(const std::vector<int>& v) {
    int m = v[0];
    for (std::size_t i = 1; i < v.size(); ++i) {
        if (v[i] > m) m = v[i];
    }
    return m;
}

Якщо вам сказали «інколи неправильно», ви спочатку відтворюєте помилку: знаходите набір, на якому результат неправильний. Потім ізолюєте причину: починаєте скорочувати набір, доки неправильна поведінка зберігається. Часто виявляється, що проблема проявляється на конкретному граничному випадку: наприклад, за відʼємних значень, повторюваних максимумів або порожнього vector. І тоді гіпотеза стає конкретною: «ми звертаємося до v[0], коли v порожній».

Налагодження в дебагері тут буде майже формальністю: breakpoint на int m = v[0];, watch v.size() — і ви вже розумієте, чому все зламалося.

7. Типові помилки

Помилка № 1: намагатися виправити баг, який ви не вмієте відтворювати.
Якщо ви не можете стабільно отримати неправильну поведінку, то кожне «виправлення» перетворюється на ворожіння на кавовій гущі. Іноді здається, що ви все полагодили, але насправді баг просто не проявився. Правильніше спочатку підібрати мінімальний сценарій, який ламає програму щоразу.

Помилка № 2: «ізолювати» через переписування половини проєкту.
Коли проблема незрозуміла, рука тягнеться до радикальних змін: «давайте перепишемо на інший цикл» або «по-іншому організуймо структуру даних». Це знищує сліди причини й створює нові баги. Ізоляція — це зменшення: вхідних даних, шляху виконання, кількості функцій, які беруть участь у відтворенні.

Помилка № 3: гіпотеза в стилі «усе зламалося».
Фрази на кшталт «vector поводиться дивно» або «умова не працює» не піддаються перевірці. Хороша гіпотеза має стосуватися того, що можна спостерігати: «індекс став рівним size()», «у sum / n обидва операнди цілі», «у цю гілку if ми взагалі не потрапляємо». Тоді ви можете поставити breakpoint і подивитися рівно те, що потрібно.

Помилка № 4: перевіряти гіпотезу не там — не той кадр стека, не та точка зупинки.
Якщо ви зупинилися всередині маленької функції, але причина в тому, що їй передали неправильні аргументи, дивитися потрібно не лише на локальні змінні. Треба піднятися вгору по call stack, перемкнутися на потрібний stack frame і побачити, де саме значення стало неправильним. Інакше легко «звинувачувати» функцію, яка просто чесно працювала з тим, що їй дали.

Помилка № 5: дивитися v[i] без контролю меж прямо у watch.
Watches — потужний інструмент, але вони не зобовʼязані рятувати вас від помилок у логіці. Якщо i уже вийшов за межі, спроба подивитися v[i] може дати сміття або спричинити дивні побічні ефекти спостереження. Хороша звичка — спочатку стежити за i і v.size(), і лише коли ви впевнені, що i < v.size(), дивитися елемент.