Il riutilizzo del software preclude la ripetibilità del processo

La possibilità di riutilizzare il software non impedisce il miglioramento del processo.

Se pensi ai processi che portano alla creazione di software: requisiti di sviluppo, progettazione del sistema, implementazione del sistema, implementazione del sistema, gestione dei requisiti, gestione delle configurazioni, verifica e validazione del prodotto di lavoro, monitoraggio delle modifiche e un numero di altri (vedi le aree di processo CMMI per una possibile suddivisione delle attività chiave nello sviluppo del software) - queste sono ripetute su ogni progetto indipendentemente da quanto riutilizzo hai. Inoltre, ciascuno di essi ha una sorta di misure quantitative e qualitative che possono essere utilizzate per determinare quanto sia buono quel particolare processo o attività e, di conseguenza, quanto è buono il processo di sviluppo nel suo insieme.

In un'estremità estrema, possiamo assumere una robusta linea di prodotti software . Dall'altro, puoi assumere lo sviluppo di campi verdi. C'è ancora bisogno di eseguire tutti questi processi, a vari livelli, anche se possono accadere a velocità diverse o forse anche in sequenze diverse. Ad esempio, in una quantità elevata di riutilizzo, una percentuale maggiore del tempo assegnato può essere spesa per attività di integrazione e verifica / convalida a livello di sistema (requisiti V e amp; V, test di integrazione, test di sistema, test di accettazione). Con i nuovi sforzi di sviluppo, una maggiore percentuale del tempo può essere richiesta in fase di progettazione e implementazione. Finché esegui un processo almeno una volta durante il corso di un progetto, puoi misurarlo (quantitativamente e qualitativamente). Una volta apportate le modifiche, è possibile osservare in che modo tali rettifiche influiscono su una certa misura dell'area del processo o sulla capacità complessiva di fornire software e quindi affinare il processo per altri progetti.

La chiave per elaborare il miglioramento consiste nell'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 la 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 riuso è sbagliata. Anche quando progetti edifici / macchine hai ancora componenti usati da molti altri progetti. Ad esempio, progetti 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 standardizzati, che promuove ancora più riutilizzo.

Penso che il problema piaccia nella complessità. Semplicemente non è possibile confrontare la complessità degli edifici più complessi con quelli di software complessi. È un'idea generalmente accettata che la complessità del software è ciò che rende difficile l'approccio dal lato dell'ingegneria. Nel momento in cui hai un processo che ti consente di creare software di qualità accettabile, scopri che la complessità del software necessario per creare salti in ordine di grandezza. Quindi il processo non può essere utilizzato. Quindi, se dovessimo ripetere una parte del software più volte fino a quando non saremmo soddisfatti del risultato, non avremmo mai finito quel software.

Ecco perché viene promosso il codice pulito. La capacità di cambiare il codice passato in base a nuove esperienze può essere considerata una forma di riutilizzo del design. Quindi, invece di creare software diversi più volte, noi rifattiamo e perfezioniamo un singolo software riutilizzando nuove esperienze e progettiamo su vecchi problemi. Tutto ciò mentre cerchi di fare del software la stessa cosa.

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

Nel settore delle costruzioni, trascorri una certa quantità di tempo e denaro su un progetto (e il software è lontano più come produrre un progetto che come costruire un edificio), quindi, grosso modo, un intero lotto di più su come costruirlo effettivamente una o più volte. Quindi vale la pena di mettere un bel po 'di lavoro per ottenere il progetto giusto. Più precisamente alla tua domanda: vale la pena ripetere lo sforzo di farlo da zero per rendere il prodotto finale un po 'migliore.

Nel software, quando si ha il progetto, è molto più economico costruire il prodotto di quanto non fosse per realizzare il progetto. Almeno il più delle volte - se il software sarà incorporato in un pacemaker, in qualche modo sarai molto più vicino alla situazione di un costruttore di ponti. Ma in generale, riutilizzare il software potrebbe far risparmiare il 90% del costo del tuo articolo di budget più grande, rispetto al risparmio del 90% di un elemento di budget molto più piccolo per la costruzione di un ponte. Quindi, riutilizzare vince molto più spesso.

Per quanto riguarda la produttività - quando costruisci, ad esempio, un ponte, affronti dei limiti davvero reali. Immaginate se gli architetti fossero pagati ingenti somme di denaro per progettare ponti per enormi giochi online multiplayer, dove i costi di costruzione erano vicini a 0 e la limitazione era significativamente inferiore al mondo reale. Progetterebbero ponti che sono stranamente complessi secondo gli standard del bridge del mondo reale. La fase blueprint potrebbe richiedere più tempo.

Inoltre, ci sono un numero limitato di ponti da costruire e, dal momento che il design è una parte marginale del costo, puoi pagare per il meglio, e alcuni dei migliori possono fare la maggior parte del design. Ci sono centinaia di migliaia di sviluppatori di software, e fondamentalmente tutti hanno un enorme arretrato di cose che farebbero se avessero tempo. Non troverai un ragazzo che faccia una parte enorme di tutto questo - è piuttosto sorprendente che ci siano persone che si avvicinano, davvero.

Il tuo vero punto di vista 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 anche se sarebbe probabilmente più efficiente a livello globale per riscrivere alcune delle cose fondamentali e provare a migliorarlo, chiunque lo faccia subisce tutti i rischi e probabilmente non gran parte della ricompensa. (C'è anche un enorme problema pratico dell'inferno delle dipendenze, che probabilmente richiede un po 'di vittoria per riscrivere le cose, ma non al punto che non varrebbe la pena, almeno guardando al quadro globale. forzare uno sforzo di reingegnerizzazione proposto mordere un bel po 'di lavoro di riscrittura per rifare pezzi più piccoli di codice esistente).

In termini di apprendimento dalla ripetizione - in tutte le discipline ciò accade meno nel design che nella costruzione, perché c'è è meno ripetizione, quindi meno possibilità di imparare e forse meno benefici. Inoltre, il processo del design 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 è inventare qualcosa di nuovo è problematico. Persino i romanzieri imparano dal passato, molto spesso, ma un processo ripetibile è un fattore secondario per gli sforzi creativi. E se qualche parte dello sviluppo del software è veramente ripetibile, perché non lo fa un computer?

Does software’s ability to be reused prevent the necessary process improvement and efficiency that comes from repeating a project?

Ho lavorato come ingegnere di sistemi e software nello stesso grande progetto negli ultimi 17 anni, incidentalmente (pensando al riferimento Airbus A380 nel tuo primo link) nell'industria aeronautica, sebbene le mie responsabilità siano nel settore degli aerei militari . Storie del genere sono fondamentalmente pura finzione, e in realtà è davvero divertente da guardare quando si hanno informazioni interne.

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

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

Il rovescio della medaglia è, come tu fai notare (o almeno deduci), che quando aggiungi funzionalità semplicemente mettendo insieme un dato insieme di componenti (e, sì, sto semplificando questo fino all'estremo), non lo fai davvero evolvi come programmatore, ingegnere o qualsiasi altra cosa.

Solo guardando gli ingegneri del software intorno a me al lavoro, so per esperienza che una maggioranza di loro non sa, e peggio - non ha interesse nell'apprendimento, nulla del prodotto che stiamo costruendo a parte il minimo indispensabile è necessario produrre il documento o il pezzo di codice che sono assegnati a fare.

Mi sto muovendo un po 'fuori tema qui, ma il mio punto è che quando i programmatori non hanno bisogno di per sapere che il codice che stanno costruendo sarà usato per davvero, e non è necessario per apprendere i meccanismi interni del sistema poiché possono solo riutilizzare componenti già scritti e testati, quindi la maggior parte di loro non si preoccuperà di farlo.

Certo, questo è anche dovuto ad altre circostanze, come ad esempio che il prodotto che stiamo costruendo è incredibilmente complesso, e sarebbe impossibile per una persona conoscere tutto (e sto solo parlando di uno dei computer in l'aereo - il più complesso di loro, ma ancora).

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

Oh, e potresti aver notato che parlo di loro molto qui. Sono ovviamente incluso anche tra questi ingegneri del software. L'eccezione è che mi sembra di essere molto più curioso e desideroso di imparare cose nuove da quelle degli altri :-) Di fronte a un nuovo compito, mi prendo sempre su di me per imparare tanto su di esso che posso, sia nel forma di fatti e studiando il codice sorgente (sì, mi piace anche quello).

Ah - dang, di nuovo tracciato di lato ... La mia scusa è che non ho dormito per 32 ore, quindi la mia capacità di messa a fuoco è un po '... cosa stavo dicendo?

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

Sì , un eccessivo riutilizzo del software rende meno ingegnosi gli ingegneri del software, il che li rende notevolmente meno efficaci 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, il miglioramento dei processi è anche più difficile da raggiungere quando non sai veramente cosa stai facendo: -)

e No , riutilizzando il software con attenzione , ti offrono potenzialmente molto tempo libero per prendere in considerazione e pianificare i miglioramenti del processo.

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

a recommended reading for this is The Software Construction Analogy is Broken

software is often likened to construction. Unfortunately this analogy is flawed and lessons learned from the construction industry are suspect...

Ciò che ho osservato è che i buoni progetti software "spostano" molta ripetibilità nell'assicurazione della qualità.

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

Ora, seguendo l'analogia "sospetto", dimmi una società di costruzioni che ha costruito 500 ponti, tutti con la stessa squadra.

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

Master builders are experts recognized for having designed and / or built tens, hundreds, or thousands of things in their area.

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

Come per gli sviluppatori di progetto, hanno letteralmente costruiti ("build notturne") - vedi, la parola è la stessa, e il significato è giusto in questo contesto - centinaia di cose nella loro area.

Se si vuole continuare questa "sospetta" analogia fino a "migliaia di cose", questi importi non sono, ancora una volta, niente di spettacolare nello sviluppo del software quando si guardano le cose giuste.

• Ad esempio, un altro dei miei progetti precedenti (ancora, niente di spettacolare, piuttosto regolare), questa volta in ruolo di dev, è in corso da più di 5 anni (8 versioni principali, diverse dozzine minori). C'erano checkpoint settimanali simili ( 5x52~=250 di loro), uscite notturne simili ( 5x365~=1800 di loro) e allo stesso modo, gli stessi team di sviluppo / QA che lavorano su questi. Giorno per giorno, settimana per settimana, mese per mese, roba per lo più ripetitiva (non molti cambiamenti tra due build notturne) - come promesso, nel raggio di migliaia di volte (1800).

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

Il concetto di spostamento della ripetibilità verso il controllo qualità diventa ancora più importante con Integrazione continua ...

the practice... of merging all developer working copies with a shared mainline several times a day... CI can be seen as an intensification of practices of periodic integration..

In addition to automated unit tests, organisations using CI typically use a build server to implement continuous processes of applying quality control in general — small pieces of effort, applied frequently. In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes. This continuous application of quality control aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. This is very similar to the original idea of integrating more frequently to make integration easier, only applied to QA processes...

La ripetibilità? è proprio lì, in gran parte come si può pensare.

Con un QA frequente / continuo, le cose che vanno storte tornano rapidamente agli sviluppatori che sono costretti a ripetere i tentativi di farlo correttamente fino al superamento dei test. In un certo senso, quel ciclo di che si ripete fino a quando non passa ricorda codice cata ,

an exercise in programming which helps a programmer hone their skills through practice and repetition...

Alcuni di ciò che dici è vero: ad es. le librerie risolvono funzioni non risolte da linguaggi di alto livello che risolvono problemi non risolti dal montaggio 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 concentrarsi su problemi irrisolti. Ora può darsi che sia necessario immergersi in alcuni altri aspetti della tecnologia (ad es. Come funzionano le reti) per risolvere un problema. Ma non è necessario diventare esperti nella lettura del linguaggio macchina quando tutto ciò che si vuole fare è costruire una pagina web.

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

Guarda attentamente e vedrai che tutta la nostra società e le nostre infrastrutture sono costruite con il 99% di riutilizzo e solo l'1% di progressi effettivi. La maggior parte delle cose nuove sono solo vecchie cose con qualcosa in più aggiunto o rimosso. È l'accumulo di conoscenza umana. Puoi scrivere il codice in un linguaggio di alto livello con librerie decenti perché qualcuno ha capito tutte le cose complicate che sono necessarie per arrivare a questo punto. Ti permette di risolvere problemi nuovi e interessanti.

Legare tutto questo insieme e rispondere ai commenti: non è necessario risolvere i problemi che sono già stati risolti per sviluppare le competenze. Inoltre, molto di ciò che fai sarà reinventare la ruota. Quindi, in breve, la risposta è no - non è necessario ri-implementare le funzioni delle biblioteche per diventare abili. Ci sono molte opportunità, alcune delle quali sono meccaniche, alcune sono creative per perfezionare il tuo mestiere.

Si tratta di risorse. Anni fa, se hai sviluppato progetti software per computer mainframe di grandi dimensioni, potrebbero trovarsi in giro per 15 anni circa con un ambiente di sviluppo sostanzialmente statico. Il programma FORTRAN scritto per calcolare il libro paga o il programma COBOL è stato perfezionato nel corso dei decenni perché era costantemente utilizzato. C'erano risorse per vedere come questo potesse essere migliorato. Non abbiamo più quel tipo di ambiente lento per perfezionare 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 doratura. Placcare in oro un progetto significa migliorarlo all'ennesima potenza e aggiungere un sacco di campane e fischietti anche se l'utente non l'ha chiesto espressamente.

Il meglio che possiamo fare è guardare la progettazione generale di un nuovo progetto e vedere come può essere migliorato sulla base dell'esperienza passata del team. Ma ci vuole un vero e proprio architetto software per avere una visione di ciò che è effettivamente considerato migliorando il design per migliorare le competenze, semplicemente mettendo in pratica l'ultima parola chiave in sviluppo come Agile, OOP, ecc.