Naprawianie błędu, który do tej pory nigdy nie powodował problemu

20

Niedawno dokonałem zmiany, która spowodowała, że ​​niektóre kody były uruchamiane znacznie częściej niż kiedyś. Doprowadziło to do odkrycia błędu. Ten błąd mógł się zdarzyć przy każdym uruchomieniu kodu, ale ponieważ był uruchamiany tak rzadko, że nigdy się nie pojawiał.

Kiedy zwróciłem na to uwagę głównego dewelopera, chciał, żebym cofnął zmianę, która ujawniła błąd, zamiast naprawiać błąd, cytując powiedzenie: „Jeśli nie jest zepsuty, nie naprawiaj go”.

Jest dla mnie jasne, że do tej pory mieliśmy szczęście, ale on nie słucha rozsądku.

Czy mimo to powinienem to naprawić?

Aktualizacja

Dowód technicznie nie ma nade mną żadnej władzy. Tylko kadencja. Był jedynym deweloperem projektu od wielu lat, aż do roku temu, i myślę, że nie przyjmuje zbyt konstruktywnej krytyki. Za to, co jest warte, nie krytykowałem go. Właśnie wskazałem, że fakt, że błąd nigdy się nie pojawił, nie oznacza, że ​​go nie ma.

Kenneth Cochran
źródło
Czy to błąd związany z wątkami, czy coś innego?
TheLQ
3
Z jakiegoś powodu jest szefem. Kiedy kupa trafi w wachlarza, będzie tym, którego pieczą. Jeśli zostanie upieczony, ponieważ nie zrobiłeś tego, o co prosi, będziesz potrzebował dużej wiosła.
Martin York,
3
Czy potrafisz skonstruować przypadek, w którym błąd występuje nawet po cofnięciu zmiany? Jeśli nie, może nie jest to błąd, jest to nieudokumentowane ograniczenie ^ H ^ H ^ H ^ Hn.
Steve314,
3
Hmm, „Jeśli jest zepsuty, usuń coś innego”. - cóż, to nowatorska interpretacja, dam mu to.
Orbling
1
„Jeśli to nie jest zepsute, nie naprawiaj go”? Ale to jest zepsute.
StuperUser

Odpowiedzi:

26

Sugeruję, że jeśli masz śledzenie błędów, prześlij je. Jeśli jest to krytyczne, podnieś go i zwróć jego uwagę. Pozwól swojemu przełożonemu obniżyć go w module śledzącym. Kiedy coś pójdzie nie tak, będziesz miał ślad papieru.

Ryan Hayes
źródło
9
Pamiętaj: Zakryj swoją dupę :-)
gruszczy
1
Nie tak szczęśliwy. Wszystko jest jak spodnie. Bez śledzenia błędów, bez zbierania wymagań, bez testowania. Prawdopodobnie nie miałby nawet kontroli wersji, gdyby kierownictwo jej nie nalegało.
Kenneth Cochran
18
Na podstawie opisu środowiska pracy powinieneś pokiwać głową i uśmiechać się, gdy główny programista powiedział ci, żebyś tego nie naprawiał, a potem poszedł do przodu i zrobił to, co chciałeś zrobić.
Carson63000,
2
I nie zadawaj takich pytań następnym razem :-)
gruszczy
2
@codeelegance: „Bez śledzenia błędów, bez zbierania wymagań, bez testowania. Prawdopodobnie nie miałby nawet kontroli wersji, gdyby kierownictwo tego nie nalegało”. - Słodka Maria, Matka Boża !! 1 !! To środowisko jest silnie ironiczne w stosunku do twojej nazwy użytkownika. :)
Tabele Bobby
8

Osobiście naprawiłbym to, chyba że wymagałoby to znacznie więcej wysiłku niż było warte. „Jeśli się nie zepsuło, nie naprawiaj” jest okropne w przypadku oprogramowania.

Jeśli twoim głównym programistą jest twój szef, który mówi, nie dotykaj go, w takim przypadku nie zrobiłbym tego.

jzd
źródło
2
Jak późno są w cyklu? To może być potencjalne samobójstwo.
Job
8
„Jeśli to nie jest zepsute, nie naprawiaj” to całkowicie dobra zasada dotycząca oprogramowania - nie tylko wtedy, gdy oprogramowanie jest zepsute.
Steve314,
Jeśli nie jest uszkodzony, nie naprawiaj go, dotyczy oprogramowania w zależności od definicji uszkodzonego kodu. W chwili, gdy siadasz i wpatrujesz się w kod, który oczywiście musi zostać naprawiony, staje się on zepsuty. W chwili, gdy zaczniesz wdrażać obejścia dla uszkodzonego kodu, faktycznie pracujesz wstecz i z czasem będzie to coraz trudniejsze do naprawienia ...
Ernelli
2

Większość odpowiedzi i komentarzy sugerowała złagodzenie odpowiedzialności za decyzję, tworząc raport o błędzie i pozwalając komuś innemu zadzwonić.

Ponieważ nie mam narzędzia do śledzenia błędów (i wątpię, aby ktokolwiek inny niż ja użyłby go, gdybyśmy mieli), zrobiłem następną najlepszą rzecz. Przeszedłem nad głową głównego programisty. Po wyjaśnieniu kierownictwu zobaczyli wszystko po swojemu. Kazali mi to naprawić i zignorować prośbę potencjalnego klienta . Powiedzieli, że wygładzą potargane pióra, jeśli kiedykolwiek odkryje podstęp i narzeka.

Nie jest to idealne rozwiązanie, ale przynajmniej błąd został poprawnie naprawiony.

Kenneth Cochran
źródło
Pracowałeś w łańcuchu dowodzenia i jako taki obejmowałeś swój tyłek. Korzystanie z oprogramowania do śledzenia błędów jest czymś firma powinna rozważyć, pomaga prowadzić przynajmniej śledzić takie rzeczy i propozycje nowych funkcji, itd
Berin Loritsch
2

Przypomnij mu, że zdanie brzmi: „Jeśli się nie zepsuło, nie naprawiaj”, a nie „Jeśli klient tego nie zauważył, nie naprawiaj tego”.

Dan Diplo
źródło
1

Jakie masz uzasadnienie dla dokonanej zmiany? Jeśli nie możesz wskazać, jakich zmian doświadczyłby użytkownik lub usunięcie długu technicznego, opowiedziałbym się po stronie głównego programisty, mówiąc o wycofaniu się ze zmiany, ponieważ tylko pogarsza to sytuację.


Moim zdaniem masz tutaj kilka różnych opcji:

Jeśli po prostu naprawisz błąd, ryzykujesz dodaniem kolejnych błędów do miksu, które mogą zawrócić mi na myśl. W zależności od tego, ile masz doświadczenia i pewności, że unikniesz jakiejś paskudnej niespodzianki, która prawdopodobnie byłaby moim przewodnikiem tutaj.

Jeśli zrobisz to, co ci kazano, czy to wina będzie stanowić problem, czy też coś więcej? Zastanawiam się, co jest tutaj nie tak, oprócz rzeczy znanych jako zasady i wartości. Mam na myśli to jako żart, ale także szczery punkt tego, co jest nie tak z tym pomysłem?

JB King
źródło
Zmiana była konieczna, aby naprawić kolejny błąd. Prowadzący zasugerował, że umieściłem warunki, które ograniczają częstotliwość uruchamiania kodu, zamiast naprawiać przyczynę błędu. Zarówno naprawiony przeze mnie błąd, jak i ten, który odkryłem, są ogranicznikami pokazu.
Kenneth Cochran
3
W takim przypadku należy go odpowiednio naprawić. Użycie warunków otaczających problem jedynie odracza katastrofę ORAZ dodaje więcej nowego kodu, który może się nie udać. To złe (nawet głupie) rozwiązanie.
Szybko_niest
1

Podczas gdy moim przytłaczającym instynktem byłoby naprawienie błędów, a nie ukrycie problemu, istnieją scenariusze, w których trzymam nos i ukrywam problem.

  1. Kod jest wykorzystywany wewnętrznie i sporadycznie, więc konsekwencjami błędu można zarządzać wewnątrz firmy.
  2. Przytłaczające względy handlowe, które wymagały dziś wysyłki, a poprawka błędu może zostać wdrożona 2 tygodnie później z minimalnymi konsekwencjami.

Zawodowo nie lubię tych odpowiedzi i wyjaśniłbym wewnętrznie, że występował eter takich sytuacji.

Michael Shaw
źródło
0

Ostatecznie nie powinieneś robić niczego, czego wyraźnie nie powiedział twój przełożony. Uważam, że najlepszą rzeczą, jaką możesz zrobić na swoim stanowisku, jest utworzenie raportu o błędach w dowolnej bazie danych śledzenia błędów. w ten sposób przynajmniej wszyscy zdają sobie sprawę z problemu i osoba o większym autorytecie może zdecydować, co z tym zrobić.

Pemda
źródło
0

Skopiuj funkcję buggy, zastosuj poprawkę, zmień jej nazwę, może trochę ją ukryj i wywołaj zamiast tego.

W oparciu o komentarz dotyczący dwóch błędów showstopper, najlepszym wyborem może być przestrzeganie litery prawa, ale ignorowanie jego ducha.

Oczywiście, istnieje minus kodowania metodą „wklej i wklej”, ale wygląda na to, że to będzie najmniejszy z twoich problemów.

Steve314
źródło
1
zły pomysł, gdybym przyłapał jednego z moich programistów na robieniu czegoś takiego, zwolniłbym go na miejscu, to gwarantowany sposób na uszkodzenie kodu i dla każdego, kto musi go utrzymywać.
Miki Watts,
@Miki - w takim przypadku powiedz mi dokładnie, co nie jest złym pomysłem? Wyjaśnij, w jaki sposób ponowne włączenie błędu, ponieważ sprawiło, że kolejny błąd (który i tak tam był) był lepiej widoczny, jest dobrą rzeczą. Jeśli chodzi o strzelanie na miejscu, argumentowałbym za konstruktywnym zwolnieniem, ponieważ deweloper nie miał wyboru.
Steve314,