Zasadniczo nie, ale i tak powinieneś dać z siebie wszystko. Wytłumaczę dlaczego (lub po prostu przeskocz do wniosku, jeśli nie masz wystarczającej cierpliwości)
Rozważ problem tak trywialny jak implementacja wyszukiwania binarnego. Jedna bardzo popularna implementacja zawierała błąd, który pozostawał niewykryty przez około dwie dekady. Jeśli dwadzieścia linii zajmie dwadzieścia lat, aby bezbłędnie było szeroko stosowane, a nawet rzekomo udowodniono, że jest poprawne, czy naprawdę możemy oczekiwać, że wielki program będzie wolny od błędów?
Ile błędów możemy się spodziewać mimo to, że będzie to ogromny program? Znalazłem jedną liczbę: „10 defektów na 1000 linii” (Kod Complete wydanie drugie, strona 517 - posłużyłem się jedynie przykładem, nie podając żadnych danych), co daje nam około 200 000 do 300 000 błędów w twoim oprogramowaniu. Na szczęście mamy sposoby na poprawę jakości programu. Testy jednostkowe, przeglądy kodu i zwykłe testy ręczne są znane z tego, że zmniejszają liczbę błędów. Mimo to liczba nadal będzie wysoka.
Gdybyśmy mogli rozwiązać 95% wszystkich błędów, byłoby to niewiarygodne. A jednak nadal mamy od 10 000 do 15 000 błędów w oprogramowaniu.
Na szczęście, ponieważ oprogramowanie jest powszechnie używane (a zatem szeroko testowane), zostaną znalezione błędy. Stopniowo będziemy otrzymywać mniej błędów. Jednak mniej błędów oznacza również, że pozostałe są trudniejsze do znalezienia - więc nie oczekuj liniowej krzywej w usuwaniu błędów. Kilka ostatnich błędów będzie naprawdę trudnych do znalezienia i może uniknąć wykrycia przez kilka lat (zakładając, że kiedykolwiek zostaną odnalezione).
Wydaje się również, że błędnie zakładasz, że jeśli oprogramowanie się nie zmieni, nie pojawią się żadne nowe błędy. Jeśli oprogramowanie zależy od bibliotek stron trzecich, nowe wersje mogą uszkodzić niektóre funkcje - wprowadzając nowe błędy, mimo że kod aplikacji jest nadal taki sam. Nowe systemy operacyjne mogą również uszkodzić aplikację, która wcześniej działała doskonale (popularny przykład znajduje się w systemie Windows Vista). Rozważ także błędy kompilatora itp.
Nie jest jasne, czy narzędzia sprawdzające kod naprawdę mogą rozwiązać problem błędnego oprogramowania. Z pewnością nie jest możliwe rozwiązanie problemu zatrzymania dla dowolnego programu, ale może być możliwe udowodnienie, że program zachowuje się tak, jak określono ... Ale co wtedy? Być może program sprawdzający ma błąd. Może sama specyfikacja zawiera błąd.
Tak wyraźnie, możemy znacznie zmniejszyć liczbę błędów, ale to naprawdę mało prawdopodobne, że kiedykolwiek dojdziemy do zera.
Ponieważ istnieje pewne pojęcie, że każda poprawka powoduje więcej błędów, ale nie sądzę, że to prawda.
(podkreślenie dodane)
Masz rację. To stwierdzenie jest błędne. Oto przykład:
int main() {
int x[10];
x[10] = 8; //Buffer overflow here
return 0;
}
Teraz naprawmy ten błąd:
int main() {
int x[11];
x[10] = 8; //No buffer overflow here
return 0;
}
Widzieć? Naprawiliśmy błąd i nie wprowadziliśmy żadnych nowych.
Jednak z pewnością poprawne jest, że za każdym razem, gdy naprawisz błąd, ryzykujesz utworzenie nowego, chociaż ryzyko to można zmniejszyć (np. Dzięki testom jednostkowym).
Powiedzmy, że na każde 100 naprawionych przeze mnie błędów przypadkowo wprowadzam nowy. Więc jeśli naprawię 10 000 błędów, wprowadzę 100 nowych błędów. A jeśli naprawię te nowe błędy, wprowadzę jeden błąd. No i co z tego? Program ma teraz 9 999 mniej błędów, więc prawdopodobnie jest lepszy niż był (zakładając, że nowy błąd nie jest 10 000 razy gorszy od poprzednich).
Naprawienie błędu może również ujawnić nowe. Ale te błędy można również naprawić. Jeśli zrobisz wszystko dobrze, w końcu oprogramowanie będzie w lepszym stanie niż się zaczęło.
Kilku najlepszych programistów byłem już stary, że lepiej nie naprawiać wielu błędów z powodu pojęcia, o którym wspomniałem w OP.
To zachowanie jest niedbałe. Jeśli wystąpi błąd i możesz go naprawić. Zrób to. Oczywiście powinieneś zrobić wszystko, aby zapobiec dodawaniu nowych, ale jeśli wprowadzę jeden mały błąd na każde 10 poważnych błędów, które naprawię, nie jest to prawidłowy powód, aby przestać naprawiać błędy. W rzeczywistości jest to dobry powód, aby nadal naprawiać błędy .
Więc mniej błędów naprawisz, mniej błędów wróci do ciebie w przyszłości
Im mniej błędów naprawisz, tym więcej błędów pozostanie w twoim oprogramowaniu, irytując użytkowników. Rzeczywiście, nie „wrócą do ciebie w przyszłości”. Nie wrócą, bo nigdy nie odeszli. Pojęcie „powrotu” jest związane z regresjami. Ponownie możliwe jest zmniejszenie ryzyka regresji.
Niektórych błędów nie można naprawić, ponieważ stały się tak szeroko stosowane, że ludzie zaczęli na nich polegać, a usunięcie błędu spowodowałoby uszkodzenie programu dla tych użytkowników. Zdarza się. Czy jednak w takim przypadku można je uznać za błędy?
Mentalność „napraw błąd, zrób błąd” może być związana z kodem That Horrible Monster - tak nieczytelnym i niemożliwym do utrzymania, że samo dotknięcie go powoduje błędy. Jeśli masz bazę kodu w potworze, być może będziesz musiał najpierw cofnąć potworowanie, zanim cokolwiek zrobisz.
Wreszcie, jeśli jesteś straszny programista, istnieje ryzyko, że coś Ci dotknąć tworzy nowe błędy. To oczywiście denerwuje starszych programistów. Jednak mówiąc: „Nic nie rób. Nie dotykaj niczego. Nawet nie oddychaj”. prawdopodobnie nie jest właściwym sposobem na stworzenie zdrowego środowiska pracy. Edukacja jest lepsza.
Wniosek:
- Oprogramowanie, które wciąż dostaje mnóstwo nowych funkcji, ale żadnych poprawek nieuchronnie będzie do niczego.
- Oprogramowanie, które otrzymuje umiarkowaną liczbę nowych funkcji, ale naprawia błędy, ma większą szansę na zastosowanie.
- Ci, którzy próbują mieć kilka błędów, mają (średnio) mniej błędów niż ci, którym to nie przeszkadza.
- Nie można oczekiwać, że program w końcu będzie wolny od błędów.
- Starsi programiści niekoniecznie są kompetentni.
- Napraw swoje błędy.
- Zastosuj metodologie, które poprawią jakość twojego oprogramowania.