Надійність інтерфейсу та обробка помилок

Чому застосунки ламаються в руках користувачів?

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

Якщо програма не підготовлена до таких дій, інтерфейс руйнується: на екрані з'являються помилки NaN (Not-a-Number), блоки спотворюються або застосунок перестає реагувати на наступні кліки. Справжній інженерний рівень продукту визначається не тим, як гарно він працює з ідеальними даними, а тим, як елегантно і надійно він реагує на некоректні дії.

Життєвий цикл дефекту: від фіксації до закриття

Коли під час тестування ви виявляєте аномальну поведінку, процес її усунення повинен відбуватися за суворим інженерним циклом:

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam activityBorderColor #1E293B
skinparam activityFontSize 13

start
:1. Виявлення аномалії в інтерфейсі;
:2. Фіксація кроків відтворення;
note right #FEF3C7
  Точні дії: що ввів, 
  куди клікнув
end note

:3. Складання опису:
Expected vs Actual;

:4. Точковий запит до AI на виправлення;
note right #DCFCE7
  Передача умов валідації 
  без зміни решти логіки
end note

:5. Верифікація виправлення;
if (Баг зник, а основний сценарій працює?) then (так)
  :Закриття дефекту та Snapshot;
  stop
else (ні)
  :Уточнення крайової умови;
  backtrack
endif
@enduml

Анатомія людиноорієнтованих повідомлень про помилки

Поширена помилка — виведення абстрактних повідомлень на кшталт «Помилка!», «Невірні дані!» або використання стандартного системного вікна alert(), яке блокує інтерфейс браузера і дратує користувача.

Якісне повідомлення про помилку повинно відповідати трьом правилам:

1. Зрозумілість: повідомлення описує проблему зрозумілою людині мовою без технічного жаргону.
2. Конструктивність: воно чітко підказує, яку саме дію потрібно виконати для виправлення ситуації.
3. Візуальна локалізація: попередження з'являється поруч із проблемним полем, підсвічуючи його контур червоним акцентом.

Формулювання промпту для усунення дефекту

Коли ви передаєте задачу на дебагінг мовній моделі, використовуйте класичний стандарт інженерного баг-репорту:

Знайдено дефект у валідації вхідних даних:
- Кроки для відтворення:
  1. Очистити поле введення кількості сторінок (залишити порожнім).
  2. Натиснути кнопку «Розрахувати».
- Фактична поведінка: блок результату відображає «0 хв», що вводить користувача в оману.
- Очікувана поведінка: 
  1. Блок результату залишається прихованим.
  2. Під полем введення з'являється блок #error-message із текстом: «Вкажіть кількість сторінок».
  3. Поле введення отримує червону рамку (клас .input-error).
  4. При повторному введенні валідного числа стан помилки автоматично зникає.

Реалізуй цю перевірку у файлі main.js. Не змінюй формулу розрахунку.

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

Практичні завдання та запитання для самоконтролю