Jak często uruchamiasz i testujesz swój kod podczas programowania? [Zamknięte]

16

Zwłaszcza, gdy piszę nowy kod od zera w C, piszę kod godzinami, a nawet dniami, bez uruchamiania kompilatora w celach innych niż okazjonalne sprawdzanie składni.

Staram się pisać większe fragmenty kodu ostrożnie i dokładnie testuję tylko wtedy, gdy jestem przekonany, że kod robi to, co powinien, analizując przepływ w mojej głowie. Nie zrozum mnie źle - nie napisałbym 1000 linii w ogóle bez testowania (to byłoby hazardem), ale napisałbym cały podprogram i przetestowałem go (i naprawiłem, jeśli to konieczne) po tym, jak skończę.

Z drugiej strony widziałem głównie początkujących, którzy uruchamiają i testują swój kod po każdej linii, którą wpisują w edytorze, i sądzę, że debuggery mogą zastąpić ostrożność i rozsądek. Uważam, że to dużo rozprasza, gdy nauczysz się składni języka.

Jak myślisz, jaka jest właściwa równowaga między tymi dwoma podejściami? Oczywiście pierwszy wymaga większego doświadczenia, ale czy wpływa to pozytywnie czy negatywnie na wydajność? Czy ten drugi pomaga dostrzec błędy na lepszym poziomie?

productivity testing coding Blagovest Buyukliev
źródło
3
Napisanie całego podprogramu zajmuje godziny lub dni?
1
@Thorbjorn Podprogram ma około 999 linii i jest zaciemniony: #define h for(int c=y-3; y; c++/(randomTypeIDefinedEarlier)s*(float)4*(lol)sin((helloWorld)mysub(2,1,++a,*(r+z))); goto xkcd)I to tylko jedna linia.
Mateen Ulhaq
1
kompilatory mogą czasem zająć dużo czasu kompilowanie programu, dlatego kompilacja przez cały czas nie jest dobrą praktyką. po każdej funkcji jest dobrą praktyką. kompiluję ponownie po dodaniu nowej funkcjonalności lub trudnego fragmentu kodu. Używam go tylko jako sprawdzania składni. nic nie zastąpi starannego sprawdzania kodu i unikania ukrytych błędów i przypadkowych zachowań.
Ross

Odpowiedzi:

6

NAPRAWDĘ zależy od aspektu projektu, nad którym pracujesz.

  • Kiedy robię cokolwiek z OpenGL (który działa jak automat stanowy), ciągle kompiluję i biegam, aby upewnić się, że niczego nie zepsułem. Ustawienie jednej wartości bez konieczności resetowania jej na końcu funkcji może sprawić, że aplikacja będzie renderować tylko czarny ekran.

  • W przypadku rozwoju „pod maską” na większą skalę staram się wcześniej uzyskać jak najwięcej testów. Ponieważ testy mogą łatwiej powiedzieć, co się zepsuło, mogę przejść chwilę bez konieczności oczekiwania na typowo długą kompilację.

  • Do projektowania UX używam jakiegoś wizualnego projektanta, który zawsze wygląda tak, jak będzie działać (lub blisko niego). Zasadniczo zawsze kompiluje kod projektu.

Sharoz
źródło
63

Osobiście muszę pracować w małych porcjach, ponieważ nie jestem wystarczająco inteligentny, aby godzinami kodować w mojej biologicznej pamięci podręcznej L1. Z powodu moich ograniczonych możliwości piszę małe, spójne metody i projektuję obiekty tak, aby miały bardzo luźne połączenie. Bardziej zaawansowane narzędzia i języki ułatwiają pisanie kodu dłużej bez budowania, ale wciąż mam dla mnie ograniczenia.

Wolę napisać mały kawałek, sprawdzić, czy działa zgodnie z oczekiwaniami. Następnie teoretycznie mogę zapomnieć o szczegółach tego utworu i potraktować go jako czarną skrzynkę w jak największym stopniu.

dss539
źródło
12
Głosuj za „... za mało mądrym ..” Czułem się tak od dłuższego czasu.
leed25d
4
Co z twoją pamięcią podręczną L2?
Mateen Ulhaq
Chciałem to zagłosować, ale wynik to 42 ...
Wayne Werner
Nowsze modele mają znacznie większe pamięci podręczne L1. Kiedy kupiłeś swój? Możesz zdecydować się na aktualizację sprzętu.
Peter Ajtai
Cóż, to nie wiek modelu, a fakt, że była to linia „budżetowa”. :(
dss539,
17

Lubię pisać test przed napisaniem kodu implementacyjnego. Podoba mi się to z trzech powodów:

  1. Ręczne napisanie kodu testowego pomaga mi przemyśleć, w jaki sposób należy go użyć. Pomaga mi myśleć o przypadkowych przypadkach, o których nie myślałem, kiedy projektowałem swój program.
  2. Wiem, że skończyłem pisać kod implementacyjny, gdy wszystkie moje przypadki testowe przejdą.
  3. Przyzwyczajenie się do pisania testów przed kodem ma również dodatkowy wpływ na to, że można udowodnić, że twój kod nie dodał żadnych nowych błędów (zakładając, że napisałeś dobre przypadki testowe).
David Weiser
źródło
2
„Wiem, że skończyłem pisać kod implementacyjny, gdy wszystkie moje przypadki testowe przejdą”. - Jak ustalić, czy napisałeś wszystkie niezbędne przypadki testowe?
dss539,
1
To świetne pytanie. Moim zdaniem, nigdy nie możesz być całkowicie pewien, że Twój kod działa poprawnie, chyba że masz formalny dowód na to. Widzę testy jednostkowe jako dowód, że twój kod ma tendencję do robienia tego, co masz na myśli. Jednak wraz ze wzrostem liczby dodawanych funkcji liczba przypadków testowych, które napiszesz, prawdopodobnie również wzrośnie. W razie wątpliwości poproś kogoś innego o sprawdzenie twoich przypadków testowych i poproś ich o przypadki, o których nie pomyślałeś.
David Weiser,
4
@David - jak formalnie udowodnić, że twój oficjalny dowód nie zawiera błędów? Jak formalnie udowodnić, że postrzegane przez ciebie wymagania odpowiadają wymaganiom w rzeczywistości. Możesz formalnie udowodnić, że jeden opis pasuje do drugiego, ale jest całkowicie możliwe, że oba opisy są niepoprawne w ten sam sposób - zwłaszcza jeśli oba opisy zostały napisane przez tę samą osobę. Pisanie rzeczy w notacji matematycznej nie czyni ludzi nieomylnymi. Ogromna liczba matematycznych „dowodów” okazała się (po długich okresach bardzo szczegółowego sprawdzania) błędna.
Steve314,
1
@ Steve314: AFAIK, formalnie udowadniając poprawność algorytmu, dokładnie i zwięźle określasz oczekiwaną poprawność. Podnosisz jednak dobrą kwestię, że definicja „poprawności” może w rzeczywistości być niepoprawna.
David Weiser,
1
@ dss539, który pochodzi z przypadków użycia, które program zamierza wdrożyć.
4

Czasem piszę kod godzinami, a nawet dniami, nie uruchamiając kompilatora do niczego poza okazjonalnym sprawdzaniem składni.

Godziny do dni - to wyraźny znak, że brakuje Ci możliwości podzielenia kodu na mniejsze części, które można zweryfikować i przetestować samodzielnie. Zdecydowanie powinieneś nad tym popracować.

Staram się pisać większe fragmenty kodu ostrożnie i dokładnie testuję tylko wtedy, gdy jestem przekonany, że kod robi to, co powinien, analizując przepływ w mojej głowie.

Zamiast pisać większe - a przez to skomplikowane - fragmenty kodu, które wymagają wielogodzinnej analizy w twojej głowie, powinieneś spróbować stworzyć mniejsze, nie tak duże elementy składowe. Nazywa się to budowaniem abstrakcji - i to jest sedno dobrego programowania, zdecydowanie nie jest oznaką bycia początkującym.

Doskonałe programowanie przypomina doskonałą grę Billard - dobry gracz nie gra mocnych uderzeń. Zamiast tego gra w taki sposób, że po każdym uderzeniu piłki zatrzymują się w pozycji, w której kolejny uderzenie znów jest łatwe. A programista nie jest dobry, ponieważ potrafi pisać skomplikowany kod - jest dobry, ponieważ może uniknąć pisania skomplikowanego kodu.

Doktor Brown
źródło
3

Kompiluję i testuję, jeśli spełniony jest jeden z następujących warunków:

  • Ostatnia kompilacja miała miejsce 15 minut temu
  • Ostatnia kompilacja była 25 linii temu
  • Zaimplementowano nową funkcję / podprogram
  • Poważna zmiana
  • Nowa funkcja (lub błąd ukryty jako funkcja)
  • Poprawka błędu (usunięto „funkcję”)
  • Nudzę się
Mateen Ulhaq
źródło
1

Częstotliwość uruchamiania i testowania kodu zależy od języka, z którym pracuję w danym momencie. Jeśli koduję procedurę przechowywaną, zwykle poczekam, aż wszystko będzie na miejscu.

Z drugiej strony, jeśli koduję w Lisp, wypróbuję każdą funkcję po jej wpisaniu.

Jeśli koduję w Haskell, zwykle wykonuję kompilację po każdej funkcji, aby wyłapać błędy typu i uruchomić kod po wszystkim.

Larry Coleman
źródło
1

Piszę tyle kodu, żeby test był zielony. Oznacza to, że uruchamiam test co kilka minut. To mój styl C ++. Jednak w Ruby używam autotestu, więc za każdym razem, gdy klikam save, otrzymuję informacje zwrotne z testów za pośrednictwem miłego wyskakującego okienka. Nie przestaję nawet pisać kodu, dzieje się to w tle.

Nazgob
źródło
1

Trzy razy na godzinę, czy tego potrzebuje, czy nie.

Zajmujemy się programowaniem pierwszego testu i przekazujemy tylko działający kod do VCS. Smolderbot idzie i sprawdza repozytorium co 20 minut i uruchamia zestaw testowy. Wszelkie awarie są natychmiast wysyłane do całego zespołu programistycznego w celu natychmiastowego usunięcia.

Andy Lester
źródło
1

Dla mnie nie chodzi o to, ile piszę. Mogę pisać tysiące wierszy prostego kodu bez konieczności jego testowania. Ale kiedy piszę trudniejszy kod, zwykle testuję każdą funkcję osobno po napisaniu spójnego zestawu.

Czasami jednak obserwowanie działania kodu jest ogromnym bodźcem motywacyjnym, gdy nic nie uruchamia się od jakiegoś czasu, dobrze jest zobaczyć, jak działa.

dan_waterworth
źródło
0

Dla mnie; -
Krótka oś czasu (niewiele czasu na myślenie) - pisz kod, kompiluj, testuj. debugowanie
Wystarczający czas - póki (gotowe) {napisz mały kod, skompiluj}, przetestuj, debuguj

Manoj R.
źródło
Uważam, że pierwsze trwa dłużej niż drugie: musisz więcej debugować niż w przypadku bardzo małej pętli testowania / zapisu.
Frank Shearar,
Może. Ale krótki harmonogram oznacza, że ​​tyłek się pali, a menedżer potrzebuje raportu, który mówi, że pewne zadanie zostało wykonane w 100%.
Manoj R
0

Testuję każdą koncepcję kodowania. Czasami jest to funkcja lub klasa, a czasem nic więcej niż instrukcja if. Gdy koncepcja zadziała, przejdź do następnego.

Dave
źródło
0

Próbuję pisać testy przed kodem. Testy przeprowadzam co najmniej dwa razy przed zatwierdzeniem. Następnie działa ponownie z serwerem Continuous Integration.

dietbuddha
źródło