Цей текст про те, як одна зайва кома, переплутаний тип даних або некоректна перевірка можуть коштувати мільйони доларів, а іноді — і людських життів.
Чому у коді виникають помилки
Програмування — це формалізація реальності мовою алгоритмів. Людина мислить контекстами, комп’ютер — інструкціями. Саме на цьому стику і народжуються помилки. Код не здогадується, що автор «мав на увазі». Він виконує те, що написано, а не те, що задумано. Ви будете здивовані, але часто помилки програмістів виникають ще й через особливості мови програмування.
Причини типові:
- когнітивне перевантаження розробника;
- неповна специфікація вимог;
- помилки проєктування архітектури;
- людський фактор і банальна втома;
- відсутність тестування або code review;
- надмірна самовпевненість («я і так усе перевірив»).
Типи помилок у програмуванні
Синтаксичні помилки
Компілятор або інтерпретатор їх одразу знаходить. Пропущена дужка, зайва крапка з комою, помилка в імені змінної. Неприємно, але безпечніше, ніж наступні категорії.
Логічні помилки
Програма працює. Просто неправильно. Наприклад, цикл обчислює суму доn-1замістьn. Дані зберігаються. Результати формуються. І всі впевнені, що система коректна.
Помилки часу виконання
NullPointerException, segmentation fault, ділення на нуль. Класика жанру. Якщо система критична — це може означати аварійне завершення процесу в невдалий момент.
Помилки проєктування
Неправильний вибір алгоритму, відсутність обробки граничних значень, некоректна модель даних. Такі помилки не видно одразу, але вони накопичуються.
Помилки інтеграції
Коли дві системи «розуміють» API по-різному. Один сервер повертає мілісекунди, інший очікує секунди. Здається дрібницею, поки ракета не летить не туди.
Цікавий факт: що таке “off-by-one error”?
Off-by-one error — це помилка, коли цикл або діапазон зсувається на одну ітерацію більше або менше від потрібного значення. Вона виглядає дрібницею, але часто спричиняє критичні збої у системах.
Як убезпечитися від фатальних помилок
Повністю виключити помилки неможливо. Але зменшити їх ймовірність — цілком реально. Вивчаючи популярний онлайн курс Python який побудований та інтерактивних прикладах, ви дізнаєтесь як писати код без помилок. Щоб зменшити кількість помилок рекомендується:
- використовувати модульне та інтеграційне тестування;
- писати автоматизовані тести з покриттям граничних випадків;
- впроваджувати code review;
- застосовувати статичний аналіз коду;
- працювати з чіткими технічними специфікаціями;
- використовувати принципи defensive programming;
- дотримуватись стандартів безпечної розробки.
І ще один простий принцип: якщо код здається занадто розумним — він, швидше за все, занадто крихкий.
Відомі фатальні помилки в історії програмування
- Ariane 5 (1996) — помилка перетворення 64-бітного числа з плаваючою комою у 16-бітне ціле без перевірки переповнення. Виникло виключення, яке не було оброблене. Ракета самознищилась через 37 секунд після старту. Фінансові втрати — приблизно 370 млн доларів.
- Therac-25 (1985–1987) — програмна race condition дозволяла активувати режим високої потужності без належної апаратної перевірки. Через відсутність фізичних блокувань пацієнти отримували передозування радіації. Кілька смертельних випадків.
- Mars Climate Orbiter (1999) — одна команда використовувала фунти-сили, інша — ньютон-метри. Конвертація одиниць не була врахована в програмному забезпеченні навігації. Апарат увійшов в атмосферу Марса під неправильним кутом і був втрачений. Збитки — понад 120 млн доларів.
- AT&T long-distance outage (1990) — помилка в обробці винятку в сигнальному програмному коді комутаційних станцій спричинила каскадне перезавантаження вузлів мережі. Близько 9 годин без міжміського зв’язку для десятків мільйонів користувачів.
- Knight Capital (2012) — застарілий тестовий код був випадково активований у продакшені після часткового оновлення серверів. Алгоритм здійснював тисячі неконтрольованих операцій на біржі. Втрати — близько 440 млн доларів менш ніж за годину.
- Heartbleed (2014) — відсутність перевірки довжини поля у функції обробки heartbeat-запитів в OpenSSL дозволяла зчитувати випадкові фрагменти пам’яті сервера. Уразливість існувала близько двох років до виявлення.
Кілька слів без пафосу
Більшість цих історій не про «поганих програмістів». Вони про відсутність перевірок, тестів, процесів і незалежної валідації. Код рідко ламається гучно одразу. Зазвичай він тихо працює роками — поки не зустріне нестандартний сценарій.
Трохи сарказму наприкінці
Більшість катастроф починались з думки: «Та це ж працює». Проблема в тому, що працює — не означає коректно. А ще гірше — не означає безпечно.
Програміст не планує створити баг. Він просто не планує всі сценарії. Іноді тому, що часу немає. Іноді тому, що «і так зійде». Іноді тому, що тестовий сервер не вибухає.
