Mówię na przykład o ponad 20-30 milionach linii kodu, na przykład oprogramowania w skali i złożoności programu Autodesk Maya.

Jeśli zamrozisz programowanie tak długo, jak to konieczne, czy rzeczywiście możesz naprawić wszystkie błędy, dopóki po prostu nie będzie ani jednego błędu, jeśli coś takiego można zweryfikować komputerowo? Jakie są argumenty za i przeciw istnieniu systemu wolnego od błędów?

Ponieważ istnieje pewne pojęcie, że każda poprawka powoduje więcej błędów, ale nie sądzę, że to prawda.

Przez błędy miałem na myśli od najprostszych literówek w interfejsie użytkownika, do poważniejszych błędów zapobiegawczych, które nie mają obejścia. Na przykład określona funkcja skryptowa niepoprawnie oblicza wartości normalne. Nawet jeśli istnieją obejścia, problem nadal musi zostać rozwiązany. Można więc powiedzieć, że można wykonać tę konkretną czynność ręcznie zamiast korzystać z dostarczonej funkcji, ale ta funkcja wciąż musi zostać naprawiona.

Jak wspomniał Mikey, pisanie bezbłędnego kodu nie jest celem. Jeśli o to właśnie dążysz, mam dla ciebie bardzo złe wieści.

Kluczową kwestią jest to, że nie doceniasz złożoności oprogramowania.

Po pierwsze - ignorujesz większy obraz działania programu. Nie działa w izolacji na idealnym systemie. Nawet najbardziej podstawowe programy „Hello World” działają w systemie operacyjnym, dlatego nawet najprostsze programy są podatne na błędy, które mogą występować w systemie operacyjnym.

Istnienie bibliotek czyni to bardziej złożonym. Podczas gdy systemy operacyjne wydają się być dość stabilne, biblioteki są mieszane, jeśli chodzi o stabilność. Niektóre są cudowne. Inne ... nie tak bardzo ... Jeśli chcesz, aby Twój kod był w 100% wolny od błędów, musisz także upewnić się, że każda biblioteka, z którą korzystasz, jest całkowicie wolna od błędów, a wiele razy po prostu nie jest to możliwe, ponieważ możesz nie mieć kodu źródłowego.

Następnie są wątki do przemyślenia. Większość programów na dużą skalę używa wątków w dowolnym miejscu. Staramy się być ostrożni i piszemy wątki w taki sposób, aby nie występowały warunki wyścigu i impas, ale po prostu nie jest możliwe przetestowanie każdej możliwej kombinacji kodu. Aby przetestować to skutecznie, należy sprawdzić każdą możliwą kolejność poleceń przechodzących przez procesor. Nie zrobiłem matematyki na tym, ale podejrzewam, że wyliczenie wszystkich możliwych gier w szachy byłoby łatwiejsze.

Sprawy stają się trudne do niemożliwych, gdy spojrzymy na samą maszynę. Procesory nie są idealne. Pamięć RAM nie jest idealna. Dyski twarde nie są idealne. Żaden z elementów w maszynie nie został zaprojektowany tak, aby był idealny - są one zaprojektowane jako „wystarczająco dobre”. Nawet idealny program ostatecznie zawiedzie z powodu czkawki ze strony maszyny. Nic nie możesz zrobić, aby to zatrzymać.

Konkluzja: Czy możesz napisać „Bug free software”?

NIE

Każdy, kto mówi ci inaczej, nie ma pojęcia.

Po prostu spróbuj napisać oprogramowanie, które jest łatwe do zrozumienia i utrzymania. Gdy to zrobisz, możesz nazwać to dniem.

EDYCJA: Niektóre osoby komentowały doskonały punkt, który całkowicie przeoczyłem: kompilator.

O ile nie piszesz w asemblerze, jest całkiem możliwe, że kompilator zepsuje twój kod (nawet jeśli udowodnisz, że kod jest „idealny”).

Lista błędów w GCC, jednym z najczęściej używanych kompilatorów: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=---

Matematycznie MOGĄ być możliwe napisanie „bezbłędnego” oprogramowania o takiej złożoności, w zależności od tego, jak zdefiniujesz „błąd”. Udowodnienie, że MOŻE być również matematycznie możliwe, poprzez zaprojektowanie systemu testowego, który wykonywałby każdą linię kodu w każdy możliwy sposób - każdy możliwy przypadek użycia. Ale nie jestem pewien - jeśli masz do czynienia z systemem wykonującym złożone obliczenia, możesz napotkać „problem nieskończoności” ...

Praktycznie rzecz biorąc, w systemie wielkości i zakresu, o którym mówisz, jest to NIEMOŻLIWE . Napisanie takiego „wolnego od błędów” systemu może zająć 1000 lat i napisać system, który udowodni, że zajmie to wykładniczo więcej czasu: będziesz musiał wymyślić każdy możliwy przypadek użycia i napisać system, który przetestuje każdy jeden - i nie sądzę, aby można było ustalić, czy rzeczywiście uwzględniono każdy przypadek użycia w systemie o takim rozmiarze i zakresie, o jakim mówisz, w czymkolwiek przypominającym rozsądną ilość czasu.

IMO twoje pytanie jest nieco źle skierowane: Naszym celem jako programistów nie jest pisanie „bezbłędnego” oprogramowania. Naszym celem jest pisanie oprogramowania UŻYTECZNEGO, ELASTYCZNEGO, ŁATWEGO W UTRZYMANIU .

Użyteczny: system spełnia zasadnicze wymagania, dla których został zaprojektowany. Mogą występować błędy - ale będą to „przypadki skrajne” - wartości odstające lub irytujące, a nie błędy, które zagrażają podstawom systemu - solidne.

Konserwowalne: Błędy można łatwo izolować i naprawiać, a NIE tworzyć nowych błędów.

Elastyczność: Twój system można łatwo zmieniać i rozszerzać bez znacznego przeprojektowywania i przestojów: większość zmian wymaga po prostu dodania nowej klasy lub modułu, który pasuje do już i tak dobrze zaprojektowanych wzorców i struktury.

Dobre praktyki projektowe, dobre praktyki kontroli, dobra praca zespołowa, sumienni programiści - taka jest recepta na DOBRE OPROGRAMOWANIE . (nie IDEALNY - ale DOBRY )

Zgodnie z tym artykułem, oprogramowanie pokładowe dla promu kosmicznego zbliżyło się bardzo blisko - w trzech ostatnich wersjach programu linii 420 000 każdy miał tylko jeden błąd. Oprogramowanie było utrzymywane przez grupę 260 mężczyzn i kobiet. Duża liczba tych osób była weryfikatorami, których jedynym celem było znalezienie błędów.

Aktualizacja oprogramowania umożliwiająca wahadłowiecowi nawigację za pomocą satelitów globalnego pozycjonowania wpłynęła tylko na 1,5% programu lub 6 366 linii kodu. Dane techniczne tej jednej zmiany wynosiły 2500 stron. Specyfikacje dla całego programu wypełniały 30 woluminów i zawierały 40 000 stron, czyli średnio dziesięć linii kodu na stronę specyfikacji.

Budżet nie stanowił problemu - przy 35 milionach dolarów rocznie mogli sobie pozwolić na robienie rzeczy dobrze.

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.

Powody, dla których nie pisano programów wolnych od błędów, są w większości ekonomiczne.

Nie są metody matematyczne do udowodnienia poprawności programu. Zostaną wspomniane na kursie informatyki wysokiej jakości. Istnieją specjalnie zaprojektowane języki programowania. Teoretycznie programowanie bez błędów jest możliwe.

Tak, istnieje niedoskonały sprzęt, który może czasami zmienić nieco wartość, ponieważ neutrino wystrzelone z odległej supernowej miliony lat temu właśnie trafiło w twój procesor we właściwym miejscu. Okej, każda teoria ma swoje założenia i abstrakcje. Ale zakładając, że procesor działa zgodnie z reklamą, istnieją narzędzia matematyczne, które zapewniają, że program również działa poprawnie.

Niektóre wysoko głosowane odpowiedzi w tym temacie wprowadzają w błąd. Na przykład, twierdzenie Gödela o niekompletności i problem zatrzymania sugerują tylko, że nie możesz mieć np. Zautomatyzowanego narzędzia, które decydowałoby o poprawności lub nieprawidłowości dowolnego programu. Ale nie chcemy decydować o poprawności żadnego programu, chcemy jedynie dowód poprawności jednego konkretnego programu.

(Analogicznie, tylko dlatego, że nie można napisać programu do automatycznego rozstrzygania prawdziwości dowolnego twierdzenia matematycznego, nie oznacza to, że nie można udowodnić jednego konkretnego twierdzenia matematycznego.)

Problem polega na tym, że:

Chociaż teoretycznie możliwe jest napisanie programu wolnego od błędów, zrobienie tego byłoby bardzo kosztowne . Pisanie kodu z dowodem jego poprawności jest bardziej skomplikowane niż rzucanie czymś w ścianę i sprawdzanie, czy się przylega. Nawet jeśli „sprawdzenie, czy się przyklei” odbywa się za pomocą testów jednostkowych; a wielu programistów nawet się tym nie przejmuje. Większość programistów nawet nie wiedziałaby, jak to zrobić, co oznacza, że ​​jako firma musiałabyś zatrudnić droższe.

Biorąc pod uwagę wszystkie koszty, typowy klient jest bardziej zadowolony z taniego oprogramowania, które działa dobrze przez 99% czasu (i 99,9% czasu po zainstalowaniu dodatkowych aktualizacji), niż z posiadania prawdopodobnie tysiąc razy droższego oprogramowania, które działa dobrze 100% czas. Ponadto klient chce mieć to oprogramowanie teraz , a nie za dziesięć lub dwadzieścia lat.

Dlatego ludzie świadomie produkują oprogramowanie, które ma pewną szansę na błędy, próbując znaleźć optymalną kombinację, w której błędy nie są zbyt częste i nie są zbyt poważne, a produkcja jest wystarczająco szybka i wystarczająco tania. Połączenie, które zapewnia największy zysk w prawdziwym życiu. (Czasami oznacza to nawet wydanie oprogramowania pełnego błędów, zanim konkurenci wypuszczą cokolwiek, i wydanie bardziej przyzwoitej wersji 2.0, gdy konkurenci są gotowi do wydania pierwszej przyzwoitej wersji.)

Jeśli zamrozisz programowanie tak długo, jak to konieczne, czy rzeczywiście możesz naprawić wszystkie błędy, dopóki po prostu nie będzie ani jednego błędu, jeśli coś takiego można zweryfikować komputerowo?

Z matematycznego punktu widzenia mógłbyś. Z ekonomicznego punktu widzenia, dlaczego ktoś miałby to zrobić? Oznaczałoby to wydać może dwadzieścia lat i kilka milionów dolarów. Tymczasem klienci chcieliby nowych funkcji, a zamrożone aplikacje nie mogłyby ich udostępnić. W momencie, gdy Twoja idealna wersja jest gotowa, rynek jest już zajęty przez twoich konkurentów.

Ekonomiczne uzasadnienie jest w porządku. Żyjemy w świecie, w którym liczą się pieniądze i czas. Ale tylko dlatego, że nie robimy czegoś z powodów ekonomicznych, nie powinniśmy mówić bzdur o tym, jak tego nie da się zrobić nawet w teorii. Kto wie ... może za kilka lat będziemy mieli kilka nowych języków i narzędzi programistycznych, które mogłyby spowodować poprawność dowodząc łatwe .

Nie.

David Hilbert zaproponował swój drugi problem matematyki w 1900 roku, który zasadniczo poprosił świat o udowodnienie, że arytmetyka działa zgodnie z przeznaczeniem. Później zaproponował „ Entscheidungsproblem ”, który zadał coś podobnego pod względem logicznym. „ Pierwsze twierdzenie Kurta Gödela ” udowodniło w 1931 r., Że żadna teoria elementarnej arytmetyki nie może być zarówno spójna, jak i kompletna. Przedstawienie Entscheidungsproblem Alana Turinga jako „ problemu zatrzymania ” przeniosło kwestię prosto do sedna tego pytania, gdzie udowodnił, że nie można udowodnić, czy program zostanie ukończony, czy nie. Biorąc pod uwagę tę nierozstrzygalność, nie można również udowodnić, czy program ma jakieś błędy, czy nie.

Nic z tego nie uwalnia praktykujących programistów wśród nas od dążenia do braku błędów. Oznacza to po prostu, że ogólnie nie możemy odnieść sukcesu.

Errare humanum est

Nawet jeśli piszesz kod w języku formalnym, takim jak metoda B , którego możesz użyć do matematycznego udowodnienia, że ​​wymagania są spełnione,

Nawet jeśli używasz formalnego języka specyfikacji,

Zawsze jest ludzki krok polegający na wydobyciu potrzeb użytkownika z jednego lub więcej mózgów na komputer.

Ten ludzki krok jest podatny na błędy, a robak jest w jabłku.

Spory odsetek „błędów”, które napotkałem, można lepiej opisać jako rozbieżność między projektem systemu a oczekiwaniami klientów.

Teraz, niezależnie od tego, czy nazywamy te błędy, czy nie, jest to akademickie, ale faktem jest, że znaczna część prac konserwacyjnych powstaje bezpośrednio w wyniku niedoskonałej komunikacji i zmieniających się oczekiwań klientów.

Nawet jeśli system jest technicznie, dający się udowodnić „poprawny” w sensie spełnienia specyfikacji (choć jest to nieprawdopodobne, by mogło to być w przypadku komercyjnego oprogramowania), nadal będziesz mieć problem z dopasowaniem funkcji oprogramowania do funkcji klienta - zmienne i źle zdefiniowane oczekiwania.

W skrócie:

Nie.

Jeśli masz wystarczająco ciasną i ograniczoną specyfikację, możesz być w stanie udowodnić, że program jest wolny od błędów, ale tylko w oparciu o nie dające się udowodnić założenia dotyczące poprawnego działania wszystkiego innego w systemie. Pozostawia to jako oczywistość, że nie ma sposobu, aby udowodnić, że specyfikacje byłyby uważane za poprawne przez tego, kto stworzył pierwotny problem lub przez osobę korzystającą z usługi.

Uważam, że sekcja Jima Shore'a „ No Bugs” to bardzo przydatna lektura na ten temat. Krótka forma: Nie można się rozwijać bez produkowania błędów - ale możemy pracować w taki sposób, aby wykryć je jak najwcześniej.

Podczas produkcji samego kodu. Na przykład, pisząc i często uruchamiając testy jednostkowe podczas programowania, stale zapewniamy, że kod wykonuje to, co powinien. Przydatne jest także ciągłe przepisywanie istniejącego kodu w taki sposób, aby jak najdokładniej wyrażał zamierzone zachowanie systemu.

W twoim przypadku jednak mówisz o istniejącej bazie kodu z milionami linii kodu. Jeśli chcesz uzyskać taki błąd systemu, musisz przede wszystkim wiedzieć, co to jest błąd w tym systemie. Możesz napisać pakiety testów post-hoc zapewniających funkcjonalność systemu (jeśli jeszcze nie istnieje). Sieć tych testów może służyć jako przybliżona definicja prawidłowego działania systemu. Ale im więcej masz kodu, tym więcej wysiłku wymaga ten rodzaj ćwiczeń. Dlatego większość firm idzie na kompromis: żyją z niedoskonałością, pracują z listami błędów i konserwacją, aby uzyskać najbardziej denerwujące błędy z systemu.

O weryfikacji przez część komputerową.

Istnieją dwa sposoby weryfikacji programu za pomocą komputera. Jeden testuje, drugi używa systemu sprawdzającego.

Jak tylko wyczerpujące testy nie są możliwe, testowanie nie jest w stanie wykazać, że program nie zawiera błędów, tylko że ma pewne. (I masz problem z pokazaniem, że twoje testy same nie testują na obecność błędów).

Aby użyć systemu sprawdzania, zaczynasz od wymagań formalnych (a one same mogą mieć błąd, mam nadzieję, że język użyty do wymagań będzie bardziej odpowiedni, aby przekonać się, że nie ma tam błędu niż w języku programowania) i zbudować / udowodnić za pomocą pomoc systemów dowodowych, że program jest wolny od błędów (i jest kwestia błędów w systemach dowodowych, ale okazały się one poprawne). Obecny stan techniki to kompilator dla podzbioru C (i ten podzbiór nie jest akademicki, „CompCert obsługuje wszystkie podzbiory C MISRA-C 2004, a także wiele funkcji wykluczonych przez MISRA”).

Nie, ponieważ środowisko komputerów i oprogramowania, na którym działa aplikacja, będzie się zmieniać nawet po zamrożeniu kodu. System operacyjny ewoluuje wraz z łatkami i poprawkami, a także urządzeniami i sterownikami. Właśnie wtedy, gdy uważasz, że osiągnąłeś poziom nieznanych błędów, AMD lub nVidia wydadzą aktualizację sterownika wideo, która ma wpływ na sposób interakcji z podsystemem wideo. Teraz Twoja aplikacja ma wady wizualne (takie jak miganie, migotanie lub redukcja liczby klatek na sekundę) dla klientów posiadających określoną kartę graficzną lub konfigurację (SLI? LOL).

Oprócz sprzętu i systemu operacyjnego, pod najważniejszymi aplikacjami znajduje się także szereg produktów pośrednich, które również ewoluują poza twoją kontrolą, a gdy tylko kod stanie się zerowy, stan warstw pod spodem zostanie zmieniony na EOL.

Technologia ewoluuje, podobnie jak firma, która wykorzystuje tę technologię, a idea „uwolnienia” kodu nie jest możliwa ani wykonalna. Firma, która prosi o nowy zestaw funkcji, nie zareaguje dobrze na „mamy zablokowany kod, gdy ścigamy wszystkie znane błędy i nikt nie zgłasza prawidłowej wady oprogramowania w ciągu X miesięcy”. Nawet jeśli firma kupi tę linię, po X miesiącach spyta, w jaki sposób pojawią się nowe funkcje, a odpowiedź nie może być „postanowiliśmy przedłużyć zawieszenie, ponieważ Oracle właśnie wydało łatkę i potrzebujemy X kolejnych miesięcy poświadczam, że ".

Nie, w pewnym momencie firma będzie szukała bardziej elastycznego zespołu programistów, który wspiera potrzebę rozwoju z prędkością technologii. Jest to podstawowy problem, przed którym stoją nowoczesne zespoły programistyczne.

Tak, ale nigdy się nie dowiesz. Im trudniej wyglądasz, tym więcej znajdziesz. Im cięższy jest system i im więcej przypadków na krawędziach jest używanych, tym bardziej podobna będzie kolejna niezgodność z pierwotną intencją lub specyfikacją. Oznacza to, że sam błąd nie jest dokładną rzeczą i często będzie zależeć od interpretacji, od tego, jak źle ktoś oceni postrzeganą anomalię.

To jest rozmyta rzecz. Niewiele systemów zostało określonych aż do ostatniego bitu. Jeśli system działa dobrze, a użytkownicy nie mają żadnych skarg (nic ich nie podsłuchuje) i są do niego całkowicie przystosowani, równie dobrze można go nazwać wolnym od błędów.

Możliwe jest konsekwentne dostarczanie oprogramowania wolnego od błędów, przy zachowaniu odpowiedniej dyscypliny i wspólnej kultury zespołu. (I dobrze przemyślany modułowy kod, kompleksowy zestaw zautomatyzowanych testów, sprawdzanie defektów i dostosowywanie procesu, oraz wiele innych rzeczy, które wymagają wysiłku i pokory, ale zwracają tysiąc razy)

Ale robiąc to, generalnie nie zamierzasz budować systemu 20 MLOC. Jeśli pisanie kodu wolnego od błędów nie jest twoim celem, nie powinno też być budowania wielu systemów MLOC.

Moje własne rozumowanie jest następujące:

Ktoś musi spełnić. Pewna osoba (być może ta sama, być może inna) ma budżet na zaspokojenie potrzeb poprzez pisanie oprogramowania. Wszyscy ci ludzie oczekują pewnych korzyści za swoje pieniądze.

Osoba z budżetem zapłaci niektórym osobom (być może tym samym, być może innym) programistom , aby ci programiści zamienili część ustalonego czasu na oprogramowanie spełniające potrzeby.

Ci programiści pracują zatem nad przekształceniem czyichś pieniędzy w oprogramowanie spełniające potrzeby. Ich obowiązkiem jest dobre wykorzystanie tych pieniędzy.

Ma to następujące konsekwencje w odniesieniu do twojego pytania:

• Biorąc pod uwagę, że w oprogramowaniu jest błąd, czy w ogóle go naprawisz? Potrzebujesz programisty, aby naprawić błąd, a programista będzie kosztował. Programista nie może zdecydować, czy wydać na to pieniądze. Jest to rola osoby posiadającej budżet.
• Czy mogę zbudować oprogramowanie 20MLOC od zera, nie pozostawiając niezmienionych błędów? Cóż, rozpoczęcie budowy 20 MLOC wymagało zamiaru wydania ogromnej kwoty pieniędzy. To jest głupie finansowo. I nie jest zbudowany w jeden dzień. Ale oprogramowanie jest na dzisiejsze potrzeby, a nie jutro. Będzie błędna próba zrównoleglenia rozwoju poprzez zatrudnienie wielu programistów. Ale wtedy są szanse, że nie dostaniesz wspólnej kultury i pojawią się błędy, pojawią się marnotrawstwo i opóźnienie, i zabraknie pieniędzy, aby je naprawić. Nie widziałem jeszcze żadnego systemu bez błędów tego rozmiaru. (Widziałem systemy wolne od błędów i systemy 20MLOC, ale nie były takie same)
• Jestem odpowiedzialny za utrzymanie systemu 20MLOC, którego nie napisałem. Czy będę w stanie osiągnąć zero znanych błędów? Nie zależy to od programistów. Nie mogą zdecydować się na naprawienie błędów, ponieważ to nie ich pieniądze na linii. Czy jest wystarczający zwrot z inwestycji, aby naprawić pozostałe błędy? Cóż, system istnieje już od jakiegoś czasu, a użytkownicy przyzwyczaili się do niego i wykorzystują dziwactwa systemu na swoją korzyść w codziennej pracy. Jeśli naprawisz błędy z zasady, osoba z pieniędzmi może być zmuszona zapłacić za przebudowę jakiejś nieokreślonej funkcji, która zniknęła z systemu, co kosztuje jeszcze więcej pieniędzy.

Chodzi o pieniądze i słusznie.

Tak.

Ale jak wiadomo, aby być tego wartym, potrzeba zbyt wiele wysiłku.

Zanim będę w stanie obronić moją odpowiedź, musimy najpierw zdefiniować, czym jest błąd:

• Błąd to zachowanie niezgodne ze specyfikacją.
• Jednak usterki w specyfikacji (np. 0 zasada robotyki) nie liczą się jako błędy oprogramowania.
• Dodatkowe funkcje nie są liczone jako błędy, chyba że jest to zabronione przez specyfikację.
• Ze względu na argumenty sprzeczności w specyfikacji również nie liczą się jako błędy oprogramowania.

Teraz, jak miejmy nadzieję, już wiesz, dobre architektury oprogramowania są modułowe, dzięki czemu każdy moduł może być testowany jednostkowo (lub ręcznie lub cokolwiek) indywidualnie. Dzięki dyscyplinie i starannym testom możliwe jest pisanie pojedynczych modułów, które nie zawierają błędów.

"Ale poczekaj!" Słyszę twój protest: „Co jeśli nieoczekiwane (ale mimo to poprawne) zachowanie jednego modułu spowoduje błąd w innym?” Zatem błąd znajduje się w drugim module. Moduły wolne od błędów mogą być traktowane jako interfejsy API, a interfejsy API, jak wiadomo, wymagają pewnej uwagi, aby były prawidłowo używane.

Pisanie kodu kuloodpornego wymaga dużej wiedzy na temat przypadków brzegowych i logiki przepływu ze strony programisty, a większość programistów albo nie jest wystarczająco inteligentna, by się uczyć, albo po prostu nie obchodzi. Lub częściej są w terminie.

„Ale daj mi miejsce, aby stać, a ja poruszę światem”. - Archimedes