Czy naprawianie błędów ma marginalną korzyść [zamknięte]

27

Słyszałem od byłego kolegi, że nie wszystkie błędy muszą zostać naprawione, ponieważ gdy schodzisz na listę priorytetowych błędów, przypadek użycia, który powoduje, że błąd staje się bardziej niejasny lub satysfakcja klienta maleje. Ale wciąż musisz poświęcić dużo czasu na naprawienie tego błędu.

Aby przekonać naszego właściciela produktu o tej koncepcji, nie mogłem znaleźć żadnych dobrych zasobów. Jedyne, co mogłem znaleźć, to dyskusje na temat tego, czy tworzenie oprogramowania jest krańcowe, czy nie.

Czy naprawianie błędów ma naprawdę marginalne znaczenie? Czy istnieje inny termin, który wyjaśnia tę koncepcję?

Gökhan Kurt
źródło
2
Twoje pytanie jest dość niejasne. „nie wszystkie błędy muszą być naprawione” oznacza, że ​​są takie, których nie warto naprawiać. „Czy naprawianie błędów ma naprawdę niewielką zaletę” brzmi dla mnie, masz na myśli coś innego. Czy możesz wyjaśnić?
Doc Brown
2
Czy to nie do zrozumienia przez właściciela produktu? Jak myślisz, dlaczego musisz ich o tym przekonać?
Przestań krzywdzić Monikę
@ Gooyo Nie zadaję tego pytania specjalnie po to, aby ich przekonać. To była koncepcja, którą spotkałem jakiś czas temu, ale nie mogę znaleźć więcej zasobów. Często zdarza się, że programista zajmuje stanowisko kierownicze. Więc ja może potrzebuję tych informacji w przyszłości.
Gökhan Kurt,
2
@ GökhanKurt: Z „Wszystkie błędy muszą zostać naprawione” nie wynika, że ​​wszystkie są jednakowo ważne. Niektóre mogą być bardziej uciążliwe niż inne i dlatego mają wyższy priorytet.
JacquesB

Odpowiedzi:

66

Z perspektywy biznesowej naprawa błędu nie różni się niczym od żądania funkcji. Ma pewien koszt w czasie programowania i ma pewną wartość dla klientów. Jeśli błąd nie ma znaczenia krytycznego, sensowne jest nadanie priorytetu wartościowej funkcji nad poprawką błędu.

Ale z technicznego punktu widzenia błędy mogą być bardziej krytyczne, ponieważ wskazują na błąd w fundamencie, który może zostać wykorzystany / zbudowany przez inny kod, w którym to przypadku błąd jest „zaraźliwy” i zwiększa koszty przyszłej konserwacji. Tak więc nie naprawienie błędu jest długiem technicznym, który wymaga zarządzania, podczas gdy brak implementacji funkcji tak naprawdę nie wiąże się z ciągłymi kosztami. Ale poziom długu technicznego zaciągniętego przez błąd zależy w dużym stopniu od charakteru błędu.

Wszystkie te czynniki należy wziąć pod uwagę przy ustalaniu priorytetów.

Jeśli chodzi o to, czy naprawianie błędów ma marginalną korzyść: to jest dane. Ponieważ nie wszystkie błędy są równe pod względem ważności, naturalnie najpierw traktujesz najważniejsze błędy. Im więcej błędów naprawisz, tym niższa będzie wartość krańcowa naprawienia następnego. Ale to, czy kiedykolwiek osiągnie poziom, na którym naprawiono błąd, nie jest warte wysiłku, jest raczej decyzją biznesową niż techniczną.

JacquesB
źródło
Podoba mi się ta odpowiedź, ale nie posunąłbym się do stwierdzenia, że ​​nowa funkcja nie wiąże się z ciągłymi kosztami. Zwykle wymaga to, aby kod był bardziej ogólny, aby uwzględnić nową funkcjonalność, i będziesz musiał żyć z wyższym poziomem abstrakcji, niezależnie od tego, ile wartości naprawdę zapewnia ta funkcja.
Doval
25
@Doval Nie rozumiesz. To, co powiedział Jacques, to funkcja, która nie została jeszcze napisana, nie ma kosztów bieżących. Innymi słowy, brak funkcji nie utrudnia implementacji innej funkcji (chyba że ta druga zależy oczywiście od pierwszej). Z drugiej strony błąd sprawia, że ​​trudniej jest zrobić coś innego niż naprawić. Jako takie, „niepisane funkcje” i „nieusunięte błędy” różnią się tym, że pierwsze nie wpływa na bazę kodu, podczas gdy drugie ma.
Sebastian Redl,
3
Dodałbym, że błąd może mieć duży wpływ na wizerunek programu (a zatem całego produktu i firmy, która go wyprodukowała) ... Należy to wziąć pod uwagę: czy ktoś chce zostaw błąd, jeśli, jeśli zostanie znaleziony, może kosztować firmę niektórych klientów i / lub firmy?
Olivier Dulac,
2
Jako przykład zaraźliwych błędów: w jednym z moich projektów wszystko działało dobrze, z wyjątkiem tego, że pamięć została zwolniona w kawałku kodu, który nie zawsze działał. Tak się złożyło, że w całym kodzie, który do tej pory napisałem, zawsze tak było; Nie miałem przecieków pamięci ani podwójnych zwolnień, tylko niektóre dzienniki debugowania, które wydawały się nie działać. Ponieważ wszystko działało, nie naprawiłem tego. Potem dodałem trochę kodu, już nie są ustawione, i zacząłem mieć przecieki pamięci. Takie błędy są niewielkie, ale warte naprawy; niestety, są również trudne do odróżnienia od faktycznie drobnych błędów.
Pozew Fund Moniki
5
Aby rozwinąć kwestię @ OlivierDulac, błąd może sprawić, że użytkownik końcowy pomyśli „Nie mogę ufać temu oprogramowaniu jako niezawodnemu” i porzuci go, pomimo jego funkcji. Jestem pewien, że wszyscy zainstalowaliśmy jakieś oprogramowanie, które wydawało się bardzo przydatne, aby odinstalować je kilka minut później, ponieważ wydawało się to nieprawidłowe. Podczas gdy brakująca funkcja może zostać zauważona, ale użytkownik końcowy myśli: „Zamierzam nadal z niej korzystać, ponieważ podoba mi się to, co ma”. Nie sądzę, że błędy i funkcje powinny być uważane za równoważne z perspektywy biznesowej.
Jon Bentley,
12

Oto dobre odniesienie

http://www.joelonsoftware.com/articles/fog0000000043.html

Czy naprawiasz błędy przed napisaniem nowego kodu? Pierwsza wersja Microsoft Word dla Windows została uznana za projekt „marszu śmierci”. [...] ponieważ faza naprawy błędów nie była częścią formalnego harmonogramu [...]

Microsoft powszechnie przyjął coś [...] najwyższym priorytetem jest wyeliminowanie błędów przed napisaniem nowego kodu [...] Ogólnie rzecz biorąc, im dłużej czekasz na usunięcie błędu, tym kosztowniejsze (czas i pieniądze) jest naprawienie .

Możesz być pewien, że im dłużej będą występować te błędy, tym dłużej będzie trzeba je naprawić, gdy staną się priorytetem. Zamiast więc uzyskiwać teraz surowe korzyści, unikasz bardziej kosztownej straty w przyszłości.

Dobrym sposobem zarządzania tym byłoby określenie czasu przeznaczonego na obsługę problemów z zaległościami. Nie popchnęłoby to tak papce jak Microsoft, ale zapewni pewne rozwiązanie przyszłych problemów, jeśli nie będą już twoim problemem, nawet jeśli klienta tak naprawdę nie obchodzi.

Walfrat
źródło
3

Aby przekonać naszego właściciela produktu o tej koncepcji, nie mogłem znaleźć żadnych dobrych zasobów.

Zakładając, że pracujesz dla organizacji komercyjnej, na pewno będzie tam ktoś, kto jest świadomy analizy kosztów i korzyści .

Twoja organizacja ma skończoną ilość zasobów programistycznych i nieskończoną listę przydatnych rzeczy do zrobienia. Do tych korzystnych rzeczy należą zarówno dodawanie nowych funkcji, jak i usuwanie istniejących błędów - usunięcie błędu poprawia oprogramowanie, podobnie jak dodanie nowej funkcji.

Oczywiste jest więc, że należy podjąć decyzję, jak przydzielić ten skończony zasób do tej nieskończonej listy, i nie jest szczególnie zaskakujące, że w wyniku tego niektóre błędy nie zostaną naprawione teraz, w przyszłym tygodniu, w przyszłym roku lub w fakt zawsze.

Jeśli szukasz bardziej uporządkowanego podejścia tutaj, możesz wypróbować system PEF / REV, który przypisuje liczby do poglądów użytkownika i programisty błędu, jako punkt wyjścia do podjęcia decyzji, co należy naprawić - a co nie.

Zobacz te dwa posty tutaj na temat inżynierii oprogramowania:

Rozwiązywanie problemów, które przyniosą największe korzyści finansowe

Prawie każdy zgłoszony błąd jest błędem o wysokim priorytecie

AakashM
źródło
2

Nie wszystkie niezamierzone lub niepożądane aspekty zachowania oprogramowania są błędami. Ważne jest, aby upewnić się, że oprogramowanie ma użyteczny i udokumentowany zakres warunków, w których można polegać na działaniu w użyteczny sposób. Rozważmy na przykład program, który ma przyjąć dwie liczby, pomnożyć je i wyprowadzić wyniki, i który wypisuje fałszywą liczbę, jeśli wynik wynosi więcej 9,95, ale mniej niż 10,00, więcej niż 99,95, ale mniej niż 100,00 itd. Jeśli program został napisany w celu przetwarzania liczb, których iloczyn był między 3 a 7, i nigdy nie będzie wzywany do przetwarzania innych, ustawienie jego zachowania na 9,95 nie uczyni go bardziej użytecznym dla zamierzonego celu. Może to jednak sprawić, że program będzie bardziej odpowiedni do innych celów.

W takiej sytuacji istnieją dwa rozsądne sposoby działania:

  1. Napraw problem, jeśli jest to praktyczne.

  2. Podaj zakresy, w których dane wyjściowe programu będą wiarygodne, i stwierdz, że program nadaje się tylko do użytku z danymi, o których wiadomo, że generują wartości z prawidłowych zakresów.

Podejście nr 1 wyeliminowałoby błąd. Podejście nr 2 może sprawić, że postęp będzie mniej odpowiedni do niektórych celów, niż w innym przypadku, ale jeśli programy nie będą obsługiwały problematycznych wartości, może to nie stanowić problemu.

Nawet jeśli niezdolność do prawidłowego obsługiwania wartości od 99,95 do 100,0 jest wynikiem błędu programistycznego [np. Decyzja o wypisaniu dwóch cyfr po lewej stronie przecinka dziesiętnego przed zaokrągleniem do jednego miejsca po tym, co daje 00.00], należy to uznać jedynie za błąd, jeśli program w innym przypadku zostałby określony jako produkujący znaczące dane wyjściowe w takich przypadkach. [Nawiasem mówiąc, wyżej wspomniany problem wystąpił w kodzie printf Turbo C 2.00; w tym kontekście jest to oczywiście błąd, ale kod wywołujący wadliwy printf byłby błędny tylko, gdyby mógł generować dane wyjściowe w problematycznych zakresach].

supercat
źródło
0

W pewnym sensie tak, nie wszystkie błędy muszą zostać naprawione. Chodzi o analizę stosunku ryzyka do korzyści.

To, co na ogół się dzieje, to spotkanie biznesowe z potencjalnymi partnerami technicznymi i zainteresowanymi stronami w celu omówienia błędów, które oczywiście nie znajdują się w stosie „potrzeby naprawy”. Oni zdecydują, czy czas (= pieniądze) zainwestowany w naprawę błędu będzie tego wart dla firmy.

Na przykład „drobny błąd” może być niewielkim błędem w pisowni / gramatyce w sekcji Warunki witryny internetowej. Osoba, która to zgłosiła, może uważać, że zmiana jest zbyt drobna, ale firma rozpoznałaby potencjalną szkodę, jaką mogłaby wyrządzić marce, i względną łatwość naprawienia kilku znaków.

Z drugiej strony możesz mieć błąd, który wydaje się ważny, ale trudny do naprawienia i dotyczy tylko niewielkiej liczby użytkowników. Np. Niewielki link do przycisku jest uszkodzony dla użytkowników korzystających ze starszej wersji Google Chrome, a także ma wyłączoną obsługę Javascript.

Innymi powodami, dla których firma NIE naprawia błędu, może być to, że zainwestowany czas zwróciłby projekt z nieoczekiwaną ilością czasu lub że czas programisty lepiej byłoby poświęcić na pracę nad innymi poprawkami / kodowaniem. Może być również tak, że błąd jest na tyle niewielki, że można go uruchomić, a następnie naprawić w późniejszym terminie.

Mam nadzieję, że to wyjaśnia tę koncepcję nieco lepiej! Z pewnością odejdę od myślenia o tym w kategoriach ogólnych - każdy błąd jest wyjątkowy i powinien być traktowany jako taki.

Korthalion
źródło
-4

Ponieważ podczas przechodzenia na listę priorytetów błędów, przypadek użycia, który powoduje, że błąd staje się bardziej niejasny, lub satysfakcja klienta maleje.

Więc ich „argument” jest w rzeczywistości

Jeśli zignorujesz błąd wystarczająco długo, użytkownik zapomni, na czym polegał problem, lub znajdzie sposób, aby go obejść.

Błędy powinny być traktowane priorytetowo i rozwiązywane „w porządku”, podobnie jak nowe żądania funkcji (ale prawdopodobnie ponad wszystkie te ostatnie).

Phill W.
źródło
3
Nie, jego argumentem jest to, że błędy o niższym priorytecie mogą występować bardzo rzadko i mogą nie wnieść tak naprawdę dużej wartości w poprawianiu (np. Jeśli masz zegar na swojej stronie, który jest o pół minuty poza domem, lub jeśli jesteś witryną błędy o północy pierwszego stycznia dla użytkowników w Mołdawii)
Nazwa wyświetlana