2008-09-21 12 views
5

W liniach produkcyjnych Toyoty zawsze wiedzą, jaką ścieżkę podróżowali. Tylko dlatego, że mogą być pewni, że mogą to naprawić, jeśli coś pójdzie nie tak. Czy dotyczy to również oprogramowania?Nigdy nie produkować na nieznaną ścieżkę, również w oprogramowaniu? [Zasada Toyoty]

Wszystkie komunikaty o błędach powinny dokładnie informować, którą ścieżkę przebyli. Niektórzy robią, komunikaty o błędach ze śledzeniem stosu. Czy to jest poprawna interpretacja? Czy można go użyć gdzie indziej?

OK, oto podcast. Myślę, że to ciekawy

http://itc.conversationsnetwork.org/shows/detail3798.html

Odpowiedz

5

Dobry pomysł tam, gdzie to możliwe. Niestety, zwykle trudno jest śledzić całą historię stanu maszyny. Po prostu nie można oznaczyć każdej struktury danych, skąd ją otrzymałeś, i cały obiekt , który jest obiektem. Możesz być w stanie przechowywać tylko wydarzenia zewnętrzne i odtwarzać w ten sposób, skąd pochodzi.

Kilka przykładów:

zrobiłem pracę nad projektem, gdzie było to możliwe i to pomogło ogromnie. Kiedy zbliżaliśmy się do wysyłki, a skończyły się błędy do naprawienia, graliśmy w "tryb zero graczy", w którym komputer wielokrotnie grałby całą noc ze wszystkimi odmianami postaci i ustawień regionalnych. Gdyby potwierdził, wyświetliłby losowy klucz, który rozpoczął mecz. Kiedy przyszliśmy rano do pracy, zapisywaliśmy klucz z ekranu (zwykle taki był) i uruchamialiśmy go ponownie, używając tego klucza. Potem obejrzymy go, dopóki nie pojawi się twierdzenie, i wyśledzimy. Ważne jest to, że możemy odtworzyć wszystkie oryginalne dane wejściowe, które doprowadziły do ​​błędu, i ponownie uruchomić go tyle razy, ile chcieliśmy, nawet po ponownych kompilacjach (w granicach ... liczba pobrań z generatora liczb losowych nie mogła zostać zmieniona , chociaż mieliśmy oddzielny RNG na rzeczy niezwiązane z grą, takie jak visual fx). To zadziałało, ponieważ każdy mecz rozpoczął się po ciepłym ponownym uruchomieniu komputera i jako dane wejściowe pobierał tylko bardzo małą ilość danych.

Słyszałem, że Bungie użył podobnej metody, aby odkryć złą geometrię w ich poziomach Halo.Postawili zestawy dev z dnia na dzień w specjalnym trybie, w którym niezniszczalny protagonista poruszałby się i skakał losowo. Rano będą patrzeć i zobaczyć, czy utknął w geometrii w jakimś miejscu, gdzie nie mógł się wydostać. W grę mogły wchodzić granaty.

W innym projekcie zarejestrowaliśmy wszystkie interakcje użytkownika z sygnaturą czasową, abyśmy mogli je odtworzyć. Działa to świetnie, jeśli możesz, ale większość ludzi ma interakcje ze zmienną bazą danych, której cały stan może nie być tak łatwo zapisany.

+0

Dobra uwaga. Używałem także tego podejścia "przechowuj informacje dookoła" dla narzędzia przetwarzania, aby można było śledzić błędy z wejścia, które spowodowało uszkodzenie pliku wyjściowego lub po prostu spóźnić się (np. Linia pliku wejściowego, w którym rzekomo znajduje się błąd). – steffenj

+0

Mark, czytałem tę odpowiedź i pomyślałem: "Widziałem już to wcześniej". Wtedy zobaczyłem twoje imię. Zdałem sobie sprawę, że pracowaliśmy razem. – Nosredna

0

Jest to dobre podejście. Pamiętaj jednak, że nie powinieneś zbytnio się logować. W przeciwnym razie nie można znaleźć interesujących informacji w całym hałasie i zmniejsza ogólną wydajność (np. Tworzenie anonimowych obiektów, w zależności od języka).

2

To mniej istotne z oprogramowaniem. Jeśli coś pójdzie nie tak w oprogramowaniu, zazwyczaj możesz odtworzyć błąd i przeanalizować go w niewoli. Nawet jeśli zdarza się to tylko raz na 1000, często można włączyć wszystkie rejestracje i uruchomić je 1000 razy (prosty test wygrzewania).

To znacznie droższe i bardziej czasochłonne na linii produkcyjnej, do tego stopnia, że ​​niemożliwe.

Posiadanie jak największej ilości informacji za pierwszym razem, gdy coś idzie nie tak, nie jest złe, ale nie jest tak ważne dla mnie jak dla Toyoty.

0

Generowanie komunikatów o błędach z pełnym śladem stosu to zwykle złe praktyki bezpieczeństwa.
Z drugiej strony, a bardziej zgodnie z intencją Toyoty, każdy opracowany moduł powinien być powiązany z oryginalnym programistą (programistami) - i powinien ponosić odpowiedzialność za tandetną pracę, poprawki błędów, luki w zabezpieczeniach itp. celów dyscyplinarnych, ale zarówno w zakresie utrzymania, jak i edukacji, jeśli jest to konieczne. A może na premie, wręcz przeciwnie ... ;-)

0

Przypomina mi tę rozmowę pod numerem Google Video o "debugowaniu wstecz w czasie". Rzadko (nigdy) używam debuggerów (i nie mogłem znieść głośnika żartobliwego), więc pominąłem rozmowę. Być może jest to dla ciebie interesujące?