Il principio di Pareto, che il 20% delle cause è collegato all'80% dei problemi, si applica ai bug del software e, in tal caso, ci sono dei modelli comuni di nota in media entro il 20% della causa?
Certo, ci sono molti pattern dove possono emergere bug. Queste sono un paio di categorie che ho incontrato nella mia carriera, ma sono sicuro che ce ne sono molte altre.
Mancanza di proprietà - > Code Atrophy
Se ci sono moduli, strumenti o librerie di cui nessuno è responsabile allora diventerà rapidamente una fattoria di errori. Se un pezzo di codice ha un chiaro proprietario, allora qualcuno è agganciato per la chiarezza del codice e la manutenzione generale. Tuttavia, se il codice è autorizzato a marcire, molte correzioni locali finiranno per introdurre comportamenti sottili che interromperanno i clienti futuri.
Architettura scadente - > Requisiti ignorati
Un altro pattern che fa apparire gli errori è architettura scadente , in particolare l'accoppiamento stretto. Una scarsa architettura porta a componenti strettamente accoppiati che hanno un contratto non ufficiale tra loro. Ad esempio, l'inizializzazione deve avvenire in un determinato ordine. Questo porta a requisiti impliciti per l'utilizzo del codice.
Un esempio ipotetico potrebbe essere: tu crei una nuova Servlet per esporre una nuova pagina web. Tuttavia, quel servlet si arresta in modo anomalo durante la produzione. La ragione di ciò è che i servlet funzioneranno correttamente quando esposti da http://localhost/ , tuttavia, nei prod devono essere registrati con ServletAuthorizationManager o qualche altro vincolo nascosto.
Mancanza di visione: sapere chi sarà l'utente finale
Un modello sorprendente che ho visto emergere in un'azienda più grande sebbene ritenga che possa anche influire su team più piccoli (una grande azienda qui significa più uno stato mentale auto-percepito di detta società che una dimensione misurabile).
Il fatto che i progettisti di sistemi e gli architetti non vedano l'intero quadro di come il software è realmente utilizzato. Questo crea un software sistemico in cui alcune parti del sistema sono completamente ignorate nelle specifiche. Ad esempio tagliando le persone che lo configureranno per i clienti pensando e progettando il sistema che deve essere configurato dai clienti stessi. La realtà, tuttavia, rende il sistema molto complesso da configurare e installare, tanto che l'addestramento richiesto per svolgere il lavoro può richiedere mesi. Eppure persistentemente rifiutano di investire in strumenti per aiutare la configurazione di massa, rendendo l'intero processo una laboriosa operazione manuale.
Funziona più a fondo della mancanza di strumenti, documentazione, perché si ritiene che sia mirato agli utenti finali che attraversano un lungo processo di revisione e styling e un grande sforzo è posto nella volgarizzazione. Il risultato finale è un documento che è ancora troppo complesso da utilizzare per l'utente finale a causa del lungo processo di creazione di questo documento, che è obsoleto e incompleto, rendendolo inutilizzabile anche per le persone che configurano il sistema.
Questo è solo un esempio ma si applica ai team di implementazione, ai team di supporto, ai formatori e molti altri che, sebbene non partecipino direttamente alla creazione del software, sono ancora parte integrante del sistema che il software deve servire.
In breve, se costruisci un sistema per un medico, non è necessariamente lui che opererà TUTTI gli aspetti del software.
Leggi altre domande sui tag bug