Kiedy przychodzisz rano, okazuje się, że twoje oprogramowanie już nie działa, nawet jeśli miało to miejsce, gdy wyszedłeś wczoraj wieczorem.

Co robisz? Co najpierw sprawdzasz? Co robisz, aby przestać się gniewać i zacząć pracować nad swoim problemem? Czy obwiniasz swoich kolegów i idziesz bezpośrednio do nich? Co można zrobić, aby uniknąć bycia w takiej sytuacji?

Zwykłymi podejrzanymi są:

• Myślałeś, że to zadziałało wczoraj, ale po całym dniu pracy byłeś zbyt ślepy, aby zrozumieć, że to nie zadziałało.

• Dziś rano nie możesz już odwoływać się do tego, co było wczoraj w pamięci podręcznej IDE.

• Stacja robocza uruchomiła się ponownie ostatniej nocy lub wyczyszczono katalogi tmp.

• Coś się zmieniło w bazie kodu: sprawdź, czy ktoś (być może ty) popełnił zmiany między ostatnią kompilacją wczorajszą a ostatnią kompilacją dzisiaj.

• Coś się zmieniło w bibliotekach obsługi: sprawdź, czy biblioteki te zostały ponownie skompilowane lub zaktualizowane. Przyczyną może być wewnątrz projektu dla określonych bibliotek lub na zewnątrz, jeśli wdrożono nową wersję pozornie niezależnego pakietu.

• Coś się zmieniło w środowisku testowym: nowa wersja maszyny wirtualnej, zmodyfikowany kod pośredniczący, zmiany na zdalnym serwerze bazy danych ...

• Coś się zmieniło w łańcuchu kompilacji: zmiany w Makefiles, nowa wersja IDE, kompilatora, standardowych bibliotek ...

1) Jeśli dzisiaj nie działa, to również nie działało wczoraj.

Ty myślał , że działa, ale tak nie było.

2) Wystąpił problem i należy go rozwiązać .

Nie myśl o tym, kto jest za to odpowiedzialny, ani o obwinianiu innych.

Jeśli nic się nie zmieniło między wczoraj a dniem dzisiejszym (jak zakładam czytanie twojego pytania), oznacza to, że powinieneś wykonać lepszą pracę w testowaniu swojego kodu, zanim faktycznie powie on, że działa.

Aby uniknąć tej sytuacji, musisz wykonać odpowiednie testy i debugowanie .

Zdefiniuj „działający” i przetestuj granice swoich procedur kodu.

• Postaraj się zostać jednym z użytkowników, którzy będą korzystać z funkcji programu lub kodu.
• Popchnij kod do dozwolonych limitów i dalej, a nawet sprawdź, czy nie działa.

Jednym ze sposobów na to jest zautomatyzowany zestaw obszernych testów przeprowadzanych w nocy, aby następnego dnia sprawdzić, czy coś poszło nie tak i naprawić problemy.

Próba znalezienia kogoś, kto przejmie winę, jest niekonstruktywna i nie rozwiązuje problemów. Nie rób tego

Jeśli coś zadziałało wczoraj i teraz nie działa, to albo masz niedeterministyczne zachowanie (jak warunek wyścigu), a wczorajsza praca była tylko szczęściem, lub coś się zmieniło od tego czasu do teraz i musisz dowiedzieć się, co to jest jest.

To, jak dokładnie dowiesz się, jaki jest przypadek i jak to naprawić, zależy od specyfiki sytuacji, ale zawsze pomaga metodycznie eliminować przyczyny, tj. Nie zmieniaj 5 rzeczy na raz i przestań szukać, czy to pomaga - dowiedz się, która konkretna przyczyna spowodowała problem, i być może zapisz, jak to naprawić, abyś mógł to sprawdzić, kiedy to się powtórzy za 3 tygodnie.

Korzystanie z odpowiednich narzędzi diagnostycznych (debugger, profiler, narzędzia do analizy sieci) również może mieć duże znaczenie.

Pracowałem z kodem, który wydawał się zmieniać z dnia na dzień i po pewnym czasie doszedłem do wniosku, że było to spowodowane złowrogimi wróżkami pełzającymi w nocy do mojej bazy kodu i zmieniającymi rzeczy w taki sposób, że pomimo tego, że działał wczoraj, teraz w ogóle nie działa. Rzeczywiście, w klasycznym stylu Schroedinbug , nie tylko teraz nie działa, ale jest jasne, że nie ma mowy, aby kiedykolwiek mógł.

Z czasem zdałem sobie sprawę, że to możliwe, że w rzeczywistości wróżki nie mają z tym nic wspólnego i że być może mój „czas powrotu do domu, to będzie wystarczająco dobry” ostatni build, nie otrzymuje szczegółowych testów i uwagi, na które być może zasługuje .

Moim pierwszym założeniem, gdy spotykam się z tym rano, jest to, że prawdopodobnie to moja wina, ponieważ zwykle jestem odpowiedzialny za własne funkcje lub rogi oprogramowania, nad którym pracuję. Moje drugie założenie jest takie, że równie dobrze mogę teraz dostać tę kawę. Jeśli nie jest to rażąco oczywiste, że małpa mogła się zorientować (co czasami bywa), istnieje duża szansa, że ​​udało mi się przeciągnąć do starej wersji biblioteki, pomyłkowo przywrócić plik, który nie musiał być zwinięty z powrotem lub mieć coś w pamięci podręcznej, które wprowadziło go do kompilacji bez sprawdzania. Przeglądając moją ostatnią aktywność w zakresie kontroli źródła, zwykle ujawnia się moje działania, czyszczenie kompilacji często usuwa błędne wersje z pamięci podręcznej.

Czasami tak naprawdę nie ma to ze mną nic wspólnego - ktoś zaktualizował zależność, nie wspominając o tym, WindowsUpdate zainstalował coś, co zmieniło środowisko, tak że mój kod nie działał; istnieje wiele możliwości tła, ale zazwyczaj chodzi o załatwienie sprawy i zaakceptowanie tego, że jak większość ludzi jestem w zasadzie idiotą.

Użyj kontroli wersji. Zrób różnicę lub skorzystaj z funkcji obwiniania VCS .:

• diff: Każdy VCS. Pokazuje różnice między różnymi wersjami
• blame: na przykład git. Pokazuje, linia po linii, kto co zmienił

Jeśli nie ma kontroli wersji, poza tym, że jest to twoja wina lub wina twojego szefa, możesz spojrzeć na daty zmiany plików i ewentualnie zajrzeć do funkcji logowania twojego systemu operacyjnego.

Poza tym: Rekompiluj wszystko, pamiętaj też o ponownej kompilacji bibliotek pomocniczych.

Oczywiście: jeśli znalazłeś źródło błędu, zachowaj spokój, zapytaj, dlaczego wprowadzono zmianę, wyjaśnij swój problem i zaproponuj rozwiązanie, które sprawi radość obojgu. Nie krzycz na nią / nią, byłoby to trucizną dla twojej produktywności.

Jeśli nie ma żadnych zmian, czas zobaczyć, co zmieniło się w systemie. Na przykład ostatnio komputery Mac OS zaktualizowały się do nowej wersji Apache, która spowodowała nieprawidłowe konfiguracje niektórych konfiguracji.

Cóż, oto prawdziwy przykład kodu, który „działał wczoraj”, a nie dziś… Jest z początku tego miesiąca.

Ta aplikacja pobiera informacje z bazy danych według daty, a domyślnym zachowaniem jest pobieranie danych dla bieżącego dnia. To zadziałało 8 sierpnia, ale nie powiodło się 9 sierpnia. Nie był wcześniej testowany. Działałoby to również 9 września i 10 października ...

Kolejną wskazówką jest to, że jesteśmy w Wielkiej Brytanii, wspomniana baza danych znajdowała się w USA ...

Tak więc, moja odpowiedź na twoje pytanie dotyczące tego, co najpierw sprawdzić, polega na dwukrotnym sprawdzeniu, jak formatujesz daty, ponieważ jeśli pomieszasz pola dnia i miesiąca, będzie to działało idealnie, ale tylko 1 dnia w miesiącu :-)

Napraw błąd (jak zwykle to robisz). Jeśli dowiesz się, kto go spowodował, wyślij im uprzejmy e-mail z informacją, co poszło nie tak.

Każdy programista popełnia błędy i jeśli zaczniesz obwiniać, to poważnie odbije się to następnym razem, gdy zrobisz to samo. (być może nawet ten błąd był twój)

Tylko jeśli podejrzewasz, że są często nieostrożni, powinieneś zrobić coś dobrego z kilku błędów.

... przeprowadzasz testy regresji i koncentrujesz się na tych, które zawodzą.

W rzeczywistości to, co zapomniałeś zrobić wczoraj przed wyjazdem, zdarza się.

Nie masz żadnych? Ok .. co tam mówisz? Obwinianie ? Cóż ... to może zadziałać

Pierwszą rzeczą do zrobienia, gdy coś przestanie działać, jest zadanie sobie pytania - co innego? Co się zmieniło?

Kiedy coś zadziałało wczoraj wieczorem, ale zawiodło dziś rano, jedyną rzeczą, która oczywiście się zmieniła, jest data i godzina :)

Zastanawiam się, czy jest jakaś część logiki, nad którą pracuję, która zależy od dat i może mieć wpływ na upływ czasu. Zaskakujące jest to, ile razy jest to przyczyną takich problemów.

Jeśli to się nie powiedzie, zdecydowanie powinieneś skorzystać z innych świetnych porad podanych tutaj.

Trochę krótka odpowiedź (do napisania), ale dość długa, aby uzyskać sedno: dlaczego programy zawodzą: przewodnik po systematycznym debugowaniu autorstwa Andreasa Zellera (który może wyglądać trochę zbyt akademicko, ale nie jest)

Patrzysz na swoją skrzynkę pocztową po wiadomości wysłanej przez silnik Continuous Integration, gdy testy jednostkowe nie powiodły się (lub na stronie dziennika, jeśli nie obejrzałeś tego konkretnego problemu) i widzisz, kto dokonał odprawy tuż przed tą kompilacją .

Potem idź z nim porozmawiać.

Są tylko dwa możliwe powody, dla których Twój kod zawodzi dzisiaj, ale działał wczoraj.

Spójrz na dane

Jest coś w danych, których nie testowałeś i które nie uwzględniłeś. Albo dane nie zostały poprawnie sprawdzone, lub błąd logiczny nie został ujawniony, dopóki nie wystąpił warunek logiczny, którego się nie spodziewałeś. Oznacza to, że błąd był wczoraj, ale ukrywał się przed tobą pod ważnymi danymi.

Kiedyś miałem kod dostępu do zamówienia działający dobrze od tygodni. Pewnego dnia poszedłem do domu i to umarło. Badanie następnego dnia ujawniło, że ukryłem błąd w łańcuchu wywołań funkcji. W słabo wpisanym języku zadeklarowałem liczbę całkowitą, kiedy powinienem był użyć długiej liczby całkowitej. Język dokonał konwersji między nimi automatycznie, dopóki nie mógł, ponieważ liczba przekroczyła wartość, która zmieściłaby się w liczbie całkowitej. Awaria systemu przy numerze zamówienia 32768.

Zobacz, co się zmieniło

Zobacz, co się zmieniło, odkąd zadziałało. Czy dział IT wypuścił aktualizację systemu operacyjnego? Czy inny programista zmodyfikował kod używany przez Twój program? Czy uprawnienia użytkownika uległy zmianie? Często, jeśli znajdziesz to, co się zmieniło, znajdziesz błąd.

Binarny kotlet

działa szczególnie dobrze w przypadku trudnych błędów JavaScript. Zasadniczo skomentuj połowę kodu, zobacz, czy wystąpił błąd, jeśli to zrobisz, to w tej połowie kodu. Połowę jeszcze raz i kontynuuj.

Jeśli kod jest dobrze zamknięty, jest to fantastyczne, oszczędzające czas narzędzie do eliminacji stresu.

Po znalezieniu winnego kodu często warto wyodrębnić błąd na własnej stronie testowej.

I oczywiście, co można zrobić, aby uniknąć bycia w takiej sytuacji?

Odpowiadając na to pytanie, możesz zajrzeć do Continuous Integration (CI) . Mówiąc wprost: CI to proces, w którym programiści często (nawet kilka razy dziennie) integrują i testują cały kod. Chodzi o to, że zmiany w jednym module, które psują inny moduł, są szybko odnajdywane.

W praktyce większość zespołów zatrudniających CI korzysta z serwera CI (patrz: lista Wikipedii ). Serwer CI jest zwykle konfigurowany do monitorowania repozytorium SCM i uruchamiania kompilacji, gdy widzi zmiany. Po zakończeniu kompilacji przeprowadzi serię automatycznych testów i opublikuje wyniki za pośrednictwem poczty e-mail i / lub strony internetowej kompilacji oraz testów, wraz z informacją o zmianach, które spowodowały kompilację. Mamy nadzieję, że gdy coś psuje kompilację lub testy, masz tylko bardzo niewielką zmianę do sprawdzenia, więc można ją rozwiązać szybciej.

Są tutaj inne pytania dotyczące tego, z którego serwera CI należy korzystać, więc pozwolę ci znaleźć ich zainteresowanych. Osobiście jestem wielkim fanem Jenkinsa.

[Co powinienem zrobić z tym, że rzeczy się psują.]

Jak już powiedzieli inni, dowiedz się, co się zepsuło i spróbuj to naprawić. Poświęcenie czasu na zrzucenie winy to czas poświęcony na rozwiązanie problemu.

Moja naturalna reakcja jest zawsze do obwiniania innych, ale z czasem doszedłem do zrozumienia, że jest zwykle mi kto jest winy. Oprócz wszystkich powyższych doskonałych komentarzy ważne jest, aby zapisać sobie, jaki był ostateczny powód. Nie ma znaczenia, czy korzystasz z Wiki, która jest udostępniana innym członkom zespołu, prywatnego Twiki, Evernote, dziennika lub dobrej pamięci. Ważne jest, aby w chwili, gdy znajdziesz odpowiedź (i chcesz wrócić do pracy!), Należy zapisać przyczynę.

Prawdopodobnie, jeśli nie działa, zidentyfikowałeś objawy, że nie działa, tzn. Zawiesza się lub wyświetla użytkownikowi określone okno dialogowe błędu.

Jeśli jedynym opisem problemu jest „to nie działa”, pierwszą rzeczą, którą musisz zrobić, to zebrać więcej informacji na temat objawów problemu.

Następnie zaczynasz szukać możliwych przyczyn, albo za pomocą dzienników, albo próby odtworzenia problemu lub kombinacji obu - zależy to od konfiguracji systemu.

Potem zaczynasz je wykluczać.

Tak zwykle dzieje się, kiedy biorę wakacje :-)

Co więcej, najpierw powiem im:

• Przyjrzę się temu, aby zobaczyć, co jest nie tak i co może być przyczyną

• Dotknę bazy za 30-60 minut, kiedy będę miał okazję zobaczyć, co się dzieje

Po tym czasie mogę zaryzykować oszacowanie tego, co mogło się zdarzyć i ile czasu zajmie naprawa, jeśli nie jest to już naprawione i, w stosownych przypadkach, jakie dane mogliśmy utracić (ale mam dobre kopie zapasowe, więc to się nigdy nie zdarza ufnie).

Co do części obwiniającej:

• jeśli jest to tylko literówka kolegi, nie trzeba o tym wspominać: gówno się zdarza, a strach przed robakiem najprawdopodobniej nauczył go lekcji i miejmy nadzieję, że nie zrobi tego ponownie.

• jeśli celowo zrobił coś, co mu powiedziałem, aby tego nie robił (np. podaj hasło root serwera produkcyjnego nowemu facetowi i powiedz mu, żeby dokonał modyfikacji bezpośrednio bez nadzoru) (tak, to już się stało ...), to ja muszę to wspomnieć.

Jeśli zwykłe metody śledzenia błędów nie działają i wszystko jest kompletnym bałaganem, może być cudownie mieć kopię zapasową, którą można łatwo przywrócić.

Oto, co uruchamiam lokalnie, automatycznie co godzinę od 8 rano do 6 wieczorem:

rdiff-backup /path/to/mystuff /path/to/mybackup

Proste, prawda?

Jeśli kiedykolwiek będziesz musiał coś przywrócić, użyj

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

rdiff-backup przechowuje tylko te pliki, które się różnią. Możesz użyć rdiff-backup na Linuxie, Macu i Windowsie.

Oczywiście nie powinna to być twoja jedyna kopia zapasowa. Ale to niezwykle łatwy i tani sposób na lokalne tworzenie kopii zapasowych.

Teraz nie poleciłbym tego jako normalnej metody naprawiania błędów, ale jeśli wszystko inne zawiedzie, jest to awaria.

Błąd mógł już istnieć, ale został ukryty przez czynniki zewnętrzne lub głębokie problemy systemowe.

To mi się przydarzyło. Wystąpił błąd między 2 wersjami naszego projektu. Dosłownie jedyną zmianą , którą wprowadziliśmy, była aktualizacja do nowszej wersji jednej z bazowych bibliotek.

Oczywiście winiliśmy ich. Ale jedyną zmianą , jaką wprowadzili, było przeredagowanie niektórych nagłówków w celu szybszej kompilacji. Zgodziłem się, że nie powinno to zepsuć systemu.

Po długim debugowaniu okazało się, że problemem był fałszywy błąd wskaźnika, który ukrywał się w moim kodzie od lat . Jakoś nigdy się nie uruchomiło, dopóki ich refaktoryzacja nie zmieniła ustawienia pliku wykonywalnego.

działał wczoraj, ponieważ był używany poprawnie.

okazuje się, że inni ludzie używają rzeczy w sposób, który nie przypuszcza, że ​​jest to dobry sposób na łamanie rzeczy.

zawsze dobrze jest aktualizować kod na początku dnia, ponieważ zapewnia to dobre środowisko testowe.

Utworzyć kopię zapasową!

Uważam, że ustawianie punktów przerwania, aby wstrzymywać i sprawdzać moje dane, jest bardzo pomocne, aby dokładnie określić, gdzie i jak idzie źle.