Ile% czasu programowania spędzasz na debugowaniu?

Question

Ile% czasu programowania spędzasz na debugowaniu? Jak myślisz, jakie są dopuszczalne wartości procentowe dla niektórych mediów programistycznych?

Answer 1

Niewiele, ponieważ mam wiele testów jednostkowych. Chyba że policzysz czas spędzony na pisaniu testów i naprawianiu wadliwych testów na debugowanie czasu, którego tak naprawdę nie robię. Rzadko teraz trzeba przejść przez kod, aby zobaczyć, dlaczego test się nie udaje.

Ile czasu trzeba poświęcić na debugowanie zależy od kodu. Jeśli jest zbyt wysoka, prawdopodobnie jest to objaw innych problemów, np. brak odpowiedniej obsługi wyjątków, rejestrowania, testowania, powtarzalności itp. To, co liczy się jako "zbyt wysoki", jest subiektywne.

Jeśli musisz debugować błąd, pomyśl o wykonaniu testu awarii przed naprawieniem go, aby błąd nie powtórzył się.

Najgorsze, nad czym musiałem pracować, to duża i złożona symulacja napisana całkowicie bez testów. Czasem nie udało się to w połowie biegu, a odtworzenie awarii wymagało ustawienia punktu przerwania, rozpoczęcia biegu i oczekiwania przez pół godziny lub dłużej. Następnie dokonaj zmiany i powtórz. Nigdy nie wdawaj się w tę nędzną i niszczącą wydajność sytuację.

Answer 2

Jest tak wiele różnorodności, jeśli chodzi o pisanie oprogramowania, że ​​nie można dać solidnej odpowiedzi. Złożoność oprogramowania może wydłużyć czas debugowania, na przykład, jeśli baza kodów jest bardzo duża, a sam kod jest źle napisany, może to wydłużyć czas debugowania.

Jednym ze sposobów skrócenia czasu debugowania jest napisanie testów jednostkowych. Robiłem to przez jakiś czas i okazało się, że pomaga zmniejszyć liczbę błędów, które są wydawane klientowi.

Answer 3

Około 90% mojego czasu poświęcam na debugowanie lub refaktoryzację/przepisywanie kodu moich współpracowników, który nigdy nie działał, ale nadal był zobowiązany do GIT jako "działający".

Może to wytłumaczyć złe morale w tej (dość dużej) firmie w wyniku złego zarządzania.

Obsługa opinia o moich sugestii: Testy

• aparatury: zabronione, zbyt dużo czasu.
• Środowisko programowania: Żaden zapasowy serwer i praca z danymi na żywo nie stanowią problemu, po prostu musisz zachować ostrożność.
• Kontrola jakości: użytkownicy mogą testować samodzielnie, bez potrzeby oddzielnego testera.
• Programowanie obiektowe: zbyt skomplikowani, nowi programiści nie będą w stanie zrozumieć kodu wystarczająco szybko.
• Pisemne specyfikacje: Za dużo czasu, łatwiej jest po prostu powiedzieć programistom, aby stworzyli to, czego potrzebujemy bezpośrednio.
• Szkolenie dla programistów: Zbyt drogie i programiści nie będą mogli pracować podczas szkolenia.