„Wczoraj działało, przysięgam!” Co możesz zrobić? [Zamknięte]

59

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?

Nikko
źródło
10
Obwinianie nigdy nie jest świetnym pomysłem. Ponieważ nie opracowałeś pytania lub problemu, nie można zgadnąć, że program sam nie spowodował błędu. Na przykład: jeśli witryna na serwerze hostingowym osiągnie limit przepustowości, sama się wyłącza. Dlatego nie możesz winić nikogo, dopóki nie upewnisz się, że kod nie zachowywał się odpowiednio.
Pankaj Upadhyay
1
cóż, to nie jest przepełnienie stosu, więc jest to bardziej ogólne pytanie. Obwinianie jest żartem :)
Nikko
28
@Nikko - też nie działało wczoraj. TO dzieje się często przy tworzeniu oprogramowania :)
Joris Timmermans
4
Aby uniknąć sytuacji, nie spiesz się z testowaniem, abyś mógł wdrożyć go w ciągu ostatnich kilku minut po południu. I zdejmij okulary przeciwsłoneczne zabarwione różą / wrażliwe na ryzyko podczas testowania.
Steve314,
18
Czy to ma coś wspólnego z DateTime.Now () ???
Sarawut Positwinyu

Odpowiedzi:

96

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 ...

mouviciel
źródło
82
Zapomnieliście o „boskiej interwencji” i „cząstka o wysokiej energii przeszła przez serwer i losowo przestawiła bity”. I erupcje słoneczne.
Kheldar
17
Zapomniałeś „używasz <wstaw tutaj swój ulubiony język>, co jest notorycznie niewiarygodne.
konfigurator
4
@Kheldar - nie zapomnij złośliwych duszków, gremlins i in.
5arx
5
@configurator: dlatego zawsze powinieneś pisać swój własny język. Zapytaj Spolsky'ego o Wasabi! sprawdza, czy Atwood jest w pobliżu i ucieka
Kheldar
13
kolejną klasyczną pułapką jest zmiana daty. Dotyczy to oczywiście szczególnie dat „limitowanych” (pierwszy lub ostatni dzień miesiąca / tygodnia, 29 lutego itd.).
Brann
49

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.

Jose Faeti
źródło
7
Chcę dać wam dwa pozytywne głosy - po jednym dla „Jeśli dziś nie działa, to i wczoraj nie działało”. i jeden dla „istnieje problem i musi zostać rozwiązany”. Oba są kluczowymi pomysłami, o których zapomina zbyt wiele osób.
MattBelanger
2
„Jeśli dzisiaj nie działa, to też nie działało wczoraj”. -> Zdarzyło mi się to wczoraj, robiąc kodowanie front-end, które opierało się na pliku cookie. Działa świetnie, gdy plik cookie został już ustawiony. Dowiedziałem się, że nie był już właściwie tworzony następnego dnia, kiedy wygasł i próbował zostać odtworzony.
Graham
@Graham: patrz „Jeśli nic się nie zmieniło między wczoraj a dziś [...], oznacza to, że powinieneś lepiej wykonać test kodu, zanim faktycznie powie on, że działa”. Musisz być lepszy w testowaniu kodu, zastanowić się, co powinno się zdarzyć, pomyśleć o tym, co może się wydarzyć. Być może przy lepszym zrozumieniu problemu tak się nie stało.
Jose Faeti
Co do 1): być może przełomowa zmiana miała miejsce w bibliotece pomocniczej
fresnel
Nie do końca prawda ...: PI przypadkowo zepsuł aplikację, wciągając do mojej aplikacji pliki pamięci podręcznej, które były obiektami, które zostały całkowicie niepoprawnie zserializowane. Aplikacja była w porządku i działała dobrze, po prostu kiedy zrobiłem ściąganie git, ponieważ pliki pamięci podręcznej były ignorowane, program zaktualizował się i potrzebował obiektów w innym formacie. Nadal dostajesz jednak głosowanie;)
Laykes
26

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.

Michael Borgwardt
źródło
Pomocne może być także pisanie notatek podczas analizy problemu.
starblue
25

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ą.

glenatron
źródło
1
Jest to bardzo pokorna i poniżająca odpowiedź, którą wielu z nas powinno przyjąć. :) Zazwyczaj piszę takie sytuacje aż do: „Hej Moe, Hej Larry, starałem się myśleć i nic się nie działo!” pod koniec dnia. Używam również metody „To działa! Szybko, sprawdź to i idź do domu, zanim będziesz miał ochotę to poprawić” pod koniec dnia, aby uniknąć takich sytuacji.
Jennifer S
3
W jednym miejscu, w którym pracowałem, nikt nie działałby z samego rana. Okazało się, że kiedy uruchamialiśmy nasze maszyny, Skype pobierał port, z którego aplikacja chciała korzystać przy pierwszym uruchomieniu.
thepeer
Może pixie jest niczym więcej niż niezainicjowaną zmienną? Czasami wersja debugowania może działać, gdy wersja wydania zawiedzie (ulega awarii lub zachowuje się inaczej).
Jared Updike
20

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.

fresnela
źródło
1
Diff Ftw. to zawsze robię.
Aditya P
2
@AdityaGameProgrammer: Używam go kilka razy dziennie, aby zobaczyć, nad czym pracuję wczoraj lub przed przerwą :)
fresnel
Brak kontroli wersji ?! To naprawdę przerażająca perspektywa.
thepeer
+1 za poinformowanie mnie o git blame... nie miał pojęcia, że istnieje, ale to FCKING AWESOME
Radu Murzea
11

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 :-)

Steve
źródło
5

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.

Tom Squires
źródło
5

... 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ć

ZJR
źródło
5

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.

2 obrotów
źródło
2
Błędy, które wiążą się ze szczególnymi cechami czasu, takimi jak przełączanie na / wyłączanie czasu letniego, są ulubionymi (w październiku i marcu) ...
Julia Hayward
4

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ć.

użytkownik1249
źródło
4

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.

Andrew Neely
źródło
3

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.

chim
źródło
oczywiście jeśli twój projekt obejmuje wiele plików, można to rozszerzyć poprzez * kaszel losowy kaszel * usunięcie połowy plików projektu, to zdecydowanie jest skuteczne narzędzie do usuwania stresu (upewnij się jednak, że masz kopię zapasową).
Lie Ryan,
Tak, zdecydowanie upewnij się, że masz kopię zapasową!
chim
3

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.

jwernerny
źródło
Tak, w pracy używamy Jenkinsa i jest to naprawdę przydatne. Możemy monitorować wersje na różnych systemach i od razu zobaczyć, co się nie powiedzie. Mamy nawet prawdziwy sygnał nawigacyjny w garażu, który zaczyna migać, gdy kompilacja się nie powiedzie.
Nikko
3

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ę.

Mrówka
źródło
2

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ć.

kuszenie
źródło
2

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ć.

dzikie piki
źródło
2

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.

olafure
źródło
3
kontrola wersji jest łatwiejsza
thepeer
@thepeer: absolutnie się zgadzam. Są jednak rzeczy, które są odporne na kontrolę źródła (szczególnie w harmonogramie mikroprzekazywania), takie jak duże pliki binarne. Jestem po prostu szczęśliwy, że mogę uniknąć takich projektów przez większość czasu
sehe
@thepeer: Nie sądziłem, że ktoś uzna to za alternatywę dla kontroli wersji. To byłby mój pomysł na zorganizowany chaos :) W ten sposób masz kopię swoich rzeczy, jak to było wczoraj. Bez względu na to, kto i kiedy zobowiązał się do systemu kontroli wersji. Twoje ostatnie zatwierdzenie mogło być także ponad 2 dni temu. W niektórych projektach niektóre pliki są ignorowane podczas kontroli wersji.
olafure
@sehe: dzięki git, którego obecnie używam, masz swoje własne repozytorium, więc nie ma wymówki, aby nie popełniać na każdym etapie.
thepeer
@olafure: każdy przyzwoity system kontroli wersji powinien umożliwiać sprawdzenie / sklonowanie pełnego stanu systemu w dowolnym punkcie.
thepeer
2

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.

rev Matthew Scouten
źródło
1

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ą!

Robert
źródło
-2

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.

DKC
źródło