Napraw błędy lub poczekaj, aż klient je znajdzie?

Czy inni naprawiają błędy, gdy je widzą, czy czekają, aż nastąpi awaria / utrata danych / ludzie umrą, zanim to naprawią?

Przykład 1

 Customer customer = null;
 ...
 customer.Save();

Kod jest wyraźnie niepoprawny i nie można go obejść - wywołuje metodę w odwołaniu zerowym. Zdarza się, że nie ulega awarii, ponieważ Savenie ma dostępu do danych instancji; więc to tak jak wywoływanie funkcji statycznej. Ale każda niewielka zmiana w dowolnym miejscu może nagle spowodować uszkodzenie kodu, który nie ulega awarii: aby rozpocząć awarię.

Ale nie jest również wykluczone, że poprawianie kodu:

Customer customer = null;
...
customer = new Customer();
try
   ...
   customer.Save();
   ...
finally
   customer.Free();
end;

może wprowadzić awarię; jeden nie wykryty przez testy jednostkowe z pełnym pokryciem i ręczne testy użytkownika.

Przykład 2

float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);

Ludzie znający fizykę będzie wiedział, że to ma być R ² w mianowniku.

Kod jest niepoprawny, jest absolutnie niepoprawny. Przeszacowanie prędkości spowoduje, że rakiety retro wystrzelą zbyt wcześnie, zabijając wszystkich pasażerów statku kosmicznego.

Być może jednak przeszacowanie prędkości może maskować inny problem: poduszki powietrzne nie mogą się wysunąć, gdy prom porusza się zbyt szybko. Jeśli nagle naprawimy kod:

float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);

Teraz prędkość jest dokładna i nagle poduszki powietrzne otwierają się, kiedy nie powinny.

Przykład 3

Oto przykład, który miałem ostatnio, sprawdzanie, czy ciąg znaków zawiera nieprawidłowe znaki:

if (StrPos(Address, "PO BOX") >= 0)
{
   //Do something
}

Co jeśli okaże się, że w Do somethingoddziale jest błąd ? Naprawianie oczywiście nieprawidłowego kodu:

if (StrPos("PO BOX", Address) >= 0)
{
   //Do something
}

Naprawia kod, ale wprowadza błąd.

Moim zdaniem są dwie możliwości:

• napraw kod i obwiniaj go za złamanie
• poczekaj, aż kod się zawiesi, i obwiniaj się za błąd

Czego ty politycznie zrobić?

Przykład 4 - dzisiejszy błąd w świecie rzeczywistym

Konstruuję obiekt, ale wywołuję niewłaściwy konstruktor:

Customer customer = new Customer();

Okazuje się, że konstruktor „bez parametrów” jest tak naprawdę sparametryzowanym konstruktorem z dalszej części łańcucha dziedziczenia:

public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)

Wywołanie go jest błędem, ponieważ pomija wszystkie kolejne konstruktory.

Mógłbym zmienić rodowód obiektu, aby nie ujawniać tak niebezpiecznego konstruktora, ale teraz muszę zmienić kod na:

Customer customer = new Customer(depends);

Ale nie mogę zagwarantować, że ta zmiana niczego nie zepsuje. Podobnie jak w powyższym przykładzie 1 , być może ktoś gdzieś, w jakiś ezoterycznych warunkach, zależy od tego, że jest skonstruowany Customerjako nieważny i pełen śmieci.

Być może Customerobiekt, teraz, gdy jest poprawnie skonstruowany, pozwoli na uruchomienie kodu, który nigdy wcześniej nie działał, a teraz mogę dostać awarię.

Nie mogę się w to założyć o życie twojej żony.

I mogę to przetestować od tutaj do wtorku, nie mogę przysiąc na życie twojej córki, że nie wprowadziłem regresji.

Czy ja:

• Napraw kod i obwiniaj go za złamanie? lub
• Zostaw błąd i poczuj się winny, gdy klient go znajdzie?

Zależy to szalenie od sytuacji, błędu, klienta i firmy. Zawsze trzeba rozważyć kompromis między poprawieniem implementacji a potencjalnym wprowadzeniem nowych błędów.

Gdybym miał dać ogólną wskazówkę co do tego, co robić, myślę, że wyglądałoby to tak:

1. Zaloguj wadę w wybranym systemie śledzenia. W razie potrzeby omów z zarządem / współpracownikami.
2. Jeśli jest to wada o potencjalnie tragicznych konsekwencjach (np. Twój przykład # 2), biegnij, krzycz, skacz w górę i w dół, aż ktoś z autorytetem zauważy i określi odpowiedni sposób działania, który zmniejszy ryzyko związane z naprawą błędu. Może to przesunąć datę premiery z powrotem, uratować życie, umyć okna itp.
3. Jeśli jest to defekt niełamliwy lub istnieje obejście tego problemu, oceń, czy ryzyko jego naprawienia przewyższa korzyści wynikające z poprawki. W niektórych sytuacjach lepiej poczekać, aż klient go podniesie, ponieważ wiesz, że nie spędzasz czasu na naprawianiu / ponownym testowaniu rzeczy, gdy nie jest to wymagane w 100%.

Pamiętaj, że dotyczy to tylko wydania. Jeśli jesteś w trybie pełnego programowania, po prostu zarejestruję defekt, aby można go było śledzić, naprawić i nazwać gotowym. Jeśli jest to coś, co zajmuje więcej niż, powiedzmy, pół godziny, aby naprawić i zweryfikować, udałbym się do kierownika / kierownika zespołu i sprawdził, czy wada powinna pasować do bieżącego cyklu wydania lub zaplanować na później.

Klienci ZAWSZE znajdą błędy . Nigdy nie ma ukrywania błędów przed klientami. Na końcu wprowadzone przez ciebie błędy zawsze do ciebie wrócą. Brak ich naprawy jest po prostu złą praktyką zawodową. Specjaliści tego nie robią.

Kiedy klienci znajdują błędy, firma wygląda źle, a nie indywidualny programista. Jest to o wiele gorsze dla firmy, więc jest twój argument za wprowadzeniem zmian. Jeśli naprawdę nie masz pewności co do wprowadzenia tej zmiany w obawie przed wprowadzeniem innych błędów, porozmawiaj ze starszym programistą, kierownikiem technicznym projektu lub kimkolwiek innym, kto jest w stanie podjąć decyzję o takiej zmianie, a następnie poradzić sobie z konsekwencjami.

Napraw błąd

Jesteśmy tutaj profesjonalistami. Jeśli znajdziesz w kodzie wadliwą ścieżkę, która spowoduje awarię lub nieprawidłowe zachowanie, musisz to naprawić. W zależności od procedur Twojego zespołu prawdopodobnie będziesz musiał zgłosić defekt, być może napisać test regresji i sprawdzić poprawkę we właściwym czasie cyklu statku. Jeśli jest to błąd o niskim priorytecie, sprawdzenie poprawki blisko początku kamienia milowego jest zawsze dobrym czasem, ponieważ jeśli spowodujesz regresję, nie wpłyniesz na cykl wydania kamienia milowego.

Nie myl tego z refaktoryzacją lub wprowadzaniem ulepszeń wydajności, które nie są związane z błędem wydajności.

Rozproszony system kontroli źródła, w którym można przechowywać osobne repozytorium „drobnych poprawek błędów”, a następnie łatwo łączyć je na początku kamienia milowego, jest tutaj bardzo pomocne.

Co powiedziałby klient?

Oto jak wyobrażam sobie, jak to się gra:

Klient: ulega awarii, gdy wykonuję x.

Programista: O tak! Pamiętam, że widziałem to jakiś czas temu. Uznałem, że to jeszcze nie była wielka sprawa, więc zostawiłem to tam.

Klient: [sięga po tępy obiekt]

Tak. Napraw błąd. Będziesz ratować klienta przed obciążającym doświadczeniem i będziesz mógł go naprawić, zanim stanie się nagły.

A jeśli uważasz, że twoja poprawka może faktycznie spowodować awarię, to tak naprawdę jeszcze jej nie znalazłeś.

Wszystkie podane przykłady wydają się mieć wspólny wątek. Wygląda na to, że chcesz naprawić błąd, którego nie w pełni rozumiesz. Mówię to, ponieważ zauważasz możliwość niezamierzonych konsekwencji dla każdego z nich.

Powiedziałbym, że to prawdopodobnie ogromny błąd i jak pisze Ben Laurie , nie naprawiaj błędu, którego nie rozumiesz . W tym słynnym przykładzie zespół Debiana złamał szyfrowanie OpenSSL dla Debiana i pochodnych takich jak Ubuntu, gdy podążali za wynikami narzędzia analitycznego.

Jeśli uważasz, że istnieje wada, patrząc na kod, upewnij się, że możesz odtworzyć defekt w sposób, który klient może zobaczyć. Jeśli nie możesz, dlaczego nie poświęcić zasobów na naprawę czegoś innego.

Jak najszybciej zacznij spłacać swój dług techniczny .

Wasze przykłady zdecydowanie wyglądają jak starsze kody , z dużym technicznym długiem i wyczuwam strach przed zmianami (BTW, to nie jest krytyka ani osąd). Cały twój zespół musi potwierdzić, że masz ten dług techniczny (więc nie jesteś obwiniony za niego), a następnie możesz zdecydować, jak sobie z nim poradzić.

Jeśli w przykładzie 1 Save()nie ma dostępu do danych instancji, jakie dane klienta dokładnie zapisuje? Zacznij to naprawiać i testować.

W przykładzie 2 łatwo jest objąć kalkulator prędkości testami i upewnić się, że poprawnie oblicza wynik we wszystkich kluczowych przykładach.

W przykładzie 3 istnieje niebezpieczeństwo przywrócenia martwego kodu do życia. Czy ten kod powinien zostać całkowicie wyeliminowany? Jaka jest intencja warunku logicznego pod tym warunkiem? Czy ma to zapewnić, że ciąg nie zawiera nieprawidłowych znaków? Lub upewnić się, że zawiera „PO BOX”? Im szybciej zaczniesz odpowiadać na takie pytania, tym lepiej.

Po rozwiązaniu wielu takich problemów, poproś swojego zespołu o coś w rodzaju retrospekcji / sekcji zwłok. Ważne jest, aby uczyć się na podstawie tego doświadczenia, aby w przyszłości zmniejszyć liczbę wstrzyknięć wad.

Masz już dobre odpowiedzi. Dodam tylko coś na temat obaw, że coś się zawiesi.

Po pierwsze, w idealnej sytuacji oprogramowanie ma budowę modułową, jest poprawnie skonstruowane i istnieje dobry podział problemów. W tym przypadku wprowadzone zmiany prawdopodobnie nie będą w stanie niczego zepsuć, ponieważ będziesz kontrolować cały powiązany kod i nie będzie żadnych ukrytych niespodzianek.

Niestety idealna sytuacja jest fikcyjna. Bez względu na to, w jakim stopniu sprzęgło jest luźne, nastąpi sprzężenie, a tym samym możliwość zerwania czegoś innego.

Rozwiązanie tego problemu jest dwojakie:

1. Zrób kod tak dobrze zorganizowany, jak to możliwe.
2. Gdy kod jest wystarczająco odizolowany, aby wiedzieć, że nic innego się nie zepsuje, napraw go.

Poprawienie struktury kodu nie polega na przepisaniu całego kodu na nowy projekt architektoniczny. Raczej refaktoringu kierować testów jest Twój przyjaciel tutaj. W tym kroku nie zmieniasz funkcjonalności.

Drugim krokiem jest naprawienie błędu.

Istotne jest kilka punktów:

1. Kontrola wersji jest absolutnie potrzebna do tego procesu.
2. Krok refaktoryzacji i krok naprawiania błędów są bardziej zaangażowani w kontrolę wersji jako osobne zatwierdzenia, więc każdy z nich ma dobrze zdefiniowaną funkcjonalność historyczną.
3. Nie skupiaj się na możliwości popełnienia kolejnego błędu, nic nie zrobisz. Pomyśl raczej o ulepszeniu kodu. Innymi słowy, chyba że wiesz, że zwiększasz liczbę błędów, a nie je zmniejszasz, powinieneś to zrobić.
4. Powiązane z ostatnim punktem: nie próbuj przewidywać przyszłości. Ludzie są skłonni myśleć, że są bardzo dobrzy w przewidywaniu. W rzeczywistości nasze zdolności przewidywania są krótkoterminowe. Nie martw się więc niejasnym, nieokreślonym przyszłym błędem. To także zasada YAGNI .
5. Odpowiednim narzędziem do kontroli wersji w świecie błędów jest narzędzie do śledzenia błędów . Będziesz także tego potrzebować.
6. Musisz naprawić błędy z dwóch powodów: w celu zadowolenia klienta; i aby móc robić postępy w rozwoju. Korzystając z przykładu 3 (fizyki): jeśli program spełnia wymagania klienta z takim zerwanym równaniem, istnieje wiele innych części oprogramowania, które zostały nieprawidłowo opracowane w celu złagodzenia tego błędu (na przykład uruchomienie poduszki powietrznej). Jeśli wymagana jest wersja 2 (lub 1.1) dla tego oprogramowania, trudniej będzie ci opracować poprawny kod na podstawie tego wadliwego. Kierujesz się albo na wielką przeróbkę, albo na wielką porażkę. Oba należy unikać.

To już więcej niż kilka punktów, więc chyba się tu zatrzymam.

Najpierw musisz rozważyć definicję błędu:

1. Odczytany kod nie pasuje do tego, co uważasz za słuszne
2. Oprogramowanie nie wykonuje poprawnie swoich zadań

Wygląda na to, że skupiasz się na # 1, gdzie # 2 jest najlepszym miejscem do siedzenia. Jasne, my programiści chcemy, aby nasz kod był poprawny (nr 1), ale ludzie płacą nam, aby działał (nr 2).

To, co możesz zrobić lub nie, do bazy kodu, która mogłaby przypadkowo wprowadzić nowe błędy, nie ma znaczenia dla # 2 poglądu na obecne oprogramowanie. Jednak numer 1 ma znaczenie dla Ciebie lub dla programisty konserwacji, który nastąpi poniżej. Czasami trudno jest zdecydować, ale kiedy konflikt # 2 i # 1, musisz wiedzieć, że # 2 jest wyraźnie ważniejszy.

Ani. Istnieje trzeci sposób: znaleźć sposób na udowodnienie, że „problematyczny kod” powoduje problemy z biznesowego punktu widzenia. Potwierdź to, co znajdziesz w BA / QA lub przynajmniej u swojego przełożonego. Następnie zaplanuj poprawkę, gdy wszyscy będą świadomi problemu.

Istnieje więcej możliwych scenariuszy niż poprawny błąd we wspomnianych przypadkach:

1. Kod, na który patrzysz, to martwy kod. Być może dlatego, że jak powiedział ysolik: klienci zawsze znajdują błędy. Jeśli nie, może kod nigdy nie zostanie wykonany.
2. Wystąpiła sytuacja WTF, w której oczywisty błąd miał swój cel. (Mówimy o kodzie produkcyjnym, wszystko mogło się zdarzyć, prawda?)
3. Firmy / klienci już wiedzieli o problemie, ale nie czują potrzeby jego naprawy.
4. Może więcej...

W każdym razie powyżej, jeśli jestem menedżerem, nie chcę, aby programiści stosowali jego / jej osąd i naprawiali „błąd” na miejscu. Naprawienie błędu na miejscu może pomóc w większości przypadków, ale gdy popełni błąd, może spowodować więcej problemów niż jego dobra intencja.

Czy ja:

• naprawić kod i zostać obwinionym za złamanie go? lub
• zostawić błąd i zrzucić winę, gdy klient go znajdzie?

Naprawiasz błąd, uruchamiasz testy jednostkowe , a gdy się powiedzie, sprawdzasz poprawkę.

(Lub, jeśli testy jednostkowe trwają naprawdę długo, najpierw sprawdź poprawkę, a następnie poczekaj, czy narzędzie CI wyśle ​​Ci wiadomość e-mail, ponieważ zatwierdzenie coś zepsuło.)

Napraw je, jeśli występują błędy związane z awarią / utratą danych. Wysyłanie programu ze znanym błędem utraty danych jest wręcz złośliwe i niewybaczalne.

Jeśli błąd jest kosmetyczny lub niekrytyczny (można go uniknąć), należy go udokumentować i przedstawić obejście. Najlepiej byłoby to naprawić, ale czasem jest to zbyt drogie, aby naprawić to w bieżącej wersji.

Zauważ, że każdy większy projekt oprogramowania ma sekcję „Znane problemy” w ReadMe, która zwykle zawiera dokładnie to: Znane błędy.

Znajomość błędów i NIE komunikowanie się z nimi jest możliwe tylko w przypadku naprawdę drobnych / kosmetycznych błędów.

Napraw to i przetestuj. Jeśli zdecydujesz się zachować znane błędy tylko dlatego, że boisz się znaleźć więcej błędów, twój program staje się polem minowym tykających bomb czasowych tak szybko, że stanie się niemożliwy do naprawy wcześniej, niż myślisz.

Ponieważ jesteś mistrzem, a kod jest podwładny, możesz nie bać się go zmienić, gdy zobaczysz, że jest źle. Strach przed kodem („może się odwzajemnić przez złamanie gdzie indziej”) jest po prostu niedopuszczalny.

Jeśli wyraźnie występuje awaria lub coś nie tak , powinieneś to naprawić. Jeśli w specyfikacji występuje dwuznaczność, np. Jeśli uważasz, że „dobrze, że klient może się tego spodziewać, ale wygląda na to, że to błąd” lub problem w specyfikacji, np. „Zostaliśmy poproszeni o zrobienie tego ale to jest do bani ”, musisz dowiedzieć się, co robić. Przerzucanie kodu przez ścianę i czekanie na opinie klientów jest złe - możesz zapytać menedżera produktu, jeśli go masz, lub zapytać klienta przed wdrożeniem produktu.

Pamiętaj, że „wiemy o tym problemie i naprawimy go w przyszłym wydaniu” jest równoznaczne z „wiemy o tym problemie, ale nie troszczymy się o ciebie na tyle, aby uniknąć problemu”.

Właściwym działaniem nie jest ani zignorowanie błędu, ani „naprawienie” go na miejscu; z tych samych powodów, które wskazałeś w swoim pytaniu.

Myślę, że powinieneś najpierw spróbować zrozumieć kod. Jeśli kod, który widzisz, ma już jakiś wiek, a nikt jeszcze nie zauważył „błędu”, prawdopodobnie istnieje ku temu powód. Spróbuj znaleźć ten powód. Oto, na co chciałbym spojrzeć przed podjęciem decyzji:

• Historia : użyj oprogramowania do kontroli wersji, aby odpowiedzieć na pytania: kto dotknął kodu? Co oni zmienili? I z jakimi komunikatami zatwierdzenia sprawdzili? Czy możesz wywnioskować, dlaczego kod wygląda tak?

• Zastosowanie : Jaki kod wykorzystuje wadliwy kod? I jak? Czy kod jest martwy? Czy istnieje inny kod, który opiera się na błędnym zachowaniu?

• Autor : Jeśli nie możesz szybko dojść do wniosku przy użyciu powyższych informacji, zapytaj autora kodu (przynajmniej jeśli jest to możliwe), dlaczego kod wygląda tak, jak wygląda. Zazwyczaj dostajesz „Ups, to powinno zostać naprawione!” lub „Nie! Nie zmieniaj tego! Jest to potrzebne!” od razu.