Come le persone sono in genere molto veloci a sottolineare, uno dei vantaggi del software è che dovrebbe essere facile e relativamente economico da cambiare rispetto all'hardware. Questo è particolarmente importante quando ti rendi conto tardi che hai qualcosa di fondamentalmente sbagliato. Fai lo stesso con l'hardware e perdi un milione di dollari, così come hai detto, usi i tuoi simulatori ecc. E ne provi il bazinga. Questo penso sia dove il paradigma fallisce un po 'quando si passa al software.
Entra nella testa dello sviluppatore del software medio e quello che hai è una persona molto impegnata con una scadenza incredibilmente stretta. Il suo manager sta dicendo che è giusto lasciare qualche bug perché è sempre possibile correggerlo in un secondo momento. I test sono spesso un ripensamento, ma anche in uno scenario basato su test, i test vengono mantenuti minimi e il codice scritto al minimo dei test, e spesso vengono prese scorciatoie in modo che molti dei casi limite possano essere ignorati. Il sistema può essere accuratamente testato unitamente, ma viene raramente testato rigorosamente nel suo complesso, e altrettanto raramente sottoposto a stress in qualsiasi grado. Aggiungete a questo che scrivete il software da zero e vi sono poche opportunità di simulare il software prima di impegnarvi a scriverlo, principalmente perché raramente scriviamo software dallo stesso tipo di blocchi predefiniti che troverete nell'hardware. Preso da questa prospettiva - che non credo sia un esempio troppo esagerato - il software non è testato allo stesso livello dell'hardware, perché realisticamente non può essere, e tentare di farlo non sarebbe Seent per essere molto redditizio.
Torna alla domanda dell'OP. Potresti definire un sistema di blocchi da cui derivare tutto il tuo software? Possibilmente. Sarebbe molto redditizio? Probabilmente no, perché quando avrai a disposizione un sistema abbastanza robusto di componenti, test e altri strumenti per supportare questo sistema di programmazione ideale , scoprirai che la tua concorrenza ti avrebbe già battuto sul mercato, e ancora peggio, dal punto di vista del programmatore medio, probabilmente si troverà uno stile di programmazione "cookie-cutter" molto limitante e molto probabilmente noioso. Lavoro personalmente su un'API, in cui la maggior parte del codice del modulo è stata perfezionata e standardizzata in modo così completo, che tutto ciò che faccio ora è generare un modello di codice e riempire gli spazi vuoti. La maggior parte del mio tempo può essere speso scrivendo codice connettore semplice e portando i moduli fuori dalla porta il più velocemente possibile. È davvero sconvolgente. Ci sono pochissime opportunità di fare qualcosa di più che semplicemente codificare lo stesso tipo di cose più e più volte, così quando arriva un'altra opportunità di progetto, colgo l'occasione per poter fare QUALCHE altro.
Quindi come si può arrivare a fornire software di alta qualità e ben gestito, e tuttavia divertitevi a farlo? Credo che questo dipenda dalla scelta degli strumenti e della metodologia. Per me la risposta è stata quella di utilizzare l'uso di una buona API BDD, perché mi ha permesso di creare codice molto facile da leggere, ma altamente granulare. Posso creare una serie di test con un numero minimo di metodi riutilizzabili e descrivere i miei test nella lingua delle specifiche. In questo modo, mi avvicino a un approccio di sviluppo più compositivo, fatta eccezione per il fatto che sono responsabile della progettazione e del controllo degli elementi costitutivi. Inoltre, l'output di test individua la parte esatta del test in cui si verifica l'errore, in modo che non debba indovinare se i guasti sono nell'impostazione o nell'asserzione. Ciò significa che dedico più tempo a concentrarmi sulla risoluzione dei problemi invece di inseguirli, il mio tempo è usato in modo più efficiente, ho più lavoro svolto più rapidamente e posso passare ad altri compiti interessanti più rapidamente.
Anche l'ottimizzazione della metodologia aiuta. Sono un grande sostenitore per l'applicazione di principi di sviluppo snelli e la combinazione con molte delle altre tecniche e principi su cui il movimento Agile ha battuto da molti anni. Avendo eliminato la maggior parte delle pratiche dispendiose che trovavo così frustranti ha aiutato moltissimo a rendere lo sviluppo un'attività più piacevole. Mi rimane ancora il problema che a volte - ma si spera non troppo spesso - i bug appariranno nel mio codice, tuttavia ora mi trovo con più tempo e ancora più incentivo a dedicare più tempo a scrivere test più robusti ea puntare a 100 % di copertura del test. Ancora meglio, è davvero bello vedere tutte quelle luci verdi apparire alla fine della mia giornata, ed essere in grado di fornire un rapporto di prova completo generato automaticamente da consegnare al mio capo alla fine della giornata.