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

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?

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.

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.

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

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.

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ę

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.

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.

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.

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.

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

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.

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