Zgodnie z zasadą Pareto programista spędza tylko 20% swojego czasu na naprawdę przydatnych rzeczach.
80% mojego czasu spędzam na debugowaniu, naprawianiu drobnych rzeczy, aby wszystko działało.
Czy istnieje sposób, aby spędzić mniej czasu na debugowaniu?
Odpowiedzi:
Kod w języku Agda lub Coq . Po skompilowaniu kod będzie działał. Jeśli jest to zbyt hardkorowe, wybierz język ze słabszym systemem typowania, np. Haskell lub F #.
Ale w większości przypadków będziesz o wiele bardziej produktywny, spędzając 20% czasu na kodowaniu i 80% na testowaniu i debugowaniu. 100% tygodnia to znacznie więcej niż 20% godziny. Jeśli potrzebujesz debugowania, to debugowanie nie jest stratą czasu i nie powinieneś przejmować się „poprawianiem” tego odsetka.
źródło
Testów jednostkowych.
Po rozpoczęciu stosowania testów jednostkowych okazało się, że napisany przeze mnie kod ma lepszą strukturę. Łatwiej było wtedy uniknąć błędów i wykryć je. Spędziłem mniej czasu na debugowaniu, ale więcej na pisaniu testu jednostkowego.
Myślę również, że czas zainwestowany w testy jednostkowe zapewnia lepszy zwrot z inwestycji niż debugowanie. Po sesji debugowania właśnie poprawiłem kod. Ten sam błąd może pojawić się kilka tygodni później i muszę ponownie debugować. Jeśli napiszę test jednostkowy, błąd jest udokumentowany jako test jednostkowy, a później działa jako test regresji. Jeśli błąd pojawi się ponownie, testy jednostkowe mi to ujawniają.
źródło
a + b
fragmentu kodu (chyba że test obejmuje cały zakres typu danych arytmetycznych).źródło
Mamy nadzieję, że testy jednostkowe pomogą, jeśli wprowadzisz błędy, które złamią przed kodem produkcyjnym - dobrze napisane testy jednostkowe również pokażą dokładnie, co się zepsuło.
To da ci większość możliwości, ale dla 99,999% projektów nadal będziesz musiał debugować różne rzeczy od czasu. Najlepszą rzeczą, jaką mogę tutaj zrobić, jest zrobienie 4 rzeczy:
źródło
Zacznij od napisania testów jednostkowych i postaraj się uzyskać jak najwyższy zasięg. Ktoś wspomniał o TDD, ale wybrałbym BDD .
Na koniec najprawdopodobniej wydasz 80% na debugowanie złożonych błędów.
źródło
Jak spędzić mniej czasu na debugowaniu? Napisz mniej kodu.
Poważnie, dopóki piszesz kod, musisz go debugować. Testy jednostkowe itp. Ogromnie pomagają, ale nie sądzę, że kiedykolwiek całkowicie zlikwidujesz ich potrzebę.
źródło
Zrozum co i dlaczego zanim zaczniesz pisać kod. Następnie konsekwentnie stosuj metodologię. Która metodologia, którą wybierzesz, nie jest tak ważna, jak konsekwentne wielokrotne stosowanie tej metodologii. Jeśli chcesz konsekwentnie dobrych wyników, musisz konsekwentnie wykonywać dobrą pracę, a posiadanie „metody szaleństwa” jest pierwszym krokiem do uzyskania tych wyników. Po zidentyfikowaniu problemów możesz dostosować swoją metodologię do potrzeb, a wraz z upływem czasu usprawnisz proces programowania i, mam nadzieję, mniej błędów i więcej nowych, znaczących zmian.
źródło
Dokładnie przeczytaj swój kod, zanim go skompilujesz. Bardzo uważna lektura pod kątem składni i funkcjonalności. Może być zaskakująco pouczający, a także dobrym wskaźnikiem, jeśli część kodu jest zbyt skomplikowana.
źródło
Większość odpowiedzi wydaje się koncentrować na tym, jak zmniejszyć liczbę problemów, które musisz debugować, a to jest cenne. Jednak debugowanie zawsze będzie konieczne, dlatego warto przyjrzeć się sposobom przyspieszenia debugowania.
Wiedzieć, jak korzystać z oprogramowania do kontroli wersji.
Popraw zrozumienie używanego języka programowania.
Bądź logiczny
źródło
Dodanie do komentarzy do testów jednostkowych, ale jest to naprawdę dobre, jeśli twój kod został rozdzielony, aby go obsługiwać (np. MVC). Jeśli nie możesz zaimplementować MVC (lub podobnego) (starszego projektu), testy jednostkowe w ogóle nie działają dla twojego interfejsu użytkownika. Następnie dodałbym automatyczne testowanie interfejsu użytkownika (Microsoft Coded UI Tests, WaitN), ponieważ zmniejszy to liczbę błędów w tej części kodu.
Poleciłbym również uruchomienie narzędzi do analizy statycznej (np. FxCop / Microsoft Code Analysis, Resharper, JustCode dla świata MS). Mogą one znaleźć wszelkiego rodzaju typowe problemy z kodowaniem, które mogą zredukować głupie zadania debugowania i skupić się bardziej na logice biznesowej debugowania.
źródło
Spraw, aby działał, a następnie spraw, aby był szybki, a następnie uczyń go ładnym. Większość błędów pochodzi z wczesnych optymalizacji lub przefaktoryzowania wierszy kodu, które były całkowicie w porządku. Jeśli wybierasz orientację obiektową, nie powtarzaj się, zachowaj prostotę i zawsze sprawdzaj rozsądność zakresów wartości, szczególnie jeśli twoje metody będą nadal działać z ograniczeniami. Nie pomoże ci popełnić mniej błędów, ale prawdopodobnie pomoże ci szybciej wykryć błędy, a zatem debugowanie zajmuje mniej czasu.
źródło
Ostatnio zastanawiałem się nad tym problemem - najprostszą odpowiedzią jest przeczytanie „Projektu rzeczy codziennych” Dona Normana; Napisz kod tak, jakbyś zaprojektował produkt.
Parafrazując, dobry projekt minimalizuje błąd. Oznacza to kilka rzeczy, z których większość już robisz (chociaż możesz nie wiedzieć dokładnie dlaczego ).
-Name działa intuicyjnie. Jest to formalnie znane jako afordancja. Oznacza to, że przycisk wymaga naciśnięcia, dźwignia umożliwia przełączenie, uchwyt do pociągnięcia itp.
- Utrudnij pisanie złego kodu. Sprawdź, czy dane wejściowe są błędne i wyrzucaj błędy wcześniej niż później, w razie potrzeby używaj aplikacji węgierskiej itp. Są to tak zwane funkcje blokady.
-Użyj abstrakcji tam, gdzie jest to właściwe. Pamięć krótkotrwała jest słaba.
-Dokumentacja jest oczywiście ważna, ale jest najmniej skuteczna w zapewnieniu prawidłowego użycia kodu. Krótko mówiąc, dobrze zaprojektowane produkty nie wymagają żadnej dokumentacji. (Najbardziej oczywistym sposobem na to jest spojrzenie na złe przykłady: mianowicie drzwi z uchwytami, które należy popchnąć).
- Testy jednostkowe. Nie zapobiegają one tak naprawdę błędom, ale pokazują, gdzie są błędy i zapewniają zdrowie psychiczne.
Jestem pewien, że brakuje mi wielu innych zasad, ale najważniejsze jest, aby przeczytać o projektowaniu pod kątem błędów.
źródło
Najlepszym sposobem na zmniejszenie debugowania, IMO, jest koncentracja i spowolnienie podczas kodowania. To zmusza cię do zobaczenia błędów, które mogłeś popełnić!
źródło
Chociaż całkowicie popieram wyżej opisane testy jednostkowe, TDD lub BDD będą miały wielką wartość, ponieważ musisz najpierw pomyśleć o problemie i rozwiązaniu.
Ale osobiście dla mnie, poświęcenie kilku minut na spokojne siedzenie i zastanowienie się nad problemem oraz jak podejść do niego, a także za i przeciw za każdym podejściem, zastanawia się nad moją jakością kodu i pomaga oczyścić umysł z bałaganu.
Czasami szybkie bazgroły na kartce papieru pozwalają zobaczyć większe połączone elementy układanki.
Piszę najgorszy kod, kiedy po raz pierwszy nurkuję w głowie i walę w klawiaturę. Trochę myśli i kontemplacji robi świat różnic.
PS. Mam na myśli 5, może dziesięć minut, a nie godziny pisania wielkiej specyfikacji.
źródło
Kilka dobrych odpowiedzi już, po prostu trochę więcej jedzenia, ale oprócz tego, co powiedzieli inni.
Ucz się na swoich błędach. Nie rób ciągle tych samych.
Pamiętaj, aby podczas programowania uwzględnić przypadki skrajne - są to miejsca, w których często występują błędy.
Zwróć uwagę na wymaganie. Nawet jeśli działa, ale nie spełnia wymagań określonych, jest to błąd.
Dzienniki wyjątków mogą być prawdziwą pomocą, gdy coś pójdzie nie tak za sześć miesięcy. Miej zwyczaj rejestrowania wyjątków.
źródło
Moje dwie najważniejsze myśli to: 1) Napisz lepszy kod, który zawiedzie, gdy zrobisz coś nieoczekiwanego 2) Stań się lepszy w debugowaniu
Mój kod jest zaśmiecony
Za każdym razem, gdy wykonuję ten fragment kodu, zgłaszany jest wyjątek, który powoduje zatrzymanie debugera, co pozwala mi kodować nowe funkcje lub unikać warunków, a następnie mylę się co do tego, co się dzieje / mam błąd
Aby lepiej debugować bałagan ze stosem wywołań, punktami przerwania (z warunkami), bezpośrednim oknem (znanym również jako okno zachęty lub repl), zmiennymi „obserwuj” i cokolwiek innego.
źródło