Jeśli błąd ma ponad 5 lat, to czy jest to funkcja? [Zamknięte]

Pozwólcie, że dodam szczegóły: pracuję w instytucjonalnym miejscu z wieloma programistami, testerami, analitykami ds. Kontroli jakości, właścicielami produktów itp., A oto coś, co mnie wkurza:

Od ponad dziesięciu lat jesteśmy w stanie sprzedawać kiepskie (aczkolwiek dość funkcjonalne) oprogramowanie. Ma wiele funkcji, a produkt jest konkurencyjny, ale istnieją pewne poważne błędy, a także tysiące „cięć papieru” - małe irytacje, do których klienci muszą się przyzwyczaić.

Boli mnie patrzenie na niektóre rzeczy, ponieważ mocno wierzę, że jeśli komputery nie przyczynią się do ułatwienia naszego życia, nie powinniśmy z nich korzystać. Mam zaufanie do moich kolegów - są mądrzy, zdolni i mogą ulepszyć wszystko, gdy skupiają się na tym.

Jednak zgłaszanie błędów dotyczących niektórych starych funkcji może być trudne bez ich zamknięcia lub zapomnienia. „Tak to działało przez eony” to typowa odpowiedź. Ponadto, gdy QA dokonuje regresji, zwykle szukają czegoś innego niż wszystko, co wydaje się niewłaściwe. Tak więc naprawę starego problemu można zapisać jako błąd, ponieważ „było tak już przed moim czasem”.

Młody programista we mnie myśli: przepisz to dziwactwo! Jako ktoś, kto miał okazję być blisko sprzedaży, klienci, chcę wątpić w to podejście.

Interesuje mnie również twoja opinia / doświadczenie. Spróbuj wziąć pod uwagę ryzyko, koszty i inne czynniki nietechniczne.

Czuję twój ból.

Ale naprawienie czegoś tylko dlatego, że jest to błąd, nie jest wystarczającym powodem.

Musisz upewnić się, że poprawka nie zepsuje żadnego innego kodu (nie tylko twojego, ale także kodu klienta, który używa twojego kodu). Jeśli rozwiążesz problem, a to zepsuje system każdego klienta, będziesz mieć bardzo niezadowolonych klientów.

Istnieje wiele znanych przykładów, w których napisano nowy kod, aby zastąpić stary system. Tam, gdzie musieli wyraźnie dodać funkcjonalność błędu w starym systemie, ponieważ użytkownicy polegali na tym błędzie (Nie zamierzam nazywać nazw, ale jestem pewien, że możesz go google).

Testy regresji są w zasadzie testem tego, czego oczekują Twoi klienci. Przed usunięciem testu regresji upewnij się, że nie zaszkodzi komuś (jest to prawie niemożliwe). Jeśli możesz naprawić błąd ORAZ to nie przerywa testów regresji, to jest to prawdziwa poprawka.

kilka rzeczy do rozważenia przy podejmowaniu decyzji o naprawieniu błędu ... w żadnym wypadku nie obejmuje wszystkich.

• Czy to jest krytyczne (system ulega awarii)? ... najwyraźniej zostały naprawione
• Czy klienci często na to narzekają? Może to być błąd, ponieważ coś jest zepsute w kodzie lub może to być błąd związany z wymaganiami, na przykład funkcja nie jest przyjazna dla użytkownika lub oczekują, że będzie działać inaczej.
• Z biznesowego punktu widzenia bardziej korzystne jest naprawienie błędu lub wdrożenie nowej funkcji?
• Czy błąd wymaga znacznych zmian architektonicznych, czy też jest częścią systemu, na którym inne podsystemy w dużej mierze polegają? Może to drastycznie wpłynąć na czas testowania i skomplikować niezbędny zasięg testu wymagany do zweryfikowania błędu? Jeśli jest naprawdę stary, czasem trudno jest dokładnie zrozumieć, na co jeszcze wpłynie system, modyfikując błędną sekcję kodu.
• Tracisz potencjalnych klientów z powodu wadliwego systemu

Określ błąd. „Specyfikacja wymieniona posortowana według daty, ale posortowana według kwoty transakcji” niekoniecznie jest błędem w kodzie. Może to być nieudokumentowana zmiana - gdzieś gdzieś ktoś poprosił o zmianę kolejności sortowania, ale specyfikacja, wymagania, instrukcja (nawet przyciski i etykiety w interfejsie użytkownika) nie zostały zmienione w celu dopasowania i nikt nie ma nic przeciwko. Twoje pojawienie się i zmiana z powrotem na „według daty” spowoduje chaos, a aktualizowanie interfejsu użytkownika, specyfikacji, instrukcji itp. Zasadniczo marnuje czas, z możliwym wyjątkiem trochę „teorii zepsutych okien” . ”

Niektóre rzeczy są oczywiście błędami. Jeśli klikniesz ten przycisk, wybuchnie. Lub jeśli klikniesz ten przycisk w poniedziałki, wybuchnie. O ile ktoś nie zlecił ci zainwestowania czasu w zrozumienie przyczyny, możesz poświęcić wiele wysiłku na zbadanie sprawy. A kiedy dowiesz się, dlaczego, być może nie możesz tego zmienić, ponieważ zrujnowałoby to coś, co jest ważniejsze dla użytkowników lub zarządzania.

Jeśli widzisz „niechlujstwo” - wycieki pamięci, kod, który wyraźnie wymaga pewnych konwencji optymalizujących, wcięć i nazewnictwa, które nie pasują do twojego - to super kuszące, aby naprawić je pewnego dnia, gdy nie masz nic innego do roboty, lub w swoim własnym czasie . Jednak te „poprawki” psują historię kontroli źródła dla niewielkiej lub żadnej korzyści, ryzykują katastrofy takie jak „nigdy nie kompilujemy tego modułu, ponieważ plik binarny, którego używamy w produkcji, został zbudowany z utraconego kodu, a ty go po prostu nadpisałeś ”i może poważnie zdenerwować ludzi, których„ błędów ”naprawiasz.

Polecam jeden na jednego z twoim szefem. Wyjaśnij, co Ci przeszkadza - czy to styl kodowania, rzeczy, które na pewno muszą irytować użytkowników, niedokładne liczby, niespójności lub katastrofa, która czeka na Ciebie? Następnie zapytaj o kierunek i (to jest klucz) weź go.

Jeśli chcesz naprawić stary błąd, musisz uważać, aby nie złamać żadnej istniejącej funkcjonalności. Jeśli istnieją testy jednostkowe, jest to łatwiejsze, ale biorąc pod uwagę dorozumiany wiek firmy i oprogramowania, nie istnieją. Poleciłbym przejrzeć książkę Martina Fowlera „Refaktoryzacja”, ponieważ opisuje ona, jak prawidłowo refaktoryzować i naprawiać błędy, próbując jednocześnie zminimalizować skutki uboczne. Polecam również upewnienie się, że firma ma się dobrze, ponieważ regularnie przeglądasz stare błędy. Mogą pozwolić ci to zrobić tylko wtedy, gdy zrobisz to w godzinach nadliczbowych.

Ponadto, jeśli błąd stał się cechą, tzn. Jest faktycznie używany przez klientów, ponieważ zapewnia coś, upewnij się, że zapewnia odpowiedni zamiennik, kiedy chcą tego zachowania (lub po prostu udokumentuj to jako funkcję zamiast błędu).