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

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.

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.

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.

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.

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

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?

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.

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

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.