Come migliorare la formazione degli studenti per quanto riguarda la manutenibilità? [chiuso]

La manutenibilità è una parte importante dello sviluppo di software professionale. In effetti, la manutenzione è quasi sempre la parte più lunga di un ciclo di vita del software, poiché dura dal rilascio del progetto fino alla fine dei tempi.

Inoltre, i progetti in manutenzione rappresentano una grande maggioranza del numero complessivo di progetti. Secondo http://www.vlegaci.com/298/interesting-statistics-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/ , la percentuale di progetti in manutenzione è di circa 2 / 3.

Di recente mi sono imbattuto in questa domanda , in cui il ragazzo sembra piuttosto sorpreso scoprendo che il suo lavoro riguarda principalmente la manutenzione. Ho quindi deciso di aprire una discussione (in francese) sul sito principale della comunità francese di professionisti dello sviluppo software ( http://www.developpez.com/ ). La discussione si intitola "Gli studenti sono abbastanza preparati alla realtà dello sviluppo di software professionale?" e riguarda principalmente la manutenibilità . È stato sottolineato che, almeno in Francia, le persone non sono abbastanza preparate per affrontare la manutenzione in entrambi gli aspetti:

• mantenere il codice esistente
• rendere il codice gestibile

La mia domanda qui fa eco a questa discussione e mira a trovare un buon modo per insegnare la manutenibilità.

• Come possiamo insegnare la manutenibilità?
• Che tipo di esercizio suggeriresti?
• Se sei stato ben addestrato per quanto riguarda la manutenibilità, quale particolare tipo di corsi hai seguito?

[modifica] Dopo alcuni fraintendimenti, penso di dover chiarire la mia domanda. Come capo progetto e sviluppatore di software, lavoro spesso con tirocinanti o studenti appena laureati. Una volta mi ero appena laureato. Il fatto è che gli studenti di solito non hanno familiarità con principi come SOLID che aumentano la manutenibilità di un progetto. Spesso finiamo per avere importanti difficoltà a far evolvere i progetti (bassa manutenibilità). Quello che sto cercando qui è un esempio accademico concreto di insegnamento di successo sull'importanza della manutenibilità e su come rendere il codice migliore riguardo a questo particolare punto; o possibili suggerimenti per migliorare il modo in cui gli studenti vengono formati.

Come possiamo insegnare la manutenibilità?

Questa è una questione di pratica.

Il modo più semplice di praticarlo in modo controllato a cui riesco a pensare è simulare il tipico progetto di manutenzione come segue.

Ottieni un progetto ( Progetto A ) ben fatto e introduci alcuni problemi su di esso: inietta alcuni bug, una buona dozzina di codice duplicato e morto, rilascia alcune funzioni, test unitari e documentazione qua e là ecc. Potresti anche avere un dedicato nome per questo, come Progetto A - versione danneggiata .

Stabilisci un tracker di problemi e riempilo di richieste corrispondenti a danni particolari che hai fatto. Stabilisci regole e pratiche di base per il processo di sviluppo - impegni VCS, revisioni del codice, QA ecc. - considera di prendere ciò che puoi dall'elenco di controllo fornito in The Joel Test .

• corsi 1.
  Correggere i bug, aggiungere test unitari mancanti, documentazione e caratteristiche.
• corsi 2.
  Refactor.
• corsi 3.
  Manutenzione / miglioramento di progetti originali che gli studenti del prossimo anno potranno utilizzare
  - Progetto A versione 2.0 e Progetto A - versione danneggiata , rispettivamente.
  _{Migliorando la versione danneggiata intendo farne un danno educativo migliore. :)}

Delle pratiche sopra menzionate, presta particolare attenzione a quella delle revisioni del codice . Questo è probabilmente il modo più efficace per garantire che il codice sia facile da mantenere, come indicato ad esempio dalla risposta principale nella domanda correlata .

Disclaimer: ho appena ottenuto il mio diploma CS. Io non sono un insegnante.

Questo può sembrare ovvio, ma penso che il modo migliore per insegnare la manutenzione del codice sia far eseguire agli studenti la manutenzione del codice. Ecco cosa farei:

1. Prendi un problema moderatamente complesso e due implementazioni semanticamente identiche, ma una è molto più gestibile dell'altra.
2. Richiedi una serie di modifiche / aggiunte di funzionalità che sono molto più facili da implementare sulla base di codice migliore. La metà degli studenti deve implementarli sulla base di codice più gestibile, l'altra metà su quella meno gestibile.
3. Per motivi di equità, potresti voler ripetere questo esercizio con i ruoli invertiti.
4. Confrontare il numero medio di modifiche implementate con successo tra le basi di codice buono e cattivo e il tempo impiegato per implementarle. Chiedi agli studenti di condividere le loro esperienze, di esprimere le loro lamentele e di parlare semplicemente del lavoro svolto.

L'idea è non solo di far lavorare gli studenti con il codice di qualcun altro, ma anche di farli apprezzare per il codice gestibile che, si spera, migliorerà le loro capacità di progettazione.

La manutenibilità è una virtù, non un'abilità. Esistono molti percorsi per creare progetti sostenibili, ma nessuna formula è garantita per produrli.

Se apprezzi le virtù come la gentilezza e la generosità, cerchi modi per praticare lo stesso nella tua vita quotidiana. Lo stesso vale per la manutenibilità: se tu e la tua organizzazione apprezzate la manutenibilità, la manterrete nella parte posteriore della mente durante la progettazione e l'implementazione del progetto. Sarà un motivo legittimo per dedicare un po 'di tempo extra alla costruzione di qualcosa perché sai che la manutenibilità è apprezzata. Al contrario, è scoraggiato passare del tempo extra per motivi di manutenibilità in un'organizzazione che non lo valorizza.

Se vuoi insegnare alle persone a rendere le cose mantenibili, dovresti iniziare chiarendo che la tua organizzazione apprezza la manutenibilità. Specificalo nei requisiti per i tuoi progetti. Rendilo uno dei criteri per la revisione del codice. In breve, fai della manutenibilità parte della tua cultura .

Successivamente, sii disposto a dedicare alcune risorse per migliorare la manutenibilità nei tuoi progetti esistenti. Identificare le parti di un progetto in cui i bug continuano a spuntare, o dove correggerli o apportare modifiche è molto difficile e richiede molto tempo e riprogettare o refactoring per facilitare la manutenzione.

Infine, indottrina i nuovi sviluppatori nella tua cultura della manutenibilità assegnandoli a team che già lo praticano quotidianamente. Non c'è modo migliore per aiutare qualcuno ad adottare un valore se non quello di fornire loro molti buoni esempi e indicazioni.

Non mi piace il termine Manutenzione in relazione allo sviluppo del software. La realtà è che tutto il software è gestibile in quanto può essere soggetto a lavori di manutenzione, quindi il vero problema è se il software è costoso o economico da mantenere, relativamente parlando. So che suona come una dichiarazione molto pedante da fare all'inizio di una risposta, tuttavia il mio punto diventerà più chiaro in un momento.

Il problema con i gradi IT che sono importanti nello sviluppo del software è che insegnano agli studenti solo il minimo indispensabile che gli studenti devono sapere sulla scrittura del software. Le competenze e le conoscenze professionali vengono acquisite attraverso l'apprendimento che viene svolto nei primi anni successiviqualificarsi per la laurea. Questo è quando un laureato inizia a lavorare su progetti che contano davvero per un cliente, in un ambiente in cui vi è una forte pressione da eseguire e l'aspettativa è quella di creare un prodotto secondo uno standard professionale. Purtroppo, molte aziende non incoraggiano una cultura in cui vengono mantenuti gli standard professionali nel software e finiscono con progetti che risultano costosi da sviluppare e mantenere come risultato. Sfortunatamente per i nostri laureati, imparano molte cattive abitudini in tali ambienti nei primi anni della loro carriera, e può passare molto tempo prima che imparino a superare queste abitudini ... se non del tutto.

Faresti meglio a insegnare agli studenti come scrivere codice pulito e come identificare i problemi nel software che di solito finiscono con l'insorgere di un debito tecnico . Cerca nei libri su Clean Code , Refactoring e Lean Software Development come punto di partenza come punto di partenza e insegna agli studenti a scrivere test unitari prima del codice di implementazione, al fine di garantire un elevato grado di copertura dei test. Insegnare agli studenti a riconoscere schemi duplicati e ripetitivi all'interno del loro codice e a come riformattare il codice per rimuovere tale duplicazione. Aiuta gli studenti a comprendere e applicare principi come SOLID e DRY. Ancora più importante, elimina l'idea che la capacità di mantenere il codice sia qualcosa che si basa esclusivamente sulla progettazione e l'implementazione del codice, e invece infondi un senso di abilità e qualità nella produzione del software fin dall'inizio, cercando di perfezionare il codice man mano che viene implementato al fine di ridurre al minimo l'impatto del debito tecnico e quindi ridurre al minimo i costi di manutenzione del software nel tempo.

Penso che il modo migliore per imparare questo tipo di abilità sia fare revisioni del codice e accoppiare le programmazioni. Durante le revisioni del codice, il personale esperto può indicare come rendere il codice più gestibile (in genere rendendolo più leggibile) e giustificare il motivo per cui alcune scelte possono creare codice più gestibile.

La programmazione in coppia è un modo ancora migliore per insegnare questo tipo di cose, perché offre allo staff meno esperto un'esperienza diretta nel mantenimento del codice con qualcuno che già sa come farlo bene.

Ci sono anche alcuni grandi libri che puoi leggere sulla scrittura di codice pulito e gestibile. Viene in mente Clean Code .

È difficile ottenere questa esperienza attraverso il mondo accademico poiché gli studenti raramente modificano basi di codice di grandi dimensioni. La maggior parte di queste abilità deriverà dall'apprendimento sul posto di lavoro e la revisione del codice e la programmazione delle coppie possono davvero facilitare questo apprendimento.

Buon codice = Meno manutenzione e Funzioni facili da migliorare / aggiungere.

Codice errato = incubo di manutenzione

Fondamentalmente dobbiamo far capire agli studenti che "ogni volta che c'è un codice schifoso in un progetto, un nuovo sviluppatore che entrerà a far parte dell'azienda perché l'autore originale del codice ne soffrirà e l'impatto del software ".

Quindi uno dei modi migliori per insegnare allo studente la manutenzione del software è mostrare l'esempio sia del buon codice che del cattivo codice e chiedere loro di aggiungere una funzione e quindi insegnare loro che scrivere un buon codice non è solo per auto-soddisfazione, ma anche per fare è facile per le persone che manterranno il codice.

Esercizio:

1) Avere un codice duplicato (ad es.) Codice duplicato pre-scritto, un metodo che dice "calcolare il pagamento del mutuo" è scritto in 9 punti in un progetto.

Chiedi allo studente di migliorare la funzione per "aggiungere un supplemento dell'1,2% a tutti i pagamenti dei mutui".

Ora lo studente vedrà il dolore di individuare e correggere il codice in tutti e 9 i posti. Ci sono molte possibilità che non sia riuscito a individuare tutti e 9 i posti in cui viene calcolato il "pagamento del mutuo".

2) Ora mostra il codice buono che ha questo metodo che calcola il pagamento del mutuo in un unico posto . dimostrare allo studente quanto sia facile migliorare un codice ben scritto e spiegargli come migliora la manutenibilità del codice / progetto.

A proposito, ho adorato il tuo approccio nell'esporre gli studenti alla manutenibilità del software.

@mattmattj: Dal momento che ci sono MOLTE risposte e il link che ho pubblicato ha anche dei buoni suggerimenti, aggiungerò qualcosa che si spera non sia una ripetizione delle risposte già pubblicate.

Innanzitutto, DEVE definire "manutenibilità" - non esiste una sola definizione accettata da tutti - simile a quella dell'architettura software. Quindi scegline uno che ritieni sia il più importante, che comprenda tutti e dichiaralo in 3-4 righe al massimo. Quindi puoi parlare di alcune metriche come - il tempo di ricordare / comprendere il tuo codice (o quello di qualcun altro), il numero di WTF al minuto / ora ecc. Mantenerlo leggero (divertente) - che li renderà più ricettivi a ciò che hai per dire dopo.

Alcuni esercizi (può sembrare un po 'sovrapposto ad alcune delle risposte, per favore perdonalo)

Dividi la classe in due: assegna a una sezione un semplice compito di codifica che deve essere eseguito in 1-2 giorni. Max. Scadenza rigida. Devono svolgere il lavoro in tutte le circostanze - linea guida - "codice di lavoro" come ritengono opportuno. Per l'altro gruppo di studenti lo stesso compito, ma con un elenco di convenzioni (di denominazione) e alcune linee guida sulla progettazione e su come verranno detratti i punti se non seguiti. Questo NON è un imbroglio, anche se sembra che sia così;) Ora fai scambiare i codici, cioè il gruppo 1 ora funziona su ciò che ha fatto il gruppo 2 e viceversa. Ora suggerisci una modifica all'assegnazione del codice originale e chiedi loro di farlo nello stesso lasso di tempo. Riconveni e chiedi loro quanto sia stato facile / difficile e apri la parola a discussioni / opinioni. Il punto colpirà sicuramente a casa - alte probabilità che il 50% della classe sarebbe felice e lo trovasse facile e il 50% lo trovasse difficile. Puoi anche chiedere loro di lavorare da soli dopo 3 settimane e vedere se riescono a farlo in 1 giorno;)

(Una buona svolta è che stai scrivendo lo stesso pezzo di codice in modo contorto e dando alla classe per la modifica insieme al proprio)

Ecco dove getti le basi della manutenibilità: ogni riga di codice modificata / aggiornata costa denaro all'azienda. Più è facile leggere e ricordare nuovamente il codice, migliore / più veloce sarà la modifica che contribuirebbe a ridurre il time to market. Molto importante nello spazio tecnologico frenetico di oggi. La manutenibilità è la chiave per un'evoluzione efficiente dei sistemi.

È importante comprendere la differenza tra sviluppo greenfield e brownfield - non tutti i progetti o sistemi verrebbero creati da zero (è piuttosto difficile trovare o far parte di progetti "ex novo"). Spiegando che il campo è "intrinsecamente" marrone e si deve passare il tempo a modellarlo mentre si procede con l'eventuale eliminazione graduale quando cresce "fuori mano" (possibile solo quando la deriva è eccessiva e "non mantenibile"). Prima lo accettano e meglio è. Ciò è difficile poiché la programmazione è intrinsecamente creativa ma il miglioramento del codice di qualcun altro non viene percepito come tale - giralo intorno. Creatività c'è la capacità di comprendere il codice e quindi applicare la "tua" creatività per migliorarla - se mantenuta meglio sarai in grado di migliorarla in modo più creativo in futuro.

Sentiti libero di fare riferimento all'analogia degli spaghetti nel link sopra ... spero che questo aiuti a colpire alcuni punti a casa. Le altre risposte aiutano a colmare le lacune e dovrebbero aiutarti con l'insegnamento! Buona fortuna!