Sto parlando di 20-30 + milioni di righe di codice, ad esempio software su scala e complessità di Autodesk Maya.

Se congeli lo sviluppo per tutto il tempo necessario, puoi effettivamente correggere tutti i bug fino a quando non c'è semplicemente un singolo bug, se una cosa del genere può essere verificata dai computer? Quali sono gli argomenti a favore e contro l'esistenza di un sistema privo di bug?

Perché c'è qualche idea che ogni correzione che fai crei più bug, ma non credo sia vero.

Per bug intendevo dai semplici errori di battitura nell'interfaccia utente, a bug preventivi più gravi che non hanno soluzione. Ad esempio una particolare funzione di scripting calcola le normali in modo errato. Anche quando ci sono soluzioni alternative, il problema deve ancora essere risolto. Quindi potresti dire che puoi fare questa particolare cosa manualmente invece di usare la funzione fornita ma quella funzione deve ancora essere riparata.

Come ha detto Mikey, scrivere un codice senza errori non è l'obiettivo. Se questo è ciò a cui stai puntando, allora ho delle pessime notizie per te.

Il punto chiave è che stai ampiamente sottovalutando la complessità del software.

Per prima cosa, stai ignorando il quadro generale di come viene eseguito il tuo programma. Non funziona in modo isolato su un sistema perfetto. Anche il più semplice dei programmi "Hello World" funziona su un sistema operativo e, quindi, anche il più semplice dei programmi è suscettibile di bug che possono esistere nel sistema operativo.

L'esistenza delle biblioteche rende questo più complesso. Mentre i sistemi operativi tendono ad essere abbastanza stabili, le biblioteche sono un miscuglio quando si tratta di stabilità. Alcuni sono meravigliosi. Altri ... non tanto ... Se vuoi che il tuo codice sia privo di bug al 100%, dovrai anche assicurarti che ogni libreria su cui corri sia completamente priva di bug, e molte volte questo semplicemente non è possibile come potresti non avere il codice sorgente.

Quindi ci sono discussioni a cui pensare. La maggior parte dei programmi su larga scala usa discussioni ovunque. Cerchiamo di stare attenti e scrivere i thread in modo tale che non si verifichino condizioni di competizione e deadlock, ma semplicemente non è possibile testare ogni possibile combinazione di codice. Per testarlo in modo efficace, è necessario esaminare ogni possibile ordinamento dei comandi che attraversano la CPU. Non ho fatto la matematica su questo, ma sospetto che enumerare tutti i possibili giochi di scacchi sarebbe più facile.

Le cose vanno da difficili a impossibili quando guardiamo la macchina stessa. Le CPU non sono perfette. La RAM non è perfetta. I dischi rigidi non sono perfetti. Nessuno dei componenti all'interno di una macchina è progettato per essere perfetto - sono progettati per essere "abbastanza buoni". Anche un programma perfetto alla fine fallirà a causa di un singhiozzo da parte della macchina. Non c'è niente che puoi fare per fermarlo.

Concludendo: puoi scrivere "Bug free software"?

NO

Chiunque ti dica altrimenti è all'oscuro.

Prova a scrivere un software che sia facile da capire e mantenere. Una volta fatto, puoi chiamarlo un giorno.

EDIT: Alcune persone hanno commentato un punto eccellente che avevo completamente trascurato: il compilatore.

A meno che tu non stia scrivendo in assembly, è del tutto possibile che il compilatore rovini il tuo codice (anche se provi che il tuo codice è "perfetto").

Un elenco di bug in GCC, uno dei compilatori più comunemente usati: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=---

Matematicamente, potrebbe essere possibile scrivere software "senza errori" di tale complessità, a seconda di come si definisce "bug". Dimostrarlo potrebbe anche essere matematicamente possibile, progettando un sistema di test che eserciterebbe ogni riga di codice in ogni modo possibile - ogni possibile caso d'uso. Ma non sono sicuro: se hai a che fare con un sistema che esegue calcoli complessi, potresti incorrere in un "problema di infinito" ...

In pratica, in un sistema delle dimensioni e dell'ambito di cui stai parlando, questo è IMPOSSIBILE . Potrebbero essere necessari 1000 anni per scrivere un tale sistema "privo di bug" e per scrivere un sistema per dimostrare che ci vorrebbe esponenzialmente più tempo: dovresti trovare ogni possibile caso d'uso e scrivere un sistema che verifichi ogni uno - e non credo che ci sia modo di determinare che tu abbia effettivamente coperto ogni caso d'uso in un sistema delle dimensioni e dell'ambito di cui stai parlando in qualcosa che assomigli ad un ragionevole lasso di tempo.

IMO la tua domanda è un po 'mal indirizzata: il nostro obiettivo come sviluppatori non è quello di scrivere software "senza errori". Il nostro obiettivo è scrivere software UTILIZZABILE, FLESSIBILE, FACILMENTE MANUTENIBILE .

Utilizzabile: il sistema soddisfa i requisiti essenziali per i quali è stato progettato. Potrebbero esserci dei bug - ma saranno in "casi limite" - valori anomali o fastidi, non bug che compromettono i fondamenti del sistema - robusti.

Manutenzione: i bug possono essere facilmente isolati e corretti e NON creare nuovi bug.

Flessibile: il tuo sistema è facile da modificare ed espandere senza riprogettazione e tempi di inattività significativi: la maggior parte delle modifiche richiede semplicemente l'aggiunta di una nuova classe o modulo che si adatta ai tuoi schemi e framework già ben progettati.

Buone pratiche di progettazione, buone pratiche di controllo, buon lavoro di squadra, sviluppatori coscienziosi: questa è la formula per GOOD SOFTWARE . (non PERFETTO - ma BUONO )

Secondo questo articolo, il software di bordo per lo Space Shuttle si è avvicinato molto: le ultime tre versioni del programma 420.000 line avevano solo un errore ciascuna. Il software è stato gestito da un gruppo di 260 uomini e donne. Un gran numero di queste persone erano verificatori, il cui unico scopo era trovare errori.

L'aggiornamento del software per consentire alla navetta di navigare con i satelliti di posizionamento globale ha avuto un impatto solo sull'1,5% del programma, ovvero 6.366 righe di codice. Le specifiche per quell'unica modifica sono state di 2.500 pagine. Le specifiche per il programma complessivo hanno riempito 30 volumi ed eseguito 40.000 pagine, ovvero una media di dieci righe di codice per pagina della specifica.

Il budget non era un problema: a $ 35 milioni all'anno, potevano permettersi di fare le cose nel modo giusto.

In sostanza, no, ma dovresti comunque fare del tuo meglio. Spiegherò perché (o semplicemente saltare alla conclusione se non hai abbastanza pazienza)

Considera un problema banale come l'implementazione della ricerca binaria. Un'implementazione molto popolare ha avuto un bug che non è stato rilevato per circa due decenni. Se venti linee impiegano venti anni per ottenere un uso senza errori e persino apparentemente dimostrato corretto, possiamo davvero aspettarci che un enorme programma sia privo di errori?

Quanti bug possiamo aspettarci comunque da un programma enorme? Un numero che ho trovato è stato "10 difetti per 1000 righe" (Codice completo 2a edizione, pagina 517 - semplicemente usato un esempio, non citando alcun dato) che ci dà circa 200.000 a 300.000 bug nel tuo software. Fortunatamente, abbiamo modi per migliorare la qualità del programma. Test di unità, revisioni del codice e test manuali ordinari sono noti per ridurre il numero di bug. Tuttavia, il numero sarà ancora elevato.

Se potessimo risolvere il 95% di tutti i bug sarebbe incredibile. Eppure avremmo ancora da 10.000 a 15.000 bug nel software.

Fortunatamente, dal momento che il software è ampiamente utilizzato (e, quindi, ampiamente testato) verranno trovati bug. Quindi avremo gradualmente meno bug. Tuttavia, un minor numero di bug significa anche che quelli rimanenti sono più difficili da trovare, quindi non aspettatevi una curva lineare nella correzione dei bug. Gli ultimi bug saranno davvero difficili da trovare e potrebbero sfuggire al rilevamento per diversi anni (supponendo che siano mai stati trovati).

Sembra anche che tu stia assumendo erroneamente che se il software non cambia, non verranno visualizzati nuovi bug. Se il software dipende da librerie di terze parti, le nuove versioni potrebbero interrompere alcune funzionalità, introducendo nuovi bug anche se il codice dell'applicazione è sempre lo stesso. I nuovi sistemi operativi possono anche interrompere un'applicazione che in precedenza funzionava perfettamente (vedi Windows Vista per un esempio popolare). Considera anche i bug del compilatore, ecc.

Non è chiaro se gli strumenti a prova di codice possano veramente risolvere il problema del software difettoso. Non è certamente possibile risolvere il problema di arresto per qualsiasi programma, ma potrebbe essere possibile dimostrare che un programma si comporta come specificato ... Ma allora? Forse il programma di prova ha un bug. Forse la specifica stessa ha un bug.

Quindi, chiaramente, possiamo ridurre notevolmente il numero di bug, ma è davvero improbabile che arriveremo mai a zero.

Perché c'è qualche idea che ogni correzione che fai crei più bug, ma non credo sia vero.

(enfasi aggiunta)

Hai ragione. Questa affermazione è sbagliata. Ecco un esempio:

int main() {
    int x[10];
    x[10] = 8; //Buffer overflow here
    return 0;
}

Ora, risolviamo questo errore:

int main() {
    int x[11];
    x[10] = 8; //No buffer overflow here
    return 0;
}

Vedere? Abbiamo corretto un bug e non ne abbiamo introdotti di nuovi.

Tuttavia, è certamente corretto che ogni volta che si risolve un bug si rischia di crearne uno nuovo, sebbene questo rischio possa essere mitigato (ad es. Con test unitari).

Diciamo che per ogni 100 bug che correggo, ne introduco accidentalmente uno nuovo. Quindi, se correggo 10.000 bug, presento 100 nuovi bug. E se correggo quei nuovi bug, introduco un bug. Ma allora? Il programma ora ha 9 999 bug in meno, quindi probabilmente è meglio di prima (supponendo che il nuovo bug non sia 10.000 volte peggiore rispetto ai precedenti).

Inoltre, la correzione di un bug può esporne di nuovi. Ma anche questi bug possono essere corretti. Se fai le cose nel modo giusto, alla fine il software sarà in uno stato migliore di quello in cui è stato avviato.

Sono stato vecchio da alcuni dei migliori programmatori che è meglio non correggere molti bug a causa dell'idea che ho citato nell'OP.

Questo comportamento è negligente. Se c'è un bug e puoi risolverlo. Fallo. Ovviamente dovresti fare del tuo meglio per evitare di aggiungerne di nuovi, ma se introduco un piccolo bug per ogni 10 bug gravi che correggo, questo non è un motivo valido per interrompere la correzione dei bug. In effetti, è un buon motivo per continuare a correggere i bug .

Quindi meno bug corretti, meno bug torneranno in futuro

Meno bug correggi, più bug rimarranno nel tuo software, infastidendo i tuoi utenti. Anzi, non "torneranno da te in futuro". Non torneranno perché non sono mai partiti in primo luogo. La nozione di "ritorno" è legata alle regressioni. Ancora una volta, è possibile ridurre il rischio di regressioni.

Alcuni bug non possono essere corretti perché sono diventati così ampiamente utilizzati che le persone hanno iniziato a dipendere da loro e correggere il bug avrebbe spezzato il programma per quegli utenti. Succede. Tuttavia, possono davvero essere considerati bug in quel caso?

La mentalità "correggi un bug, crea un bug" potrebbe essere correlata a Quel mostro orribile - codice che è così illeggibile e non realizzabile che semplicemente toccandolo crea bug. Se hai un mostro nella tua base di codice, potresti aver bisogno di annullare la sua mostro prima di fare qualsiasi cosa.

Infine, se sei un programmatore terribile, c'è il rischio che qualsiasi cosa tocchi crei nuovi bug. Ciò ovviamente renderebbe nervosi i programmatori senior. Tuttavia, dicendo "Non fare nulla. Non toccare nulla. Non respirare nemmeno." probabilmente non è il modo giusto per creare un ambiente di lavoro sano. L'istruzione è migliore.

Conclusione:

• Il software che continua a ricevere tonnellate di nuove funzionalità ma nessuna correzione di bug inevitabilmente farà schifo.
• Il software che ottiene un numero moderato di nuove funzionalità ma che risolve i suoi bug ha maggiori possibilità di essere utilizzabile.
• Coloro che cercano di avere pochi bug hanno (in media) meno bug di quelli a cui non importa.
• Non è ragionevole aspettarsi che un programma alla fine diventi privo di bug.
• I programmatori senior non sono necessariamente competenti.
• Risolvi i tuoi bug.
• Adottare metodologie che migliorino la qualità del tuo software.

Le ragioni per non scrivere programmi senza bug sono per lo più economiche.

Ci sono metodi matematici per dimostrare la correttezza di un programma. Saranno menzionati in un corso di informatica di alta qualità. Esistono linguaggi di programmazione inventati appositamente per questo scopo. In teoria, è possibile programmare senza bug .

Sì, c'è l'hardware imperfetto che a volte può cambiare un po 'di valore perché un neutrino sparato da una supernova lontana milioni di anni fa ha appena colpito il processore nel posto giusto. Va bene, ogni teoria ha i suoi presupposti e le sue astrazioni. Supponendo che il processore funzioni come pubblicizzato, esistono strumenti matematici per assicurarsi che anche il programma funzioni correttamente.

Alcune risposte molto votate in questo argomento sono fuorvianti. Ad esempio, il teorema di incompletezza di Gödel e il problema di arresto implicano solo che non si può avere, ad esempio, uno strumento automatizzato che decida la correttezza o l'erroneità di qualsiasi programma. Ma non vogliamo decidere la correttezza di alcun programma, vogliamo solo una prova della correttezza di un programma specifico .

(Analogamente, solo perché non puoi scrivere un programma per decidere automaticamente la verità di alcun teorema matematico, ciò non significa che non puoi provare un teorema matematico specifico .)

Il problema, invece, è questo:

Sebbene in teoria sia possibile scrivere un programma privo di bug, farlo sarebbe molto costoso . Scrivere un codice con una prova della sua correttezza è più complicato che semplicemente lanciare qualcosa a un muro per vedere se si attacca. Anche se "vedere se si attacca" viene eseguito dai test unitari; e molti programmatori non si preoccupano nemmeno di farlo. La maggior parte dei programmatori non saprebbe nemmeno come farlo, il che significa che come azienda dovresti assumere quelli più costosi.

Considerando tutti i costi, un cliente tipico è più soddisfatto di un software economico che funziona bene il 99% delle volte (e il 99,9% delle volte dopo l'installazione di aggiornamenti aggiuntivi) piuttosto che avere un software forse mille volte più costoso che funziona bene il 100% di il tempo. Inoltre, il cliente desidera avere questo software ora e non tra dieci o venti anni.

Pertanto, le persone producono consapevolmente software che ha qualche possibilità di bug, cercando di raggiungere la combinazione ottimale in cui i bug non sono troppo frequenti e non troppo seri e la produzione è abbastanza veloce ed economica. La combinazione che offre il massimo profitto nella vita reale. (A volte significa anche rilasciare un software pieno di bug prima che i tuoi concorrenti rilascino qualcosa e rilasciare una versione più decente 2.0 quando i tuoi concorrenti sono pronti a rilasciare la loro prima versione decente.)

Se congeli lo sviluppo per tutto il tempo necessario, puoi effettivamente correggere tutti i bug fino a quando non c'è semplicemente un singolo bug, se una cosa del genere può essere verificata dai computer?

Matematicamente parlando, potresti. A livello economico, perché qualcuno dovrebbe farlo? Significherebbe spendere forse vent'anni e qualche milione di dollari. Nel frattempo, i clienti vorrebbero nuove funzionalità e le applicazioni bloccate non potrebbero fornirle. Quindi, nel momento in cui la tua versione perfetta è pronta, il mercato è già preso dai tuoi concorrenti.

Il ragionamento economico è OK. Viviamo in un mondo in cui denaro e tempo contano. Ma solo perché non facciamo qualcosa per motivi economici, non dovremmo dire cose senza senso su come ciò non possa essere fatto nemmeno in teoria. Chissà ... forse tra qualche anno avremo alcuni nuovi linguaggi e strumenti di programmazione che potrebbero rendere facile la correttezza .

No.

David Hilbert propose il suo secondo problema di matematica nel 1900 che essenzialmente chiedeva al mondo di dimostrare che l'aritmetica funzionava come previsto. In seguito ha sostenuto " il problema di Entscheidungs ", che ha chiesto qualcosa di simile in termini logici. Il " primo teorema di incompletezza " di Kurt_Gödel dimostrò nel 1931 che nessuna teoria dell'aritmetica elementare poteva essere coerente e completa. La rappresentazione di Alan Turing del problema di Entscheidungs ​​come " il problema dell'arresto " ha spostato la questione direttamente nel cuore di questa domanda, dove ha dimostrato che è impossibile dimostrare se un programma verrà completato o meno. Dato che non è affidabile, è anche impossibile provare se un programma ha qualche bug o meno.

Niente di tutto ciò libera i programmatori che praticano tra di noi dalla ricerca di bug. Significa semplicemente che non possiamo avere successo in generale.

Errare humanum est

Anche se scrivi codice con un linguaggio formale, come il metodo B , che puoi utilizzare per dimostrare matematicamente che i requisiti sono soddisfatti,

Anche se usi un linguaggio di specifica formale,

C'è sempre un passo umano che consiste nell'estrarre le esigenze dell'utente da uno o più cervelli su un computer.

Questo passaggio umano è soggetto a errori e il worm è nella mela.

Una buona parte dei "bug" che ho riscontrato potrebbe essere meglio descritta come disallineamento tra progettazione del sistema e aspettative dei clienti.

Ora, sia che chiamiamo questi bug o meno, è accademico, ma resta il fatto che una buona parte del lavoro di manutenzione nasce come risultato diretto della comunicazione imperfetta e del cambiamento delle aspettative dei clienti.

Anche se un sistema è tecnicamente, dimostrabilmente "corretto" nel senso di soddisfare una specifica (per quanto improbabile possa essere per il software commerciale del mondo reale), avrai comunque il problema di abbinare la funzione del software alla sempre-cliente del tuo cliente aspettative mutevoli e mal definite.

In breve:

No.

Se si dispone di una specifica sufficientemente rigorosa e limitata, si potrebbe essere in grado di dimostrare un programma privo di bug, ma basato solo su ipotesi non dimostrabili sul corretto funzionamento di tutto il resto del sistema. Questo lascia come dato di fatto che non c'è modo di provare che le specifiche sarebbero state considerate corrette da chiunque abbia posto il problema originale o da chiunque stesse usando il servizio.

Ho trovato la sezione No Bugs di Jim Shore una lettura molto utile su questo argomento. La forma abbreviata: non è possibile svilupparsi senza produrre bug, ma possiamo lavorare in modo tale da rilevarli il prima possibile.

Durante la produzione del codice stesso. Ad esempio, scrivendo ed eseguendo test di unità frequentemente durante lo sviluppo, garantiamo costantemente che il codice faccia quello che dovrebbe fare. Inoltre, è utile riscrivere perennemente il codice esistente in modo tale da esprimere in modo più chiaro il comportamento del sistema previsto.

Nel tuo caso, tuttavia, stai parlando di una base di codice già esistente con milioni di righe di codice. Se vuoi ottenere un tale bug di sistema libero, prima di tutto devi sapere cosa è "un bug" per questo sistema. Potresti scrivere suite di test post-hoc assicurando la funzionalità del sistema (se non ancora esistente). La rete di questi test può servire da definizione approssimativa per il corretto comportamento del sistema. Ma più codice hai, maggiore è lo sforzo in tali esercizi. Pertanto, la maggior parte delle aziende scende a compromessi: convive con l'imperfetto, lavorando con elenchi di bug e manutenzione per eliminare dal sistema i bug più fastidiosi.

Informazioni sulla verifica da parte del computer.

Esistono due modi per verificare un programma utilizzando un computer. Uno sta testando, l'altro sta usando il sistema di prova.

Non appena i test esaustivi non sono possibili, i test non sono in grado di dimostrare che un programma non ha bug, solo che ne ha alcuni. (E hai il problema di dimostrare che i tuoi test stessi non stanno testando la presenza di bug).

Per utilizzare un sistema di prova, si parte da requisiti formali (e potrebbero avere bug, si spera che il linguaggio utilizzato per i requisiti sia più adatto a convincersi che non esiste alcun bug rispetto a un linguaggio di programmazione) e costruire / provare con l'aiuto dei sistemi di prova che il programma è privo di bug (e c'è la questione dei bug nei sistemi di prova, ma si sono dimostrati corretti). Lo stato dell'arte attuale è un compilatore per un sottoinsieme C (e il sottoinsieme non è accademico, "CompCert supporta tutto il sottoinsieme MISRA-C 2004 di C, oltre a molte funzionalità escluse da MISRA").

No, perché l'ambiente del computer e del software su cui è in esecuzione l'applicazione continuerà a cambiare anche mentre il codice è bloccato. Il sistema operativo continua a evolversi con patch e correzioni, nonché con dispositivi e driver. Proprio quando pensi di aver raggiunto il punto in cui non sono noti bug, AMD o nVidia rilasceranno un aggiornamento del driver video che influisce sul modo in cui interagisci con il sottosistema video. Ora l'applicazione presenta difetti visivi (come lampeggiamento, sfarfallio o riduzione della frequenza dei fotogrammi) per i clienti che hanno una determinata scheda video o configurazione (SLI? LOL).

Oltre all'hardware e al sistema operativo, ci sono anche una serie di prodotti middleware sotto le app più significative che si evolveranno al di fuori del tuo controllo, e non appena il codice viene portato a zero, i livelli sottostanti ottengono EOL.

La tecnologia si evolve, così come il business che sfrutta la tecnologia e l'idea di "liberare" il codice non è possibile o fattibile. L'azienda che richiede un nuovo set di funzionalità non risponderà bene a "abbiamo bloccato il codice mentre inseguiamo tutti i bug noti e nessuno segnala un difetto del software valido in X mesi". Anche se l'azienda acquista quella linea, dopo X mesi chiederanno come stanno arrivando le nuove funzionalità e la risposta non può essere "abbiamo deciso di estendere il blocco perché Oracle ha appena rilasciato una patch e abbiamo bisogno di impiegare X più mesi per certificare che ".

No, a un certo punto l'azienda cercherà un team di sviluppo più flessibile che supporti la necessità di andare avanti alla velocità della tecnologia. Questo è il problema fondamentale che devono affrontare i moderni team di sviluppo.

Sì, ma non lo saprai mai per certo. Più guardi duro più troverai. Più pesante è il sistema e più casi limite vengono utilizzati, più simile si troverà un'altra discrepanza con l'intento o le specifiche originali. Ciò implica che un bug in sé non è una cosa esatta e dipenderà spesso dall'interpretazione, da quanto male un individuo valuta un'anomalia percepita.

È una cosa confusa. Pochi sistemi sono specificati fino all'ultimo bit. Se un sistema funziona bene e gli utenti non hanno lamentele (non sono disturbati da nulla) e sono totalmente adattati ad esso, puoi anche chiamarlo privo di bug.

È possibile fornire costantemente software privo di bug, data la disciplina sufficiente e la cultura del team condivisa. (E un codice modulare ben ponderato, una suite completa di test automatizzati, ispezione dei difetti e adattamento del processo e molte altre cose che richiedono impegno e umiltà ma che ripagano mille volte)

Ma facendo questo, generalmente non hai intenzione di costruire un sistema 20 MLOC. Se la scrittura di codice privo di bug non è il tuo obiettivo, nessuno dei due dovrebbe creare un sistema MLOC.

Il mio ragionamento è il seguente:

Qualcuno ha bisogno di soddisfare. Qualcuno (forse lo stesso, forse uno diverso) ha un budget per soddisfare la necessità attraverso la scrittura di software. Tutte queste persone si aspettano di ottenere dei benefici per i loro soldi.

La persona con un budget pagherà alcune persone (forse le stesse, forse diverse) chiamate programmatori , in modo che questi programmatori trasformino parte del loro tempo concordato in software che soddisfi la necessità.

Questi programmatori lavorano quindi per trasformare i soldi di qualcun altro in software che soddisfi la necessità. È loro responsabilità mettere a frutto questi soldi.

Ciò ha le seguenti implicazioni per quanto riguarda la tua domanda:

• Dato che c'è un bug nel software, lo risolverai? È necessario un programmatore per correggere un bug e il programmatore avrà un costo. Un programmatore non può decidere se spendere i soldi per farlo. È il ruolo della persona che detiene il bilancio.
• Posso creare un software 20MLOC da zero senza lasciare bug non risolti alla fine? Bene, partire per costruire un 20MLOC ha richiesto l'intenzione di spendere un'enorme quantità di denaro. Questo è finanziariamente sciocco. E non è costruito in un giorno. Ma il software è per le esigenze di oggi, non per domani. Ci sarà un tentativo fuorviante di parallelizzare lo sviluppo assumendo molti programmatori. Ma poi, è probabile che non otterrai una cultura condivisa e ne conseguiranno degli errori, si verificheranno sprechi e ritardi e il denaro finirà per risolverli. Non ho ancora visto alcun sistema privo di bug di queste dimensioni. (Ho visto sistemi senza bug e sistemi 20MLOC, ma non erano gli stessi)
• Sono responsabile del mantenimento di un sistema 20MLOC che non ho scritto. Sarò in grado di raggiungere zero bug noti? Ciò non dipende dai programmatori. Non possono decidere di correggere i bug perché non sono i loro soldi sulla linea. C'è abbastanza ROI per correggere i bug rimanenti? Bene, il sistema è in circolazione da un po 'di tempo e gli utenti si sono abituati e usano le stranezze del sistema a proprio vantaggio nel loro lavoro quotidiano. Se correggi i bug per principio, la persona con i soldi potrebbe dover pagare per riqualificare alcune funzionalità non specificate che sono scomparse dal sistema, costando ancora più denaro.

Si tratta solo di soldi, e giustamente.

Sì.

Ma come sai, richiede troppo sforzo per valerne la pena.

Prima di poter difendere la mia risposta, dobbiamo prima definire cos'è un bug:

• Un bug è un comportamento contrario alle specifiche.
• Tuttavia, i difetti nella specifica (ad es. La nona legge della robotica) non contano come bug del software.
• Le funzionalità extra non vengono considerate come bug, a meno che non siano vietate dalle specifiche.
• Per ragioni di argomento, le contraddizioni all'interno delle specifiche non contano neanche come bug del software.

Ora, come si spera già saprai, le buone architetture software sono modulari, in modo che ogni modulo possa essere testato unitamente (o testato manualmente o altro) individualmente. Attraverso la disciplina e test accurati, è possibile scrivere singoli moduli che non contengono bug.

"Ma aspetta!" Ti sento protestare, "Che cosa succede se un comportamento inaspettato (ma comunque corretto) di un modulo provoca un bug in un altro?" Quindi il bug si trova nel secondo modulo. I moduli senza bug possono essere trattati come API e le API, come sai, richiedono un po 'di cura per essere usate correttamente.

La scrittura di codice a prova di proiettile richiede una conoscenza approfondita dei casi limite e della logica di flusso da parte dello sviluppatore e la maggior parte degli sviluppatori di software non è abbastanza intelligente da imparare o semplicemente non gliene importa. O più spesso, sono in scadenza.

"Ma dammi un posto dove stare, e io muoverò il mondo." - Archimede