Codifica "standard" ... Ci sono molte aree di sviluppo che possono essere standardizzate. Stiamo parlando di convenzioni di codifica, come gli standard di denominazione ecc.? O stiamo parlando di qualcosa di più profondo, come TDD / BDD, CI, ecc.
Posso dirti che l'aderenza a una metodologia "test-first", con l'IC che impone test di passaggio e una buona copertura del codice, riduce il numero di bug rilevati dal client. I test automatici, sia da parte dello sviluppatore che del controllo qualità, sono anche un modo relativamente "economico" per trovare i bug perché generalmente hanno tempi di risposta molto brevi. Puoi sapere che non hai scritto quello che pensavi di aver scritto eseguendo circa 45 secondi di test unitari. Un paio d'ore di test di integrazione troveranno i punti in cui collegare le cose insieme non è andato come previsto, e i test dell'interfaccia utente automatizzati end-to-end possono individuare rapidamente errori funzionali nel software a livelli molto alti.
Inoltre prevengono la regressione. Hai trovato un bug. Si scrive un test che dimostrerà che il comportamento non si verifica più, si codifica fino a quando il test non supera, e ora si dispone di un test che da questo punto in poi farà in modo che il bug non sia mai più un problema. Questa è, nella mia esperienza, una delle principali fonti di nuovi bug; risolvere una cosa infrange qualcos'altro, e il test dello sviluppatore della correzione potrebbe non coprire quell'altra situazione che ora è rotta. Rompere le cose che prima funzionavano è una GRANDE bandiera rossa per i tuoi clienti.
Infine, questa struttura di test automatizzata che crei come parte di questa metodologia ti darà molto facilmente un ambiente in cui puoi rilasciare una nuova build del software letteralmente in un istante. "Ehi, quel bug che hai appena risolto ha causato dei veri grattacapi, quando lo avresti pronto in una nuova versione?" fai clic su "Oh, in circa 5 minuti quando il server di generazione termina di pubblicarlo nella pagina di download".
Per quanto riguarda le convenzioni di codifica di base, come la standardizzazione dei nomi di variabili ecc., ho trovato che la maggior parte di ciò è meno utile e più irritante. Quelli sono i tipi di standard che sono "meravigliosi, perché ce ne sono tanti tra cui scegliere". Ciò che percepisci come la differenza tra un identificatore PascalCased e CamelCased potrebbe non essere quello che pensa qualcun altro. Principali caratteri di sottolineatura, limiti di lunghezza del nome (o requisiti che i nomi metodo / campo raccontano una storia); diverse dalle convenzioni imposte dal compilatore o che sono comunemente viste nel codice della libreria specifico della lingua, il moderno IDE può dirti tutto ciò che devi sapere su una variabile o funzione, incluso se devi o non dovresti provare a usarlo in un particolare circostanza. Inoltre, l'esecuzione di un controllo di convenzione del codice restituirà spesso problemi con il codice che non è possibile o non si desidera modificare, ad esempio una libreria di terze parti che utilizza un diverso insieme di standard o codice di interoperabilità che può essere conforme alla denominazione dell'API Win standard invece degli standard della tua lingua madre. Finisci per aggiungere cruft al tuo codice per dire al tuo strumento di ignorare il cruft nel tuo codice.