Kiedy poprawianie błędów staje się przesadne, jeśli w ogóle?

128

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

Tiago Marinho
źródło
95
Nie zadzieraj z moim przykładem kolega ze scenariusza przypadku
Tiago Marinho
15
@PlasmaHH Używam tego hipotetycznego scenariusza, aby wyjaśnić moje pytanie. Jeśli błąd istnieje, czy nie, nie ma to żadnego znaczenia
Tiago Marinho
13
@TiagoMarinho: staram się wskazać na to, że czasem właściwym rozwiązaniem jest zdefiniowanie takiego scenariusza jako zamierzonego zachowania.
PlasmaHH
23
Dlaczego, u licha, miałbyś w ogóle uruchomić taką pętlę, używając rekurencji? Być może nie chcesz naprawić błędu, ale na pewno powinieneś ponownie rozważyć proces projektowania :-)
jamesqf
28
To wydaje się bardziej pytaniem biznesowym. Musisz ustalić priorytety na podstawie kosztu naprawy oraz wpływu / częstotliwości błędu.
Casey Kuball

Odpowiedzi:

164

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.

Mcottle
źródło
119
Całkowicie zgadzam się z „Zdziwiłbyś się, jak dobrzy użytkownicy końcowi przekraczają granice i odkrywają wady”.
Zauważył
74
Użytkownicy końcowi nie są w żaden sposób ograniczani przez to , co uważasz za rozsądne wykorzystanie twojego oprogramowania. Będą użytkownicy, którzy będą chcieli zapętlić wideo na zawsze. Jest to funkcja zapewniana przez oprogramowanie, więc będą z niej korzystać.
gnasher729
36
@ gnasher729 „10-godzinne filmy XXXX” na Youtube to dobry identyfikator, który w rzeczywistości niektórzy ludzie chcą zapętlić coś na zawsze.
Chris Cirefice
23
Kolejny problem: jeśli twoje oprogramowanie jest popularne, wtedy ktoś napotyka błąd, który rzeczywiście zdarza się tylko w rzadkiej sytuacji, publikuje go w Internecie, i nagle wszyscy i jego pies mówią: „to oprogramowanie jest śmieciami, awarie występują, jeśli zapętlę wideo dla dzień". Lub konkurent używa go, aby pokazać, jak łatwo można zawiesić aplikację.
gnasher729,
4
Nacisk na ostatni akapit. Czy wiesz, że MacOS Classic ulegnie awarii, jeśli otrzyma 32 768 kolejnych zdarzeń „naciśnięcia myszy” bez pośredniego zdarzenia „zwolnienia myszy”?
Mark
79

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

pjc50
źródło
2
Pamiętam również błąd (sprzętowy) w niektórych procesorach Intela, w których pewna wartość zmiennoprzecinkowa poszła nie tak.
5
@WilliamKappler en.wikipedia.org/wiki/Pentium_FDIV_bug jest, jak sądzę, o czym mówisz. Był przez rok, zanim ktokolwiek to zauważył.
Jeutnarg,
10
@ gnasher729 - Nie bardzo, byli już na dole i wciąż kopali :) Większość ludzi musiała ponownie instalować Win 95 częściej niż 49,7 dni IIRC.
mcottle,
4
@Luaan Komentarz miał być lekkomyślnym wykopaliskiem w M $, stąd buźka po pierwszym zdaniu. Byli za ósemką w '95, ponieważ wyszło bardzo późno w 95 (prawdopodobnie dlatego, że wydanie Win95 w 1996 roku byłoby złym wyglądem), na wpół upieczone (pamiętasz USB BSOD?) I skłonni byli stać się niestabilni i wymagać regularnej instalacji stąd moje drugie zdanie - które nigdy nie wspominało o uruchomieniu serwera w systemie Windows 95, nie wiem skąd je masz (retrospekcje?). Druga płyta CD poprawiła sytuację, ale pierwsze wydanie z 95 roku było doozy.
mcottle,
5
TBH Myślę, że to fiasko „Windows for Warships” spowodowało więcej szkód w reputacji ( archive.wired.com/science/discoveries/news/1998/07/13987 ) i korzystało z NT. Maszyny z systemem Unix w tamtym czasie mogły zarządzać wieloletnimi czasami pracy, nawet używając (bardzo wczesnych) wersji Linuksa. Wszystkie komputery domowe były również w stanie pracować bez przestojów, chociaż rzadko były używane w ten sposób. Widziałem mikrosfery BBC osadzone w eksponatach edukacyjnych dekadę po ich przestarzałości.
pjc50
33

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

Kevin Workman
źródło
Bardzo dobra uwaga Kevin. Zwróć uwagę na mój komentarz do wybranej powyżej odpowiedzi, która koncentruje się na pytaniu analitycznymWhat's the worst thing that could happen?
OMY,
Innym założeniem jest to, że stale rosnący stos doprowadzi do problemów tylko wtedy, gdy osiągnie rozmiar przepełnienia. W rzeczywistości stos może być normalnym zasobem, ten błąd ciągle przecieka. Cała przeglądarka może stać się coraz wolniejsza przez małe kawałki na każdej iteracji ^ H ^ H ^ H ^ H ^ H ^ Hrecursion.
Alfe,
1. OP nigdy nie powiedział, że przyczyną problemu był rosnący stos. Może to być równie łatwo spowodowane błędem w procedurze licznika (dec -> div / 0?). 2. Jeśli problemem jest problem przepełnienia stosu, to czy to pytanie nie powinno zostać opublikowane w StackOverflow? <rimshot!> ;-D
OMY
@OMY Do kogo skierowany jest ten komentarz?
Kevin Workman,
13

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.

Vladimir Stokic
źródło
„To nie jest sprawa osobista. To biznes ”, chyba Michaela, nie Vito. (Zdziwiłbyś się, jak dobrzy użytkownicy końcowi przekraczają granice i odkrywają defekty)
384X21
Właściwie to dzięki Vito, jeśli czytasz książkę. Nawet w filmie to Tom Hagen mówi to po raz pierwszy, kłócąc się z Sonnym o to, czy powinni pójść na materace, a dopiero potem Michael pierwszy mówi słynny cytat: „To nie jest osobisty, Sonny. . ” Ale Hagen nauczył się tego od Vito.
Vladimir Stokic
11

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.
Dmitrij Grigoriew
źródło
5

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.

JoulinRouge
źródło
6
Zwrot z inwestycji w rozwiązanie problemu rzadko jest łatwy do oszacowania - zazwyczaj musisz polegać na swojej ocenie.
Ant P
Zwrot, który przyniesie ta poprawka, to głównie reputacja, która jest prawie niemożliwa do oszacowania. Jeśli jestem jedynym, który nawet wie, że może wystąpić błąd, a następnie za rok lub dwa zmieniam pracę, a nowa firma zastanawia się nad osadzeniem odtwarzacza wideo w swoim produkcie (być może sprzedając miliony urządzeń), czy zalecałbym użycie ten?
Jerry Jeremiah
@JerryJeremiah, jeśli błąd uniemożliwia uruchomienie procesu biznesowego, nie chodzi o reputację, zależy to od jego znaczenia. I w każdym przypadku i każdej polityce, którą stosujesz do poprawiania błędów, czy nie, musisz dokonać subiektywnej oceny na podstawie swojego doświadczenia i wiedzy. Nawet jeśli znasz dokładną liczbę użytkowników, którzy napotkają błąd, nadal musisz dokonać ludzkiego wyboru (również polityka ROI może obejmować statystyki błędów błędów w celu zwiększenia kosztów). Ponieważ dzisiaj nie ma mechanicznego sposobu, aby poznać a priori idealną rzecz do zrobienia.
JoulinRouge
5

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

Lekkość Wyścigi na orbicie
źródło
5

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.

Zgięty
źródło
Dziękujemy za zwrócenie uwagi na problemy drugiego rzędu. Zbyt wiele osób leczy tylko ten objaw, a przyczyna nie ustaje w tworzeniu kolejnych objawów.
Jaxter
4

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.

Buhb
źródło
2

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.

Aleksandra
źródło
2

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

AnoE
źródło
2
Przepraszam, jeśli tak myślisz o tym, jak szybko zaakceptowałem odpowiedź. W mojej obronie po prostu nie wiedziałem, że pytanie będzie miało> 10 000 wyświetleń i tyle odpowiedzi w momencie akceptacji. W każdym razie nadal nie zmieniłem zdania co do najlepszej odpowiedzi.
Tiago Marinho,
@TiagoMarinho, nie ma problemu, komentarz nie był skierowany przede wszystkim do ciebie osobiście i nie spodziewałem się, że ponownie się zastanowisz. ;) Bardziej mnie zaskakują motywacje każdego, kto zagłosował za usunięciem mojej odpowiedzi ... Poza tym jest tu trochę głosów negatywnych na kilka odpowiedzi bez żadnych komentarzy. Nie jestem pewien, czy tak właśnie dzieje się w tym konkretnym obszarze SE.
AnoE,
Całkowicie zgadzam się na temat dziwnego głosowania w dół
Tiago Marinho,
Zastanawiam się, czy przynajmniej w tym przypadku leczenie jest lepsze niż leczenie. Jeśli decydujesz, czy zastosować specjalną obsługę wad projektowych, które już zidentyfikowałeś, warto porównać pełny koszt cyklu życia: a) wdrożenie obsługi błędów i potencjalne działanie na błąd, gdy wystąpi, poprzez naprawienie projekt lub b) po prostu naprawianie projektu w pierwszej kolejności.
Jaxter
@jaxter, dokładnie. Stąd moje podejście do otwierania umysłu na poprawkę błędu (nawet jeśli wydaje się to przesadą), ale kiedy zdecydujesz się nie naprawiać błędu, przynajmniej zaimplementuj funkcję szybkiego działania. Oczywiście, jeśli szybkie rozwiązanie jest droższe niż „prawdziwa” poprawka, to unikaj jej i zrób prawdziwą naprawę błędu.
AnoE
1

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.

Topo Morto
źródło
0

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.

Alfe
źródło
2
Zostaw komentarz, gdy głosujesz. Powinniśmy wiedzieć, jaka jest krytyka, aby poprawić odpowiedź.
Alfe,
0

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.

Lucas
źródło
-1

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.

gnasher729
źródło
Nie jestem pewien, czy metryka utylitarna działa tutaj najlepiej. Oczywiście, przykład odtwarzacza wideo został zaprojektowany tak, aby był niewielki, ale nawet to nie jest niezawodne. Jeden z respondentów już cytował 24-godzinną pętlę promocyjną w lobby Use Case, a innym może być kiosk na konwencie sprzedaży / technologii, który trwa tydzień. Oba będą kosztować firmę i / lub pieniądze dla firmy, więc nie są trywialne.
Jaxter
Oznaczałoby to, że usunięcie błędu zapewnia więcej korzyści, niż pierwotnie oczekiwano, więc powinno ono zająć wyższe priorytety. W ten sposób odniesiesz większy sukces w życiu, jeśli twoja opinia na temat tego, co jest najbardziej przydatne, będzie w jak największym stopniu zgodna z rzeczywistością.
gnasher729
-2

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.

Dima Tisnek
źródło
Czy naprawdę chciałeś powiedzieć, że to zawsze „przesada”? Myślę, że gdzieś pomieszałeś definicje. Przesada oznacza „pracę ponad to, co było wymagane”, czyli innymi słowy, to więcej niż ktokolwiek powinien robić. Twierdzisz, że naprawianie błędów jest zawsze przesadzone , a jednocześnie sugerowanie ludziom, że to za mało pracy i że musimy wykonać więcej pracy nad tym, co nie ma sensu.
doppelgreener
@doppelgreener Widzę, jak to może być mylące. naprawianie błędów jest straszną praktyką i nigdy nie powinno być wykonywane. Z drugiej strony, dostosowanie projektu lub architektury oprogramowania do zmieniających się wymagań jest dobrą praktyką, którą należy przestrzegać. To samo dotyczy poprawiania uczciwych błędów przy założeniu, że zrobiono to dobrze.
Dima Tisnek
2
Nie wiem o jakim typie naprawy błędów mówisz, ale w moim codziennym świecie „zmiana architektury” jest metodą naprawy błędów. Możesz określić, co gromadzisz, pod pojęciem „naprawy błędów”.
doppelgreener
@doppelgreener - Termin „poprawka” ma szczególne znaczenie w niektórych formach zarządzania jakością, a wielu menedżerów programowych przyjęło wyspecjalizowane użycie. „ Poprawka ” jest tylko tymczasowym rozwiązaniem lub obejściem, podczas gdy prawdziwerozwiązanie ” problemu wymaga zidentyfikowania i wyeliminowania „ podstawowej przyczyny ”. W oprogramowaniu błąd może być tak prosty, jak źle umieszczony przecinek, w którym poprawka (poprawienie przecinka) JEST rozwiązaniem, ale jeśli błąd jest spowodowany przez coś większego, to poprawka (np. Ograniczniki pętli) nie będzie taka sama jak rozwiązanie (przeprojektowanie / przepisanie).
OMY,
2
@OMY Dziękujemy za wyjaśnienie. Czuję, że ponieważ taka definicja „naprawić” nie jest używany przez pytanie, odpowiedź powinna reagować na tego słowa znaczeniu, który jest używany.
doppelgreener