Wyobraź sobie, że tworzysz odtwarzacz wideo w JavaScript. Ten odtwarzacz wideo zapętla wideo użytkownika wielokrotnie za pomocą funkcji rekurencyjnej, dlatego przeglądarka too much recursion RangeErrorw pewnym momencie wyzwoli .

Prawdopodobnie nikt nie użyje tak często funkcji pętli. Twoja aplikacja nigdy nie zgłasza tego błędu, nawet jeśli użytkownik opuścił pętlę aplikacji na tydzień, ale nadal istnieje. Rozwiązanie problemu będzie wymagało przeprojektowania sposobu działania pętli w aplikacji, co zajmie dużo czasu. Co robisz? Dlaczego?

• Napraw błąd

• Zostaw błąd

Czy nie powinieneś naprawiać błędów, w które wpadną ludzie? Kiedy poprawianie błędów staje się przesadne, jeśli w ogóle tak jest?

EDYTOWAĆ:

Jeśli podejście rekurencyjne nie powodujące rzeczywistego błędu jest dla ciebie problemem, załóżmy, że za każdym razem, gdy gracz zapętla wideo, zmienna jest zwiększana o 1. Po 2 ⁵³ pętlach ta zmienna przepełni się i twój program nie będzie w stanie jej obsłużyć, zgłaszając wyjątek.

Musisz być pragmatyczny.

Jeśli jest mało prawdopodobne, aby błąd został wywołany w prawdziwym świecie, a koszt naprawy jest wysoki, wątpię, by wiele osób uznało to za dobre wykorzystanie zasobów do naprawy. Na tej podstawie powiedziałbym, że zostaw to, ale upewnij się, że hack zostanie udokumentowany dla ciebie lub twojego następcy za kilka miesięcy (patrz ostatni akapit).

To powiedziawszy, powinieneś użyć tego problemu jako „uczenia się”, a przy następnym zapętlaniu nie używaj niepotrzebnie pętli rekurencyjnej.

Przygotuj się także na zgłoszenie błędu. Zdziwiłbyś się, jak dobrzy użytkownicy końcowi przekraczają granice i odkrywają wady. Jeśli stanie się to problemem dla użytkowników końcowych, będziesz musiał to naprawić - wtedy będziesz zadowolony, że udokumentowałeś włamanie.

W systemie Windows 95 wystąpił podobny błąd, który spowodował awarię komputerów po 49,7 dniach . Zostało to zauważone dopiero kilka lat po wydaniu, ponieważ bardzo niewiele systemów Win95 i tak działało tak długo. Więc jest jeden punkt: błędy mogą być nieistotne dla innych, ważniejszych błędów.

Co musisz zrobić, to ocena ryzyka dla całego programu i ocena wpływu poszczególnych błędów.

• Czy to oprogramowanie znajduje się na granicy bezpieczeństwa?
• Jeśli tak, czy ten błąd może spowodować exploit?
• Czy to oprogramowanie ma kluczowe znaczenie dla zamierzonych użytkowników? (Zobacz listę rzeczy, dla których Java EULA zabrania ci korzystania z niej )
• Czy błąd może spowodować utratę danych? Strata finansowa? Utrata reputacji?
• Jak prawdopodobne jest wystąpienie tego błędu? (Uwzględniłeś to w swoim scenariuszu)

I tak dalej. Ma to wpływ na owady selekcję , proces podejmowania decyzji, które błędy naprawić. Prawie całe oprogramowanie wysyłkowe ma bardzo długie listy drobnych błędów, które nie zostały jeszcze uznane za wystarczająco ważne, aby je naprawić.

Inne odpowiedzi są już bardzo dobre i wiem, że twój przykład jest tylko przykładem, ale chcę wskazać dużą część tego procesu, który nie został jeszcze omówiony:

Musisz zidentyfikować swoje założenia, a następnie przetestować je na podstawie przypadków narożnych.

Patrząc na twój przykład, widzę kilka założeń:

• Podejście rekurencyjne ostatecznie spowoduje błąd.
• Nikt nie zobaczy tego błędu, ponieważ odtwarzanie filmów trwa zbyt długo, aby osiągnąć limit stosu.

Inni ludzie dyskutowali o pierwszym założeniu, ale spójrz na drugie: co jeśli moje wideo ma ułamek sekundy?

I pewnie, może nie jest to bardzo częsty przypadek użycia. Ale czy naprawdę jesteś pewien, że nikt nie załaduje bardzo krótkiego filmu? Zakładasz, że filmy mają minimalny czas trwania i prawdopodobnie nawet nie zdałeś sobie sprawy, że coś zakładałeś! Czy to założenie może powodować inne błędy w innych miejscach Twojej aplikacji?

Niezidentyfikowane założenia są ogromnym źródłem błędów.

Tak jak powiedziałem, wiem, że twój przykład jest tylko przykładem, ale ten proces identyfikacji twoich założeń (który jest często trudniejszy niż się wydaje), a następnie wymyślenie wyjątków od tych założeń jest ogromnym czynnikiem przy podejmowaniu decyzji, gdzie spędzić czas.

Więc jeśli pomyślisz, że „nie powinienem był tego programować, ponieważ to się nigdy nie wydarzy”, powinieneś poświęcić trochę czasu, aby naprawdę zbadać to założenie. Często będziesz myśleć o narożnych przypadkach, które mogą być bardziej powszechne niż początkowo sądziłeś.

To powiedziawszy, jest moment, w którym staje się to ćwiczeniem daremności. Prawdopodobnie nie obchodzi Cię, czy Twoja aplikacja JavaScript działa idealnie na kalkulatorze TI-89, więc poświęcenie na to jakiejkolwiek ilości czasu jest po prostu zmarnowane.

Inne odpowiedzi już to omówiły, ale zaproponowanie granicy między „to jest ważne” a „to strata czasu” nie jest nauką ścisłą i zależy od wielu czynników, które mogą być całkowicie różne od jednego osoba lub firma do innej osoby.

Ale ogromną częścią tego procesu jest najpierw identyfikacja twoich założeń, a następnie próba rozpoznania wyjątków od tych założeń.

Poleciłbym przeczytać następujący artykuł:

Niezawodność i jej zagrożenia: taksonomia

Między innymi opisuje różne rodzaje błędów, które mogą wystąpić w twoim programie. To, co opisałeś, nazywa się uśpieniem , aw tym artykule opisano to w następujący sposób:

Błąd jest aktywny, gdy powoduje błąd, w przeciwnym razie jest uśpiony. Aktywny błąd to albo a) błąd wewnętrzny, który wcześniej był uśpiony i który został aktywowany przez proces obliczeniowy lub warunki środowiskowe, lub b) błąd zewnętrzny. Aktywacja błędu to zastosowanie wejścia (wzorca aktywacji) do komponentu, który powoduje uaktywnienie nieaktywnego błędu. Większość usterek wewnętrznych przełącza się między stanem uśpienia a stanem aktywnym

Po opisaniu tego wszystko sprowadza się do stosunku kosztów do korzyści. Koszt składałby się z trzech parametrów:

• Jak często pojawiał się problem?
• Jakie byłyby konsekwencje?
• Jak bardzo ci to przeszkadza?

Pierwsze dwa są kluczowe. Jeśli jest to jakiś błąd, który ujawniłby się raz na niebieskim księżycu i / lub nikt nie dba o niego, lub miałby całkowicie dobre i praktyczne obejście, możesz bezpiecznie udokumentować go jako znany problem i przejść do bardziej wymagających i więcej ważne zadania. Jeśli jednak błąd spowoduje niepowodzenie transakcji pieniężnej lub przerwie długi proces rejestracji, co frustruje użytkownika końcowego, musisz podjąć odpowiednie działania. Trzeci parametr jest czymś odradzam. Słowami Vito Corleone:

To nie jest sprawa osobista. To jest biznes.

Jeśli jesteś profesjonalistą, odłóż emocje na bok i działaj optymalnie. Jeśli jednak twoja aplikacja jest Twoim hobby, jesteś zaangażowany emocjonalnie, a trzeci parametr jest równie ważny, jak każdy pod względem decydowania, czy naprawić błąd, czy nie.

Ten błąd pozostaje nieodkryty tylko do dnia, w którym ktoś umieści gracza na ekranie lobby, prowadząc prezentację firmową 24 godziny na dobę, 7 dni w tygodniu. Więc to wciąż błąd.

Odpowiedź na to co robisz? jest naprawdę decyzją biznesową, a nie inżynierską:

• Jeśli błąd dotyczy tylko 1% użytkowników, a Twój odtwarzacz nie obsługuje funkcji wymaganej przez kolejne 20%, wybór jest oczywisty. Udokumentuj błąd, a następnie kontynuuj.
• Jeśli poprawka znajduje się na twojej liście rzeczy do zrobienia, często lepiej ją naprawić przed rozpoczęciem dodawania nowych funkcji. Otrzymasz korzyści z procesu tworzenia oprogramowania bez wad i nie stracisz dużo czasu, ponieważ i tak jest na twojej liście.

Zwłaszcza w dużych firmach (lub dużych projektach) istnieje bardzo pragmatyczny sposób ustalenia, co robić.

Jeśli koszt naprawy jest większy niż zwrot, który przyniesie poprawka, zachowaj błąd. Viceversa, jeśli poprawka zwróci więcej niż koszt, to napraw błąd.

W przykładowym scenariuszu zależy to od liczby użytkowników, których spodziewasz się stracić, od liczby użytkowników, których zyskasz, jeśli opracujesz nowe funkcje zamiast naprawiać ten kosztowny błąd.

tl; dr Oto dlaczego RESOLVED/WONTFIX. Tylko nie nadużywaj go - dług techniczny może się narastać, jeśli nie będziesz ostrożny. Czy jest to podstawowy problem związany z twoim projektem, który może powodować inne problemy w przyszłości? Następnie to napraw. Inaczej? Pozostaw to, dopóki nie stanie się priorytetem (jeśli kiedykolwiek tak będzie).

W opisywanej sytuacji występują trzy błędy:

1. Brak procesu oceny wszystkich zarejestrowanych błędów (zarejestrowałeś błąd w swoim bilecie / zaległości / jakimkolwiek systemie, który posiadasz, prawda?), Aby ustalić, czy należy go naprawić, czy nie. To jest decyzja kierownictwa.

2. Brak umiejętności w zespole, który prowadzi do stosowania takich wadliwych rozwiązań. Należy pilnie rozwiązać ten problem, aby uniknąć przyszłych problemów. (Zacznij uczyć się na swoich błędach.)

3. Problem, że wideo może przestać być wyświetlane po bardzo długim czasie.

Tylko z trzech błędów (3) może nie być konieczne naprawienie.

Istnieje wiele odpowiedzi na temat oceny kosztu naprawienia błędu, a nie jego pozostawienia. Wszystkie zawierają dobre porady, ale chciałbym dodać, że koszt błędu jest często niedoszacowany, a być może bardzo niedoceniany. Powodem jest to, że istniejące błędy mętnieją wody w celu dalszego rozwoju i utrzymania. Sprawienie, by testerzy śledzili kilka błędów „nie naprawiających” podczas nawigacji w oprogramowaniu, próbując znaleźć nowe błędy, spowalniając ich pracę i narażając się na błędy. Kilka błędów „nie naprawiających”, które prawdopodobnie nie wpłyną na użytkowników końcowych, będą spowalniać dalszy rozwój, a wynik będzie gorszy.

Jednej rzeczy, której nauczyłem się przez lata programowania, to to, że błąd wróci. Użytkownik końcowy zawsze go odkryje i zgłosi. To, czy naprawisz błąd, czy nie, jest „tylko” priorytetem i terminem.

Mieliśmy poważne błędy (moim zdaniem poważne), które zostały postanowione przeciwko naprawianiu w jednym wydaniu, tylko po to, aby stać się ogranicznikiem programu w następnym wydaniu, ponieważ użytkownik końcowy napotkał go w kółko. To samo na odwrót - zostaliśmy zmuszeni naprawić błąd w funkcji, której nikt nie używa, ale było to przydatne dla zarządu.

Są tutaj trzy rzeczy:

Zasady

To jedna strona medalu. Do pewnego stopnia czuję, że to jest dobre, aby domagać się błędów mocujących (lub złych implementacjach, nawet jeśli „działa”), nawet jeśli nikt nie zauważając go.

Spójrz na to w ten sposób: prawdziwym problemem niekoniecznie jest błąd, w twoim przykładzie, ale fakt, że programista uznał, że dobrym pomysłem jest wdrożenie pętli w ten sposób. Od pierwszej chwili było oczywiste, że nie było to dobre rozwiązanie. Istnieją teraz dwie możliwości:

• Programista po prostu tego nie zauważył. Cóż ... programista powinien rozwinąć intuicję tego, jak działa jego kod. To nie jest tak, że rekurencja to bardzo trudna koncepcja. Naprawiając błąd (i pocąc się przez całą dodatkową pracę), może czegoś się uczy i pamięta, choćby po to, aby uniknąć dodatkowej pracy w przyszłości. Jeśli powodem było to, że on po prostu nie miał wystarczająco dużo czasu, kierownictwo może dowiedzieć się, że programiści nie potrzebują więcej czasu, aby stworzyć wyższą jakość kodu.

• Programista zauważył, ale uznał to za „nie problem”. Jeśli tak pozostanie, powstanie kultura leseferyzmu, która ostatecznie doprowadzi do błędów, w których naprawdę boli. W tym konkretnym przypadku kogo to obchodzi. Ale co, jeśli ten programista opracuje aplikację bankową następnym razem i zdecyduje, że pewna konstelacja nigdy się nie wydarzy. To robi. Złe czasy.

Pragmatyzm

To jest druga strona. Z Oczywiście ty prawdopodobnie, w tym konkretnym przypadku, nie naprawić błąd. Ale uważaj - jest pragmatyzm, a potem pragmatyzm. Dobry pragmatyzm polega na znalezieniu szybkiego, ale solidnego, dobrze uzasadnionego rozwiązania problemu. Tj. Unikasz przeprojektowywania, ale rzeczy, które faktycznie wdrażasz, są nadal dobrze przemyślane. Zły pragmatyzm ma miejsce, gdy po prostu zhakujesz coś razem, co działa „tak” i pęknie przy pierwszej okazji.

Zawodzą szybko, zawodzą mocno

W razie wątpliwości należy szybko zawieść i mocno zawieść.

Oznacza to między innymi, że Twój kod zauważa błąd, a nie środowisko.

W tym przykładzie możesz przynajmniej zrobić to tak, aby nie wystąpił twardy błąd środowiska wykonawczego („przekroczona głębokość stosu” lub coś takiego), zastępując go własnym, wyjątkowym wyjątkiem. Możesz na przykład mieć globalny licznik i dowolnie zdecydować, że ratujesz po 1000 filmów (lub jakakolwiek liczba jest wystarczająco wysoka, aby nigdy nie wystąpić podczas normalnego użytkowania i wystarczająco niska, aby nadal działać w większości przeglądarek). Następnie przekaż temu wyjątkowi (który może być wyjątkiem ogólnym, np. RuntimeExceptionW Javie lub zwykłym ciągiem w JavaScript lub Ruby) znaczącą wiadomość. Nie musisz wchodzić w zakres, aby stworzyć nowy typ wyjątków lub cokolwiek robisz w swoim konkretnym języku programowania.

W ten sposób masz

• ... udokumentował problem w kodzie.
• ... sprawiło, że był to problem deterministyczny. Ty wiesz , że wyjątek nastąpi. Nie masz ochoty na zmiany w podstawowej technologii przeglądarki (pomyśl o nie tylko przeglądarce komputera, ale także smartfonach, tabletach lub przyszłej technologii).
• ... sprawiło, że łatwo go naprawić, gdy w końcu trzeba go naprawić. Źródłem problemu jest twoja wiadomość, otrzymasz sensowną ścieżkę zwrotną i tak dalej.
• ... wciąż nie tracę czasu na „prawdziwą” obsługę błędów (pamiętaj, że nigdy nie spodziewasz się wystąpienia błędu).

Moją konwencją jest poprzedzenie takich komunikatów o błędach słowem „Paranoia:”. To dla mnie i dla wszystkich jest to wyraźny znak, że nigdy nie oczekuję, że ten błąd się popsuje. Mogę je wyraźnie oddzielić od „prawdziwych” wyjątków. Jeśli widzę taki w graficznym interfejsie użytkownika lub w pliku dziennika, jestem pewien, że mam poważny problem - w końcu nigdy się nie spodziewałem. W tym momencie przechodzę w tryb crunch (z dużą szansą na szybkie i dość łatwe rozwiązanie, ponieważ wiem dokładnie, gdzie wystąpił problem, ratując mnie od wielu fałszywych debugowania).

Napisano to na biurku starszego programisty w moim miejscu pracy

Czy to pomaga komukolwiek?

Myślę, że często jest to dobry punkt wyjścia do procesu myślowego. Zawsze jest wiele rzeczy do naprawienia i ulepszenia - ale ile naprawdę dodajesz? ... niezależnie od tego, czy jest to użyteczność, niezawodność, łatwość konserwacji, czytelność, wydajność ... czy jakikolwiek inny aspekt.

Przychodzą mi na myśl trzy rzeczy:

Po pierwsze , wpływ zidentyfikowanego błędu musi zostać dokładnie zbadany, zanim decyzja o pozostawieniu błędu w kodzie będzie mogła zostać podjęta w odpowiedzialny sposób. (W twoim przykładzie od razu pomyślałem o wycieku pamięci, który reprezentuje stale rosnący stos i który może powodować, że Twoja przeglądarka będzie spowalniać i spowalniać z każdą rekurencją.) To dokładne badanie często trwa dłużej niż usunięcie błędu, więc wolałbym naprawić błąd w większości przypadków.

Po drugie , błędy mają tendencję do wywierania większego wpływu, niż się początkowo wydaje. Wszyscy dobrze znamy działający kod, ponieważ jest to „normalny” przypadek. Błędy natomiast są „wyjątkiem”. Oczywiście wszyscy widzieliśmy wiele błędów, ale ogólnie widzieliśmy znacznie więcej działającego kodu. Mamy zatem większe doświadczenie w zachowaniu się działającego kodu niż w zachowaniu się błędnego kodu. Istnieją tysiące książek na temat działającego kodu i tego, co zrobi w jakich sytuacjach. Nie ma prawie nic na temat zachowania błędnego kodu.

Powód tego jest prosty: błędy nie są porządkiem, lecz chaosem . Często mają w sobie ślad porządku (lub odwrotnie: nie niszczą porządku całkowicie), ale ich błędny charakter to zniszczenie porządku, którego chciał programista. Sam chaos ma tendencję do przeciwstawiania się poprawnemu oszacowaniu. O wiele trudniej jest powiedzieć, co zrobi program z błędem, niż to, co zrobi poprawny program tylko dlatego, że nie pasuje już do naszych mentalnych wzorców.

Po trzecie , twój przykład zawierał aspekt, że usunięcie błędu oznaczałoby konieczność przeprojektowania programu. (Jeśli usuniesz ten aspekt, odpowiedź jest prosta: Napraw błąd, nie powinno to zająć zbyt długo, ponieważ nie jest konieczne przeprojektowywanie. W przeciwnym razie :) W takim przypadku straciłbym zaufanie do programu w sposób, w jaki jest obecnie zaprojektowany. Przeprojektowanie byłoby sposobem na przywrócenie tego zaufania.

Wszystko to mówi , że programy są rzeczami, z których ludzie korzystają, a brakująca funkcja lub drugi, naprawdę uciążliwy błąd w innym miejscu może mieć priorytet przed naprawieniem błędu. Oczywiście, weź pragmatyczny sposób i najpierw wykonaj inne czynności. Ale nigdy nie zapominaj, że pierwsze szybkie oszacowanie wpływu błędu może być całkowicie błędne.

Niskie prawdopodobieństwo / Łagodne konsekwencje = Niska priorytetowa poprawka

• Jeśli prawdopodobieństwo wystąpienia jest bardzo niskie
• Jeśli konsekwencje wystąpienia są łagodne
• Wtedy błąd nie stanowi zagrożenia, a następnie nie jest priorytetową poprawką.

Ale to nie może stać się kulą dla leniwych programistów ...

• Co w ogóle oznacza „bardzo niska częstotliwość”?
• Co w ogóle oznaczają „łagodne konsekwencje”?

Aby stwierdzić, że prawdopodobieństwo wystąpienia jest bardzo niskie, a konsekwencje łagodne, zespół programistów musi zrozumieć kod, wzorce użytkowania i bezpieczeństwo.

Większość programistów dziwi się, że rzeczy, które pierwotnie wymyślili, nigdy się nie wydarzyły, w rzeczywistości zdarzają się często

Nasz system edukacyjny nie uczy zbyt dobrze prawdopodobieństwa i logiki. Większość osób, w tym większość inżynierów oprogramowania, ma zepsutą logikę i zepsutą intuicję proaktywności. Doświadczenie z rzeczywistymi problemami i doświadczenie z rozległymi symulacjami to jedyny sposób, w jaki mogę to naprawić.

Konfrontuj swoją intuicję z danymi ze świata rzeczywistego

Ważne jest, aby utworzyć kilka dzienników, aby móc śledzić wzorce użytkowania. Wypełnij kod stwierdzeniami rzeczy, które Twoim zdaniem nie powinny się zdarzyć. Będziesz zaskoczony, że tak. W ten sposób będziesz w stanie skonfrontować swoją intuicję z twardymi danymi i je udoskonalić.

Mój przykład łagodnego problemu i miary kontroli

W witrynie e-commerce, w której pracowałem dawno temu, inny programista popełnił błąd: w pewnym niejasnym stanie system obciążył klienta o jeden cent mniej niż zarejestrowany w logach. Odkryłem błąd, ponieważ wykonałem raporty w celu zidentyfikowania różnic między dziennikami a saldami kont, aby system księgowy był bardziej odporny. Nigdy nie naprawiłem tego błędu, ponieważ różnica była bardzo mała. Różnica była obliczana codziennie i była niższa niż 2,00 USD miesięcznie. Tak się składa, że ​​opracowujemy całkowicie nowy system, który za rok powinien zastąpić obecny. Nie ma sensu przekierowywać zasobów z potencjalnie rentownego projektu, aby naprawić coś, co kosztuje 2,00 USD miesięcznie i zostało poddane odpowiedniej kontroli.

Wniosek

Tak, istnieją błędy, których nie trzeba od razu naprawiać, które nie są wystarczająco ważne, aby opóźnić rozwój nowych funkcji. Jednak system musi kontrolować występowanie tego błędu, aby upewnić się, że jest mały, ponieważ nie możemy ufać własnej intuicji.

Myślę, że od samego początku zadajesz złe pytanie.

Pytanie nie brzmi „powinienem naprawić ten błąd, czy też nie powinienem go naprawić”. Każdy programista ma ograniczony czas. Pytanie brzmi zatem: „co jest najbardziej użyteczną rzeczą, jaką mogę zrobić w ciągu godziny, czterech godzin lub tygodnia”.

Jeśli naprawienie tego błędu jest najbardziej przydatne, ponieważ poprawia oprogramowanie o największą liczbę dla większości ludzi, to napraw błąd. Jeśli możesz wprowadzić większe ulepszenia w innym miejscu, dodając funkcje, których brakuje ludziom, lub naprawiając ważniejszy błąd, wykonaj te inne czynności. I dodatkowe punkty bonusowe za wszystko, co czyni twój przyszły rozwój bardziej wydajnym.

Naprawianie błędów jest zawsze przesadą

Najpierw klasyfikujmy część błędu .

Czy to uczciwy błąd , np. Błąd jednorazowy lub zmienne zacienianie, które uniknęło testów? W tym przypadku mam nadzieję, że oprócz „naprawienia” problemu napisałeś także nowe testy jednostkowe, skorzystałeś z okazji, aby przefakturować pobliski kod, gdzie wszystkie te ostatnie są przydatne .

Jeśli jednak jest to wada projektowa, tak jak ma to miejsce w twoim przypadku, powinieneś ponownie ocenić projekt lub, w najgorszym przypadku, wyłączyć tę funkcję.

Więc nie próbuj tego naprawiać .

Oczywiście możesz zrobić coś gorszego - możesz spróbować metodologii hack-at-hack . Pętla wideo to włamanie (zła architektura i znane jest uszkodzenie). Możesz dodać limit pętli , aby po N iteracjach (które testowałeś poniżej limitu przeglądarki) pętla się kończy.

Konsekwencje są oczywiste, teraz musisz obsługiwać zarówno uszkodzony kod, jak i nowy limit pętli.

PS przeprasza za ekstremalny widok.

PPS Uwaga na temat terminologii: nie można „naprawić” błędu. Być może weterynarz mógłby, ale nie chodźmy tam ;-). Problemy są rozwiązywane lub „naprawiane”, podczas gdy błędy są usuwane lub obejrzane.