Podczas debugowania czasami stwierdzam, że wprowadzam pewne zmiany i nie jestem w 100% pewien, dlaczego zmiany te poprawiają niektóre błędy w programie. Czy konieczne jest zrozumienie każdego szczegółu, dlaczego występowały pewne błędy i dlaczego niektóre zmiany wyeliminowały te błędy? A może programiści często uruchamiają program, nie znając szczegółów, dlaczego poprawka zadziałała?
12
Odpowiedzi:
Powiedziałbym, że niezbędne jest zrozumienie każdego szczegółu, dlaczego występowały pewne błędy i dlaczego pewne zmiany wyeliminowały te błędy, a także często deweloperzy czasami uruchamiają program bez znajomości szczegółów, dlaczego poprawka zadziałała!
Sztuka zmieniania rzeczy do momentu zniknięcia błędu, bez zrozumienia, co go spowodowało lub dlaczego zmiana go naprawiła, jest często nazywana „programowaniem voodoo” i nie jest to komplement. Naprawdę nie ma możliwości, abyś był pewny, że naprawiłeś błąd, w przeciwieństwie do częściowego naprawienia go w konkretnym przypadku, który badałeś, jeśli nie rozumiesz, co go spowodowało.
W najgorszym przypadku nie zrobiłeś nic poza przeniesieniem błędu: pamiętam z pierwszego roku informatyki na uniwersytecie, kiedy wielu studentów uczyło się C i wskaźników po raz pierwszy, błędy wskaźnikowe często przestały się pojawiać, gdy zmieniały rzeczy losowo, ponieważ zmiany przestawiłyby struktury danych w pamięci na tyle, aby błąd wskaźnika nadepnął na inny kawałek pamięci. Oczywiście, że nie pomógł w ogóle .
Ale powiedziawszy to, komercyjne realia programowania są często takie, że zadowolenie klienta, że błąd został naprawiony, jest ważniejsze niż zadowolenie siebie. Nigdy nie polecałbym, aby zadeklarować coś naprawionego, jeśli nie masz pojęcia, co go spowodowało, ale jeśli widzisz, że jakiś kod był problematyczny, i przerobiłeś go, nawet jeśli nie jesteś w 100% pewien, jak to spowodowało błąd, który ma się objawić, czasami musisz po prostu przejść do następnego błędu, zanim klient zbyt głośno krzyczy o twoim powolnym postępie.
źródło
Jeśli uważasz, że klient jest wściekły, że naprawienie błędu trwa zbyt długo, wyobraź sobie, jak wściekły będzie z powodu powtarzającego się błędu, który, jak twierdziłeś, został naprawiony, lub z jednej przyczyny pogorszenia czegoś innego. Jeśli twoja poprawka jest jedynie obejściem lub złagodzeniem, klienci zwykle nadal ją przyjmują, ale musisz być szczery, co to jest, i musisz wprowadzić tyle dzienników, ile potrzebujesz, aby to naprawić.
Jeśli jesteś pewien, że to naprawiłeś, ale nie wiesz, dlaczego ta poprawka działa, zapytaj kogoś. Większość inżynierów, których znam, uwielbia takie pytania z powodu tajemnicy.
źródło
Zmiana rzeczy, dopóki błąd nie będzie już występować, jest na ogół złą praktyką, ale niestety rzeczywistością dla niektórych osób.
Jestem przekonany, że nigdy nie powinieneś pisać kodu, w którym nie rozumiesz, co on robi i dlaczego to robi. Jak możesz być pewien, że pomimo naprawienia błędu, który postanowiłeś naprawić - nie złamałeś nic innego?
Ogólnie rzecz biorąc, zanim naprawisz problem / błąd - powinieneś dokonać oceny / analizy przyczyny problemu, aby ustalić, dlaczego problem występuje i czy można go odtworzyć. Następnie powinieneś czytać kod i rozumieć, dlaczego kod powoduje błąd. Kiedy już to zrozumiesz: możesz zacząć patrzeć, jak rozwiązać problem i określić inne obszary, na które wpłyną twoje zmiany. Testy jednostkowe mogą tu naprawdę pomóc!
Widziałem wiele zmian w kodzie, które wprowadzili ludzie, aby naprawić problem (co jest świetne), ale niestety wprowadzono inne problemy, ponieważ programista nie był świadomy pełnego wpływu tego, co zmienili. Wiele z tych „poprawek” po prostu zaciemnia pierwotną przyczynę pierwotnego problemu, a także wprowadza złożoność i więcej błędów.
Powiedziawszy to, naprawiłem wiele problemów w kodzie wyłącznie przez skojarzenie. Tam, gdzie coś zmieniłem / przerobiłem / przebudowałem coś i naprawiłem inne zaległe błędy. Więc chociaż nie wiem, co je pierwotnie spowodowało, znalazłem podejrzany kod i „naprawiłem” go - co zdarzyło się naprawić te błędy. Takie zmiany obejmuję testami jednostkowymi i integracyjnymi, aby zapewnić integralność biznesowych i technicznych wymagań funkcji.
źródło
Istnieją co najmniej trzy duże problemy z tym:
Prowadzi to do myślenia w czarnej magii, w którym rezygnujesz z tego, że możesz zrozumieć kod, a zamiast tego po prostu zaczynasz poruszać się w nadziei, że problemy znikną. Jest to programowy odpowiednik pchania jedzenia na talerzu, mając nadzieję, że obiad będzie wyglądał na wystarczająco zjedzony, aby rodzice nie sprawili, że zjesz więcej warzyw.
Nie możesz wiedzieć, że błąd został naprawiony lub po prostu zamaskowany przez twoją zmianę, chyba że rozumiesz a) na czym polegał problem, i b) jak twoja zmiana rozwiązuje problem.
Błąd prawdopodobnie nie został naprawiony i w najbliższym czasie znów cię ugryzie.
źródło
Widzę dwa scenariusze: pracowałeś nad czymś innym, a błąd przestał się dziać, dopóki coś innego nie zepsuło niczego innego, prawie musisz pozwolić temu wejść - zrobiłeś to, co było potrzebne / chciałem i miał nieprzewidziany i niewytłumaczalny pozytywny efekt uboczny.
Drugi polega na tym, że pracujesz nad tym błędem, a losowa zmiana sprawiła, że wszystko działa, co jest niedopuszczalne. Jeśli nie masz pojęcia, co robił stary kod, prawdopodobnie nie masz pojęcia, co robi nowy kod.
Naprawdę nie mogę wymyślić dobrego powodu, aby sprawdzić drugą sprawę - jeśli jest to krytyczny błąd, ważne jest, aby go naprawić. Jeśli jest to błąd niekrytyczny, przynajmniej możesz być pewien, że nie wprowadzasz błędu krytycznego wraz z „poprawką”.
źródło
Myślę, że w dzisiejszych czasach jest to bardzo powszechne. Wynika to z Google i Stackoverflow. Masz problem ze swoim kodem, po prostu google go, znajdź rozwiązanie, naprawione, przejdź do następnego problemu.
źródło