Il riutilizzo del software impedisce la ripetibilità del processo

Riutilizzo del codice come problema

Stavo pensando a questa domanda sulla consegna del software e ho continuato a tornare al problema della ripetibilità e / o della riproducibilità . Sono importanti, perché se non ripeti un progetto diventa più difficile migliorare il processo che hai usato per costruire il progetto. L'ingegneria comporta il costante miglioramento dei processi coinvolti nella progettazione e costruzione al fine di produrre progetti di qualità superiore.

Il software può fare molto affidamento sul riutilizzo grazie alla sua forma digitale. Invece di riscrivere un modulo, lo chiamiamo di nuovo o lo copiamo sull'altro sistema. Alcuni esempi sono l'autenticazione / login o forse una funzione di registrazione. Ci sono molti esempi ben noti per quelle categorie, e la saggezza convenzionale è quella di riutilizzare ciò che esiste invece di far rotolare la tua.

Alcuni confronti con altre discipline

Costruzione

Al contrario, la costruzione di sistemi fisici (edifici, ponti) non è affatto riutilizzabile. È vero che il progetto di una casa può essere riutilizzato più volte per costruire la stessa copia della casa, ma la costruzione deve essere eseguita ogni volta. Cut & Paste non funziona così nel mondo analogico. I progetti Bridge sono meno riutilizzabili rispetto alle case perché le condizioni del sito possono variare.

I costruttori principali sono esperti riconosciuti per aver progettato e / o costruito decine, centinaia o migliaia di cose nella loro area. Ad esempio, Frank Lloyd Wright , architetto e designer di fama mondiale designed more than 1,000 structures and completed 532 works. In contrasto con Anders Hejlsberg che ha disegnato "solo" cinque lingue (Turbo Pascal; Delphi; J ++; C #; dattiloscritto). In molti modi, è un confronto ingiusto perché i domini sono diversi. Ma a livello generale, la produzione quantificabile di due persone molto intelligenti è molto diversa.

Arti marziali

Gli artisti marziali diranno che la padronanza di una mossa proviene solo da migliaia di ripetizioni. Dopo che una buona parte di quelle ripetizioni è stata introdotta, molti artisti marziali sono sorpresi di come un kata o una forma precedentemente percepiti siano diventati semplici. Gli istruttori di quegli studenti noteranno anche come il movimento diventa più fluido e propositivo, oltre ad avere un'economia di movimento. Allo stesso modo, gli artisti marziali esperti sono in grado di raccogliere katas più complessi più rapidamente rispetto agli studenti meno esperti. L'esperienza della ripetizione ha fornito loro una struttura o un processo che consente loro di apprendere più rapidamente.

Lavorazione del legno

I falegnami sperimentano una trasformazione simile. I falegnami hobbisti fanno sempre riferimento al loro primo progetto che ha richiesto molti cassetti. Se completano il progetto, ottengono un nuovo apprezzamento per l'efficienza che le linee di assemblaggio producono. Ci sono altri vantaggi come una migliore comprensione di come disporre le parti dei cassetti sul supporto in fogli al fine di massimizzare l'uso del legno. Rispetto agli hobbisti, i falegnami professionisti sono in grado di progettare, avviare e costruire più rapidamente oggetti che hanno realizzato molte volte in precedenza. Inoltre acquisiscono la capacità di vedere i problemi inerenti al progetto di qualcun altro dopo aver commesso quell'errore nel loro lavoro.

Quindi, il riutilizzo del software impedisce agli sviluppatori di software di diventare più competenti?

In molti modi, la progettazione e la costruzione del software sono sempre nuove. Non ripetiamo i lavori passati, perché se riusciamo a riutilizzare un modulo, una libreria o un sistema, lo facciamo. Preferibilmente estenderemo un sistema esistente prima di riscrivere l'intera cosa da zero. Ma la ripetizione è ciò che ci consente di trovare efficienza nella progettazione e nella costruzione. Chiunque abbia praticato uno sport o un'attività fisica ti dirà che la ripetizione è la chiave per diventare un buon praticante.

La mia domanda: la possibilità di riutilizzare il software impedisce il necessario miglioramento del processo e l'efficienza derivanti dalla ripetizione di un progetto?

La possibilità di riutilizzare il software non impedisce il miglioramento dei processi.

Se pensi ai processi che vanno alla creazione di software: sviluppo di requisiti, progettazione del sistema, implementazione del sistema, distribuzione del sistema, gestione dei requisiti, gestione delle configurazioni, verifica e convalida del prodotto di lavoro, tracciamento delle modifiche e molti altri (vedi Aree di processo CMMI per una possibile suddivisione delle attività chiave nello sviluppo del software): queste vengono ripetute su ogni progetto indipendentemente da quanto riutilizzi. Inoltre, ognuno ha una sorta di misure quantitative e qualitative che possono essere utilizzate per determinare quanto è buono quel particolare processo o attività e, di conseguenza, quanto è buono il processo di sviluppo nel suo insieme.

In una estremità dell'estremo, possiamo assumere una solida linea di prodotti software. Dall'altro, puoi assumere uno sviluppo greenfield. C'è ancora la necessità di eseguire tutti questi processi, in varia misura, sebbene possano accadere a velocità diverse o forse anche in sequenze diverse. Ad esempio, in un'elevata quantità di riutilizzo, una maggiore percentuale del tempo assegnato può essere impiegata in attività di integrazione e verifica / convalida a livello di sistema (requisiti V&V, test di integrazione, test di sistema, test di accettazione). Con i nuovi sforzi di sviluppo, potrebbe essere necessaria una percentuale maggiore di tempo durante la progettazione e l'implementazione. Finché esegui un processo almeno una volta nel corso di un progetto, puoi misurarlo (quantitativamente e qualitativamente). Dopo aver apportato le modifiche e aver verificato in che modo tali modifiche incidono su una parte dell'area di processo o sulla capacità complessiva di fornire software,

La chiave per migliorare il processo è avere una sorta di suddivisione logica delle attività e dei processi, determinare come misurarli (preferibilmente in modo coerente) e come comprendere tali misurazioni per apportare modifiche al processo verso un certo fine. Non si tratta di ripetere il progetto, ma di coerenza nel modo in cui si ripete il processo.

Penso che l'idea che altre discipline ingegneristiche non facciano uso del riutilizzo sia sbagliata. Anche quando si progettano edifici / macchine, si hanno ancora componenti utilizzati da molti altri progetti. Ad esempio, disegni le tue viti? Motori? Porte o finestre? Ovviamente no. Questi sono spesso progettati da persone diverse che poi li usano in prodotti diversi. E sono abbastanza spesso standardizzati, il che promuove ancora più riutilizzo.

Penso che al problema piaccia la complessità. Semplicemente non è possibile confrontare la complessità anche degli edifici più complessi con software complessi. È un'idea generalmente accettata che la complessità del software sia ciò che rende difficile l'approccio dal punto di vista ingegneristico. Nel momento in cui è in atto un processo che consente di creare software di qualità accettabile, si scopre che la complessità del software necessaria per creare salti in ordine di grandezza. Quindi il processo non può essere utilizzato. Quindi se dovessimo ripetere più volte una parte del software fino a quando non saremo soddisfatti del risultato, non finiremmo mai quel software.

Ecco perché viene promosso il codice pulito. La capacità di cambiare il codice passato in base a nuove esperienze può essere definita come una forma di riutilizzo del design. Quindi, anziché creare più software diversi più volte, rielaboriamo e perfezioniamo un singolo software riutilizzando nuove esperienze e progettando vecchi problemi. Tutto mentre proviamo a fare in modo che il software faccia la stessa cosa.

Il software è diverso dalla maggior parte delle altre discipline, quindi l'economia di dove trascorriamo meglio il nostro tempo è spesso diversa.

Nel settore delle costruzioni, si spende una certa quantità di tempo e denaro per un progetto (e il software è molto più simile alla produzione di un progetto che alla costruzione di un edificio), quindi, in termini approssimativi, molto di più per realizzarlo una o più volte. Quindi vale la pena dedicare parecchio lavoro per ottenere il progetto giusto. Più specificamente alla tua domanda: vale la pena ripetere lo sforzo di farlo da zero per rendere il prodotto finale un po 'migliore.

Nel software, quando hai il progetto, è molto più economico costruire il prodotto di quanto non lo fosse fare il progetto. Almeno la maggior parte delle volte - se il software verrà incorporato in un pacemaker, in qualche modo sei molto più vicino alla situazione di un costruttore di ponti. Ma in generale, il riutilizzo del software potrebbe risparmiare il 90% del costo del più grande elemento di budget, rispetto al 90% di un elemento di budget molto più piccolo per la costruzione di un bridge. Quindi, il riutilizzo vince molto più spesso.

Per quanto riguarda la produttività, quando costruisci, per esempio, un ponte, devi affrontare vincoli del mondo reale davvero significativi. Immagina se agli architetti fossero state pagate ingenti somme di denaro per progettare ponti per giochi online multiplayer di massa, in cui i costi di costruzione erano vicini allo 0 e le limitazioni erano significativamente inferiori rispetto al mondo reale. Progetterebbero ponti che sono stranamente complessi per gli standard dei ponti nel mondo reale. La fase del progetto potrebbe richiedere un po 'più di tempo.

Inoltre, ci sono un numero limitato di ponti da costruire e, poiché il design è una piccola parte del costo, puoi pagare per il meglio e alcuni dei migliori possono fare la maggior parte del design. Esistono centinaia di migliaia di sviluppatori software e praticamente tutti hanno un arretrato gigantesco di cose che farebbero se avessero tempo. Non troverai un ragazzo che fa una parte enorme di tutto ciò - è abbastanza sorprendente che ci siano persone che si avvicinano, davvero.

Il tuo vero punto sembra essere che potremmo perdere qualcosa riutilizzando invece di provare a ripetere e migliorare le cose. Penso che tu abbia un punto. Il problema è che, sebbene molto probabilmente sarebbe più efficiente a livello globale riscrivere alcune delle cose di base e cercare di migliorarle, chiunque se ne accetti ottiene tutti i rischi e probabilmente non molto della ricompensa. (Esiste anche un enorme problema pratico dell'inferno delle dipendenze, che probabilmente toglie un po 'della vittoria dalla riscrittura delle cose, ma non al punto che non varrebbe la pena, almeno guardando il quadro globale. Anche il copyright e i brevetti possono forzare uno sforzo di reingegnerizzazione proposto che morde un bel po 'di lavoro di riscrittura per rifare pezzi più piccoli di codice esistente).

In termini di apprendimento da ripetizione - in tutte le discipline questo accade meno nella progettazione che nella costruzione, perché non v'è meno ripetizioni, quindi meno possibilità di imparare, e forse meno beneficio. Inoltre, il processo di progettazione probabilmente non è così ripetibile. È un po 'come avere un processo per scrivere un romanzo. Un buon processo può quasi certamente aiutare, e il software è generalmente molto più collaborativo di un romanzo, ma ripetere un processo quando l'obiettivo è quello di inventare qualcosa di nuovo è problematico. Perfino i romanzieri imparano molto dal passato, ma un processo ripetibile è un fattore secondario per gli sforzi creativi. E se qualsiasi parte dello sviluppo del software è veramente ripetibile, perché un computer non lo sta facendo?

La capacità del software di essere riutilizzato impedisce il necessario miglioramento del processo e l'efficienza derivanti dalla ripetizione di un progetto?

Ho lavorato come ingegnere di sistemi e software nello stesso grande progetto negli ultimi 17 anni, per inciso (pensando al riferimento Airbus A380 nel tuo primo collegamento) nel settore aeronautico, sebbene le mie responsabilità ricadano nel settore degli aerei militari. Storie come questa sono fondamentalmente pura finzione e in realtà sono davvero divertenti da guardare quando si ha una visione approfondita.

Ma per la tua breve e concisa domanda: dalla mia esperienza, direi sia sì che no.

Vorrei prima dire che sono tutto per il riciclaggio del software in tutte le forme (beh, forse non tutti ...). I vantaggi del riutilizzo di qualsiasi cosa, dai frammenti di codice e dagli algoritmi di codice, agli interi moduli di codice e alle librerie di funzioni, è nel complesso molto meglio che ricominciare sempre dall'inizio (per spingerlo un po ').

L'aspetto negativo è, come fai notare (o almeno inferire), che quando aggiungi funzionalità semplicemente mettendo insieme un determinato set di componenti (e, sì, lo sto semplificando all'estremo), non ti evolvi davvero come programmatore, ingegnere o altro.

Solo guardando gli ingegneri del software intorno a me al lavoro, so da una lunga esperienza che la maggior parte di loro non lo sa, e peggio ancora - non ha interesse per l'apprendimento, qualsiasi cosa sul prodotto che stiamo costruendo oltre al minimo indispensabile che devono produrre il documento o il pezzo di codice a cui sono assegnati.

Sto trattando un po 'fuori tema qui, ma il mio punto è che quando i programmatori non hanno bisogno di imparare per cosa verrà realmente utilizzato il codice che stanno costruendo, e non hanno bisogno di imparare il funzionamento interno del sistema poiché possono semplicemente riutilizzare componenti già scritti e testati, quindi la maggior parte di essi non si preoccuperà di farlo.

Certo, ciò è dovuto anche ad altre circostanze, come il fatto che il prodotto che stiamo costruendo è incredibilmente complesso, e sarebbe impossibile per una persona apprenderne tutto (e sto solo parlando di uno dei computer nell'aereo - il più complesso, ma comunque).

Se i nostri ingegneri del software non avessero la possibilità di riutilizzare tanto codice, sono convinto che sarebbero diventati migliori nella loro professione in generale, e risorse molto più grandi per il progetto in particolare.

Oh, e avrete notato che parlo di loro molto qui. Naturalmente sono anche incluso tra questi ingegneri del software. L'eccezione è che sembro essere molto più curioso e desideroso di imparare cose nuove rispetto alle altre :-) Quando mi trovo di fronte a un nuovo compito, mi prendo sempre su me stesso di imparare tutto ciò che posso, sia nel forma di fatti e studiando il codice sorgente (sì, mi piace anche quello).

Ah - dang, di nuovo in disparte ... La mia scusa è che non ho dormito per 32 ore, quindi la mia capacità di concentrazione è un po '... cosa stavo dicendo?

Se qualcuno sta ancora leggendo, la mia conclusione è che:

Sì , un riutilizzo eccessivo del software rende gli ingegneri del software meno esperti, il che li rende notevolmente meno efficienti quando hanno effettivamente bisogno di sapere come funzionano le cose. L'analisi dei problemi è un buon esempio o anche solo essere in grado di dire se una soluzione di progettazione suggerita è praticabile. E, naturalmente, anche il miglioramento dei processi è più difficile da ottenere quando non sai davvero cosa stai facendo :-)

e No , il riutilizzo del software con cura , potenzialmente ti dà molto tempo libero per considerare e pianificare i miglioramenti del processo.

Come sottolineato nella risposta accettata in un'altra domanda dei programmatori, le analogie con la costruzione devono essere prese con cura:

una lettura consigliata per questo è The Software Construction Analogy is Broken

il software è spesso paragonato alla costruzione. Sfortunatamente questa analogia è imperfetta e le lezioni apprese dall'industria delle costruzioni sono sospette ...

Quello che ho osservato è che i buoni progetti software "spostano" molta ripetibilità in garanzia di qualità.

Quando ero un tester in un progetto della durata di 1,5 anni, eseguiamo cicli di test con rilasci settimanali di "checkpoint", circa 70 volte totali nel progetto. Era ... abbastanza ripetibile, a bassa voce (non cambiano molte cose in una settimana). Il test delle build notturne è stato, naturalmente, ancora più ripetibile - circa 500 volte nel corso del progetto (alcuni bug divertenti di showstopper erano troppo rari per fare la differenza).

Ora, seguendo quell'analogia "sospetta", dimmi una società di costruzioni che ha costruito 500 ponti, tutti con lo stesso team.

• Seguendomi ulteriormente, dimmi una società che ha utilizzato principalmente gli stessi mattoni e ferro in ciascuno dei loro nuovi ponti (qui, mi riferisco al fatto che le versioni che abbiamo testato avevano principalmente gli stessi frammenti di codice giorno per giorno, settimana da settimana - "non cambiano molte cose").
  

I costruttori principali sono esperti riconosciuti per aver progettato e / o costruito decine, centinaia o migliaia di cose nella loro area.

Bene, seguendo la tua spiegazione della ripetibilità citata sopra, posso dire cosa? Allora, il nostro piccolo gruppo non molto speciale di tester ha verificato, vedi sopra ("circa 500") centinaia di cose nella nostra zona.

Per quanto riguarda gli sviluppatori di progetti, hanno letteralmente costruito ("build notturne") - vedi, la parola è la stessa, e il significato è giusto in questo contesto - centinaia di cose nella loro area.

Se si vuole continuare quell'analogia "sospetta" fino a "migliaia di cose", queste quantità non sono, di nuovo, nulla di spettacolare nello sviluppo del software quando si guardano le cose giuste.

• Ad esempio, l'ennesimo dei miei progetti passati (ancora una volta, niente di spettacolare, piuttosto regolare), questa volta nel ruolo di sviluppatore, è andato avanti per più di 5 anni (8 versioni principali, diverse decine di minori). C'erano checkpoint settimanali simili ( 5x52~=250di loro), rilasci notturni simili ( 5x365~=1800di loro) e allo stesso modo, stessi team di sviluppo / controllo qualità che lavoravano su questi. Giorno per giorno, settimana per settimana, mese per mese, roba per lo più ripetitiva (non molto cambiamento tra due build notturne) - come promesso, nel range di migliaia di volte (1800).

I progetti più longevi come Windows o Java o AutoCAD possono durare 10, 20, 30 anni, il che spiega facilmente la ripetizione di quante "migliaia" build notturne e test notturni.

Il concetto di spostamento della ripetibilità al QA diventa ancora più evidente con l' integrazione continua ...

la pratica ... di unire tutte le copie di lavoro degli sviluppatori con una linea principale condivisa più volte al giorno ... L'IC può essere vista come un'intensificazione delle pratiche di integrazione periodica.

Oltre ai test unitari automatizzati, le organizzazioni che utilizzano CI utilizzano in genere un server di build per implementare processi continui di applicazione del controllo di qualità in generale - piccoli sforzi, applicati frequentemente. Oltre all'esecuzione dell'unità e ai test di integrazione, tali processi eseguono ulteriori test statici e dinamici, misurano e profilano le prestazioni, estraggono e formattano la documentazione dal codice sorgente e facilitano i processi di controllo qualità manuale. Questa continua applicazione del controllo di qualità mira a migliorare la qualità del software e a ridurre i tempi di consegna, sostituendo la pratica tradizionale di applicare il controllo di qualità dopocompletando tutto lo sviluppo. Questo è molto simile all'idea originale di integrare più frequentemente per facilitare l'integrazione, applicata solo ai processi di controllo della qualità ...

Ripetibilità? è proprio lì, tanto quanto si può pensare.

Con il QA frequente / continuo, le cose che vanno male tornano rapidamente agli sviluppatori che sono costretti a ripetere i tentativi di farlo correttamente fino a quando i test falliti passano con successo. In un certo senso, quel ciclo di ripetizione fino a quando non assomiglia al codice cata ,

un esercizio di programmazione che aiuta un programmatore ad affinare le proprie abilità attraverso la pratica e la ripetizione ...

Parte di ciò che dici è vero: ad esempio le biblioteche risolvono funzioni non risolte da linguaggi di alto livello che risolvono problemi non risolti dall'assemblaggio che risolvono problemi non risolti dal codice macchina. Quando chiami System.out.println () in Java stai perdendo di vista il modo in cui una CPU emette su un dispositivo.

Quindi sì, stai perdendo qualcosa. Ciò che ottieni è la capacità di concentrarti su problemi irrisolti. Ora potrebbe essere necessario immergersi in alcuni altri aspetti della tecnologia (ad esempio come funzionano le reti) per risolvere un problema. Ma non devi diventare un esperto nella lettura del linguaggio macchina quando tutto ciò che vuoi fare è costruire una pagina web.

Allo stesso modo, i costruttori di ponti risolvono ogni volta un problema leggermente diverso (è un fiume diverso). Non si preoccupano di come creare travi di acciaio con una certa resistenza alla trazione o di come lavorare i bulloni con una certa tolleranza. Lo lasciano agli specialisti che hanno risolto quel problema.

Osserva attentamente e vedrai che l'intera nostra società e infrastruttura sono costruite sul riutilizzo del 99% e solo sull'1% di progressi reali. La maggior parte delle cose nuove sono solo cose vecchie con qualcosa in più aggiunto o rimosso. È l'accumulo di conoscenza umana. Puoi scrivere codice in un linguaggio di alto livello con librerie decenti perché qualcuno ha capito tutte le cose incredibilmente complicate necessarie per arrivare a questo punto. Ti consente di risolvere problemi nuovi e interessanti.

Per legare tutto insieme e rispondere ai commenti: non è necessario risolvere i problemi che sono già stati risolti per sviluppare competenza. Inoltre, molto di ciò che fai reinventerà la ruota. Quindi, in breve, la risposta è no: non è necessario implementare nuovamente le funzioni delle biblioteche per diventare competenti. Ci sono molte opportunità, alcune delle quali sono vere, altre sono creative per affinare il tuo mestiere.

Si tratta di risorse. Anni fa, se sviluppaste progetti software per computer mainframe di grandi dimensioni, potrebbero essere in circolazione per circa 15 anni con un ambiente di sviluppo in gran parte statico. Il programma FORTRAN scritto per calcolare il libro paga o il programma COBOL è stato perfezionato nel corso di decenni perché è stato costantemente utilizzato. C'erano risorse per vedere come questo potesse essere migliorato. Non abbiamo più quel tipo di ambiente lento per mettere a punto e perfezionare le competenze per un progetto specifico. Ma prendiamo le competenze e le adattiamo alle risorse del prossimo progetto permettendo. Ma alla fine diventa una scelta di denaro speso per il nuovo progetto per fare il lavoro, o per fare il nuovo lavoro con una grande quantità di dorature. Placcare in oro un progetto significa migliorarlo all'ennesima potenza e aggiungere un sacco di campane e fischietti anche se l'utente non lo ha fatto

Il meglio che possiamo fare è guardare alla progettazione complessiva di un nuovo progetto e vedere come può essere migliorato sulla base dell'esperienza passata del team. Ma ci vuole una vera esperienza architetto del software per avere una visione di ciò che è effettivamente considerato migliorare il design per migliorare le competenze vs semplicemente racchiudere l'ultima parola d'ordine in sviluppo come Agile, OOP, ecc.