Comunicazioni riguardanti la manutenibilità del codice [duplicato]

6

Sono alla ricerca di buon linguaggio o metafore per discutere della manutenibilità del codice con persone non tecniche (PM, business sponsor e c).

In particolare, di recente ho creato alcuni pezzi di codice una tantum, meritatissimi, stasera e fatti sul posto di lavoro. Tutti, incluso lo sponsor interno, sapevano che stavamo salvando un paio d'ore basandoci sul presupposto che il codice sarebbe stato usato una volta, per il bisogno immediato, e non ancora.

Quindi l'inevitabile: "Ehi, ricorda quella cosa che abbiamo fatto? Facciamolo di nuovo, ma con questi piccoli cambiamenti". Ovviamente, i cambiamenti minori non sono così trascurabili, tanto più che il codice è stato scritto come una grande cattiveria procedurale incentrata su ipotesi sull'ambiente. [Sì, sì, lo so, evitare il problema, in primo luogo. Non scrivere codice cattivo. Scrivi tutto come se fosse mantenuto da qualcun altro, o da me da anni. Questa è una domanda diversa, però. Questo è dopo che è successo.]

Quindi quali sono alcune buone metafore per lo sponsor interno (non tecnico) per spiegare rapidamente perché il codice non è di manutenzione o di lieve modifica? Le pareti di un set cinematografico: non c'è un garage lì, è solo una porta. - oppure - Le porte sono saldate chiuse su questa macchina.

Come descrivi questo continuum?

Voglio trovare alcuni termini per il nostro gruppo che ti aiutino a parlare di quanto impegno ci sia in avanti e in che modo migliorerà la manutenibilità: illustrando i compromessi in "Vuoi questo stasera o vuoi mantenerlo? "

(nello scrivere questo, mi rendo conto che potrebbe essere lo stesso che definire "mantenibile" per gli stakeholder non tecnici. Sembra come spiegare allentamento dell'accoppiamento a tipi non tecnici potrebbe non essere la soluzione migliore. Se l'hai fatto con successo, come?)

Modificato per la risposta: Per ora continuerò a usare le metafore dell'edilizia. Questo si trasformerà nelle dimensioni e nella forza della fondazione: "Sì, possiamo costruire questo edificio su questo, ma dovremo rielaborare le fondamenta per essere più grandi e coprire l'area giusta".

    
posta Jamie F 29.02.2012 - 23:50
fonte

4 risposte

6

Le metafore di costruzione sono spesso utili quando si spiegano concetti di software a persone non tecniche.

Si può dire, ad esempio, "Questo codice era così strutturato da una giuria, era come usare un 2x4 per aprire la porta del garage invece di installare un apriporta da garage adeguato."

Le metafore costruttive si prestano bene a un continuum di spiegazioni.

    
risposta data 01.03.2012 - 01:22
fonte
13

Qui prova questo, lavora per i miei studenti tutto il tempo:)

Porta un pacchetto di spaghetti alla riunione (non cotti) e chiedi loro di rimuovere un singolo noodle o multipli. È facile.

Ora prendine una cotta o semplicemente "scarica i crudi" sul tavolo e chiedi loro di scegliere qualcosa senza disturbare l'ambiente (o nel caso di quello cotto, tracciare il suo inizio / fine).

Questo di solito arriva a casa: gli spaghetti non cotti sono ben architettati, separati dalle preoccupazioni, puliti e richiedono uno sforzo per farlo (pensate al processo di produzione).

Quest'ultimo, basta scaricare in una padella per cucinare o sul tavolo, veloce da fare ma un incubo per passare da in seguito.

Da qui il termine "codice spaghetti":)

    
risposta data 01.03.2012 - 02:46
fonte
5

Pensa a oggetti di uso quotidiano con interfacce ben definite che lo rendono facilmente sostituibile, come una lampadina o una batteria. Spiega che le primissime luci elettriche costruite da Edison non avevano lampadine avvitate, perché era più veloce collegare il bulbo direttamente durante la progettazione piuttosto che dedicare più tempo a progettare una presa a vite. Gli zoccoli sono stati sviluppati in seguito quando è stato necessario sostituire frequentemente i bulbi.

Il software è lo stesso. Ci sono modi per "collegare direttamente" alcune cose in modo da renderle più veloci da sviluppare, ma anche rendere più difficile la sostituzione di parti di esso. Se vuoi apportare molte modifiche in un secondo momento, devi prima progettare la "presa a vite", quindi il resto sarà più veloce e facile da cambiare.

    
risposta data 01.03.2012 - 14:36
fonte
3

Parlerei in termini di "debito tecnico" per questo, soprattutto se si parla di parti interessate come clienti o dirigenti che hanno un orecchio per le preoccupazioni della finanza. Prendere decisioni sbagliate o generare lavori sciatti è come stipulare prestiti con tassi di interesse.

    
risposta data 29.02.2012 - 23:57
fonte

Leggi altre domande sui tag