Come migliorare la formazione degli studenti in merito alla manutenibilità? [chiuso]

How can we teach maintainability?

Questa è una questione di pratica.

Il modo più semplice per esercitarlo in un modo controllato che posso pensare è quello di simulare un tipico progetto di manutenzione come segue.

Ottieni qualche progetto ( Progetto A ) che sia ben fatto e presenti alcuni problemi su di esso: iniettare alcuni bug, un buon sonnellino di codice duplicato e morto, rilasciare alcune funzionalità, unit test e documentazione qui ecc. Potresti anche avere un nome dedicato per questo, come Progetto A - versione danneggiata .

Stabilisci un tracker dei problemi e compilalo con richieste corrispondenti a danni specifici che hai fatto. Stabilire regole e pratiche di base per il processo di sviluppo - VCS commette, recensioni di codici, QA ecc. - Prendi in considerazione ciò che puoi dalla lista di controllo fornita nel The Joel Test .

• corsi 1.
  Correggere bug, aggiungere test unitari mancanti, documentazione e funzionalità.
• corsi 2.
  Refactor.
• corsi 3.
  Manutenzione / miglioramento di progetti originali da utilizzare per gli studenti del prossimo anno - Progetto A versione 2.0 e Progetto A - versione 2.0 danneggiata , rispettivamente.
  _{Migliorando versione danneggiata Voglio dire fare meglio danno educativo ad esso. :)}

Tra le pratiche sopra menzionate, presta particolare attenzione a quella delle recensioni del codice . Questo è probabilmente il modo più efficace per garantire che il codice sia facile da mantenere, come indicato ad esempio da top answer nella domanda correlata .

Dichiarazione di non responsabilità: ho appena ottenuto la laurea in CS. Non sono un insegnante.

Può sembrare ovvio, ma penso che il modo migliore per insegnare la manutenzione del codice sia che gli studenti eseguano la manutenzione del codice. Ecco cosa farei:

1. Prendi un problema moderatamente complesso e due implementazioni semanticamente identiche, ma una è molto più gestibile rispetto all'altra.
2. Richiedi un numero di modifiche / aggiunte di funzioni che sono molto più facili da implementare sulla base di codice migliore. Una metà degli studenti deve implementarli sulla base del codice più manutenibile, 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 valide e negative e il tempo impiegato per implementarle. Invita gli studenti a condividere le loro esperienze, a esprimere le loro lamentele e, in generale, a parlare del lavoro che hanno svolto.

L'idea è non solo che gli studenti lavorino con il codice di qualcun altro, ma anche che sviluppino un apprezzamento per il codice gestibile che sperabilmente migliorerà le loro capacità di progettazione.

La manutenibilità è una virtù, non un'abilità. Esistono molti percorsi per la creazione di progetti gestibili, ma nessuna formula è garantita per produrli.

Se apprezzi le virtù come la gentilezza e la generosità, cerchi dei modi per praticare lo stesso nella tua vita quotidiana. Lo stesso vale per la manutenibilità: se tu e la tua organizzazione valutate la manutenibilità, la manterrete nella vostra mente mentre progettate e implementate il vostro progetto. Sarà un motivo legittimo per dedicare un po 'di tempo in più a costruire qualcosa perché sai che la manutenibilità è apprezzata. Viceversa, la spesa extra per motivi di manutenibilità in un'organizzazione che non la apprezza è scoraggiata.

Se vuoi insegnare alle persone a rendere le cose gestibili, dovresti iniziare chiarendo che la tua organizzazione valuta la manutenibilità. Specificalo nei requisiti per i tuoi progetti. Rendilo uno dei criteri per il successo delle revisioni del codice. In breve, rende la manutenibilità parte della tua cultura .

Quindi, sii disponibile a dedicare alcune risorse per migliorare la manutenibilità nei tuoi progetti esistenti. Identifica le parti di un progetto in cui gli errori continuano a crescere, o dove correggere bug o apportare modifiche è molto difficile e richiede molto tempo e riprogettazione o refactoring per facilitare la manutenzione.

Infine, indottrina i nuovi sviluppatori nella tua cultura della manutenibilità assegnandoli ai team che lo praticano quotidianamente. Non esiste un modo migliore per aiutare qualcuno ad adottare un valore se non quello di dare loro un sacco di buoni esempi e indicazioni.

A me non piace il termine Gestibile 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 poco costoso da mantenere, relativamente parlando. So che questa sembra 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 titoli di informatica che sono importanti nello sviluppo del software è che in realtà insegnano solo agli studenti il minimo indispensabile che gli studenti devono sapere sulla scrittura del software. Le abilità e le conoscenze professionali si ottengono attraverso l'apprendimento che viene svolto nei primi anni dopo che si qualificano 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 grande pressione da eseguire, e l'aspettativa è 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 essere costosi da sviluppare e mantenere come risultato. Sfortunatamente per i nostri laureati, imparano molte cattive abitudini in questi ambienti nei primi anni della loro carriera, e può essere molto tempo prima che imparino come superare queste abitudini ... se non del tutto.

Sarebbe meglio insegnare agli studenti come scrivere codice pulito, e come identificare i problemi nel software che di solito finiscono per incorrere in debito tecnico . Cerca nei libri su Pulisci codice , Refactoring e Lean Software Development come punto di partenza come punto di partenza, e insegnare agli studenti a scrivere test unitari prima del codice di implementazione, al fine di garantire un livello elevato di copertura del test. Insegnare agli studenti a riconoscere i modelli duplicati e ripetitivi all'interno del loro codice e come rifattorizzare il codice per rimuovere tale duplicazione. Aiuta gli studenti a comprendere e applicare principi come SOLID e DRY . Soprattutto, eliminare questa idea che la capacità di mantenere il codice è qualcosa che viene fatto basandosi esclusivamente sulla progettazione e sull'implementazione del codice, e invece infondere un senso di artigianalità e qualità nella produzione del software fin dall'inizio, cercando di perfezionare il codice mentre viene implementato al fine di ridurre al minimo l'impatto del debito tecnico e quindi mantenere il costo di mantenere il software al minimo nel tempo.

Penso che il modo migliore per apprendere questo tipo di abilità sia fare revisioni del codice e programmare una coppia. Durante le revisioni del codice, lo staff esperto può indicare come rendere il codice più gestibile (in genere rendendolo più leggibile) e giustificare il motivo per cui determinate scelte possono creare un codice più gestibile.

La paia di programmazione è un modo ancora migliore per insegnare questo tipo di cose, perché fornisce all'esperienza diretta del personale meno esperto nel mantenere il codice con qualcuno che sa già come farlo bene.

Ci sono anche alcuni ottimi libri che puoi leggere sulla scrittura di codice pulito e manutenibile. Mi viene in mente Pulisci codice .

È 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à verrà dall'apprendimento sul posto di lavoro, e le revisioni del codice e la programmazione della coppia possono davvero facilitare questo apprendimento.

Codice buono = Manutenzione ridotta e Semplicità di miglioramento / aggiunta di funzionalità.

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à nell'azienda perché l'autore originale del codice ne soffrirà e come il software è interessato. "

Quindi uno dei modi migliori per insegnare allo studente la manutenzione del software è mostrare l'esempio sia del codice buono che del codice errato e chiedere loro di aggiungere una funzione e poi insegnare loro che scrivere un buon codice non è solo per la soddisfazione personale ma per renderlo facile per le persone che manterranno il codice.

Esercizio:

1) Avere un codice errato pre-scritto (es.) codice duplicato, un metodo dice "per calcolare il pagamento del mutuo" è scritto in 9 posti in un progetto.

Chiedi allo studente di migliorare la funzione per "aggiungere un supplemento dell'1,2% a tutte le rate del mutuo".

Ora lo studente vedrà il dolore di localizzare e fissare il codice in tutti e 9 i posti. Ci sono molte possibilità che non sia in grado di localizzare tutti i 9 luoghi 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 solo posto . dimostrare allo studente che è facile migliorare un codice ben scritto e spiegargli come migliora la manutenibilità del codice / progetto.

A proposito, ho adorato il tuo modo di esporre gli studenti alla manutenibilità del software.

@mattmattj: Poiché ci sono MOLTE risposte e il link che ho postato ha anche alcuni buoni suggerimenti Aggiungerò qualcosa che, si spera, non è una ripetizione delle risposte già pubblicate.

In primo luogo, si DEVE definire la "manutenibilità" - non esiste una singola definizione accettata da tutti - simile a quella dell'architettura software. Quindi scegline uno che ritieni sia il più importante, completo e lo dichiari in 3-4 righe al massimo. Quindi puoi parlare di alcune metriche come: il tempo per ricordare / capire il tuo codice (o quello di qualcun altro), il numero di WTF al minuto / ora ecc. Mantieni la luce (umoristica) - che li renderà più ricettivi a ciò che hai per dire dopo.

Alcuni esercizi (potrebbe sembrare un po 'sovrapposto ad alcune delle risposte, ti prego di perdonarlo)

Split the class in two - give one section a simple coding assignment that needs to be done in 1-2 days. Max. Hard deadline. They have to get the work done under all circumstances - guideline - "working code" as they deem fit. For the other group of students the same assignment but with a list of (naming) conventions and some guidelines about design and how points will be deducted if not followed. This is NOT cheating, even if it sounds like it ;) Now have them swap the codes i.e. group 1 now works on what group 2 did and vice versa. Now suggest a modification to original coding assignment and ask them to do it in the same time frame. Reconvene and ask them how easy/difficult it was and open the floor to discussions/opinions. The point will definitely hit home - high chances 50% of the class would be happy and found it easy and 50% found it difficult. You may also ask them to work on their own thing after 3 weeks and see if they can do it in 1 day ;)

(A good twist is you writing the same piece of code in a convoluted manner and giving to the class for modification along with their own)

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

È importante capire la differenza tra sviluppo di greenfield e brownfield - non tutti i progetti o sistemi sarebbero creati da zero (è piuttosto difficile trovare o far parte di progetti "da zero"). Spiegando che il campo è "intrinsecamente" marrone e devi passare il tempo a modellarlo mentre procederai con l'eliminazione progressiva quando cresce "inavvertitamente" (possibile solo quando la deriva è eccessiva e "non mantenibile"). Prima lo accettano e meglio è. Questo è difficile dal momento che la programmazione è intrinsecamente creativa, ma il miglioramento del codice di qualcun altro non è percepito come tale. La creatività è la capacità di comprendere il codice e quindi di applicare la "tua" creatività per migliorarla - se meglio conservata, sarai in grado di migliorarla in modo più creativo in futuro.

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