Consigli per insegnare ai giovani programmatori uno stile di codifica buono [duplicato]

Make a good impression

prendi alcuni dei libri più noti, ad es. Clean Codice , Codice completo , Coders at Work , Clean Coder: un codice di condotta per i programmatori professionisti ecc. ( guarda qui per gli elenchi completi ) e dai loro una coppia di giorni per leggerne uno - al lavoro, in un ufficio privato. Distanziateli, diciamo 1 libro al mese o un quarto. Vedranno dallo sforzo che ciò che stai dicendo personalmente è davvero importante, non solo "la linea della compagnia" da portare con un pizzico di sale. Ovviamente assicurati di avere una gestione in linea con questo: non vuoi che dicano di passaggio "eh? Qual è la persona X fino a quando non è rinchiusa lì dentro con la porta chiusa?"

Insieme a corsi di formazione continui e più formali nelle ultime tecnologie.

Inoltre, mentre le cose sono fatte "nel modo giusto" ha dato un grande incoraggiamento e persino dei premi. Altrimenti può essere più di un ambiente negativo, punitivo, piuttosto che positivo, gratificante. La maggior parte della gente vuole fare e vuole essere conosciuta per fare "un buon lavoro" se ha gli strumenti per farlo.

Practice what you preach, Preach what you practice

Parla del codice, parla dei buoni principi, parla di nuovi strumenti, diventa "conosciuto" per questo.

Fornisci / supporta / suggerisci screencast, video, peepcodes e qualsiasi tutorial e classe online che puoi trovare.

Supporto e suggerimento di gruppi di utenti locali appropriati, compresi quelli su siti come link

Se sei in ufficio (ad esempio, non virtuale), una buona libreria di libri reali che vorresti che le persone usassero è buona. Trova un modo per rendere questo "non solo scaffale polveroso nell'angolo" ma posizionandolo in modo ben visibile, spostando i libri in giro, ecc. Usa anche la tua immaginazione. Forse ogni programmatore riceve un libro come "compiti a casa" al mese e tu hai una riunione mensile dove possono "presentare i loro risultati"!

Questo renderà molto più un'impressione che ogni conversazione da 10 minuti da sola e ti rimuoverà dal ruolo di "critico" e permetterà loro di imparare a pescare da soli (invece di dare loro il pesce, conosci l'accordo) . Alcuni giovani trovano anche intimidatorio avere un anziano che spiega sempre cose, quando a volte tutto ciò che vogliono veramente è un po 'di tempo per studiare, esercitarsi e assorbirlo.

Instill a culture of learning and excellence

Fondamentalmente vuoi creare "una cultura dell'apprendimento e dell'eccellenza" in modo da poter mettere in pratica ciò che insegni e ispirare gli altri a fare lo stesso.

Questo dovrebbe essere in concomitanza con le revisioni del codice per vedere se / come i principi si applicano al lavoro effettivamente svolto. Viceversa, le revisioni del codice eseguite senza sopra possono sembrare sessioni da montare allo studente, non importa quanto ben intenzionate dall'insegnante.

Tutti i programmatori dovrebbero sempre eseguire recensioni di codice con un programmatore esperto prima di commettere / unire le loro modifiche al codice.

1. Ciò offre ai programmatori esperti la possibilità di raggiungere un consenso su quali stili vogliono applicare (e riconoscere quali sono solo una questione di preferenza) tra di loro.
2. Offre ai programmatori junior la possibilità di apprendere quali pratiche sono attese dalla loro squadra fin dall'inizio. Entro un paio di mesi, il 90% del codice che scriveranno seguirà già tali pratiche prima della revisione del codice.

Inoltre, la maggior parte degli IDE ha strumenti che è possibile configurare per applicare la maggior parte delle preferenze di stile di codifica con belle sottoveste e opzioni squiggly per correggere automaticamente lo stile in un file. I programmatori Junior riprenderanno quel ritmo piuttosto veloce.

Penso che il modo migliore per incoraggiare questo comportamento da parte dei giovani sviluppatori sia quello di esercitarsi da soli e di essere un modello per loro. Se possibile, dovresti accoppiare il programma con loro spesso e porre l'accento sulla qualità del codice quando programmati con loro. Durante l'abbinamento, puoi spiegare e giustificare le buone scelte di codifica man mano che le fai. Puoi esplorare le opzioni "peggiori" e spiegare perché non sono una buona soluzione a lungo termine. Essere parte di questo tipo di sviluppo a mani nude è probabilmente uno dei modi migliori per insegnare ai nuovi sviluppatori l'importanza della qualità del codice. Se tutti i membri del team pensano che la qualità del codice sia importante, impareranno a rispettarlo.

Sembra che sia qualcosa di semplice da applicare, dato che uno standard di codifica verrà gestito solo da:

1. Assumi le persone che sono d'accordo con te.
2. Analisi del codice
3. Utilizza le applicazioni che possono automatizzare questa roba.
4. Make fa parte del tuo lavoro come mostrato. Ci devono essere delle conseguenze per non aver fatto il tuo lavoro.

Personalmente, sarei un pessimo lettore di un manager che lo ha reso troppo prioritario. Concentrati su ciò che è importante e non ottenere nitpicky. Dovresti essere in grado di giustificare il motivo, ma ci sono momenti in cui devi scegliere uno standard (Chissà perché un rientro di 4 spazi è migliore di 5 a parte il fatto che sei solo mentalmente.).

Ottieni un certo consenso di squadra sugli standard. Ciò migliorerà la qualità e il livello di aderenza. Non perdere troppo tempo in un dibattito. Alla fine un leader prende una decisione in base alla quantità di input.

Offri loro una unità di codice scritta in modo molto scorretto per modificare (e testare) e poi riscrivere (e testare) e poi dare loro un'unità di codice veramente ben scritta con test unitari da modificare (e testare) e chiedere loro l'esperienza.

Dopodiché fornisci loro una lista di standard da leggere e rifattorizzare il loro codice (dall'esercizio precedente) per abbinare tali standard alla pratica.

Prima di questo, avrai bisogno di una documentazione organizzata dei tuoi standard.

Credo che non dovresti insegnare uno stile di codifica specifico per i seguenti motivi:

• I programmatori junior devono imparare dai loro errori. Miglioreranno continuamente valutando il loro lavoro e facendo revisioni del codice con gli sviluppatori senior.

• Le linee guida per la codifica variano in base alla cultura di un'azienda per cui lavori. Potrei discutere contro ciò che consideri un codice pulito.

• Normalmente i programmatori junior non ottengono molta visibilità sui sistemi aziendali, ed è qui che normalmente vive il codice pulito.

• Molto spesso i docenti universitari sono rimasti bloccati nel mondo accademico per decenni. Personalmente ho trovato che le loro linee guida e i loro feedback erano piuttosto scarsi e poveri rispetto agli attuali standard del settore. Alcuni, ovviamente, sono molto buoni.

Per riassumere:

• Penso che la soluzione non sia insegnare linee guida o stili di codifica specifici, ma cercare di spiegare la loro importanza in progetti di varie dimensioni.

• C'è solo così tanto che puoi spiegare in classe e dai libri.

• Gli sviluppatori dovranno sporcarsi le mani per vedere il vero vantaggio per se stessi.

• Assegna gli sviluppatori junior per abbinare il programma, quindi rivedere il loro lavoro e dare loro un feedback. Alla fine dovrebbero iniziare a vedere il vantaggio.

Non esiste uno stile di codifica di proiettili d'argento che funzioni sempre, proprio come qualsiasi cosa in ingegneria dei sistemi.

Il vero problema è che le persone non sono d'accordo su cosa sia esattamente il codice pulito. Una volta che hai scritto il codice perfetto con ogni dettaglio esattamente corretto, la prossima persona penserà ancora che sia una schifezza. Ogni programmatore sta guardando diverse parti del codice e trova cose che non gli piacciono mentre ignora simultaneamente tutte le parti buone. Questa è una parte necessaria della programmazione, dal momento che i programmatori devono trovare le cose cattive prima di passare al controllo della versione per la prima volta. Quindi i programmatori possono facilmente riconoscere il codice errato. È solo che è diverso per ogni programmatore.

In una squadra, questa funzione causerà problemi, se ci sono regole troppo rigide per le convenzioni o se le persone devono mantenere e lavorare con codice scritto da altre persone. La soluzione migliore è mantenere le convenzioni, ma non farle rispettare. E poi assicurati che tutti sappiano chi è responsabile di ciascuna parte del codice.

Ora insegnare ai programmatori junior è complicato. La maggior parte dei tentativi finisce nel giovane programmatore pensando che il suo ultimo codice sia in qualche modo cattivo e che la sessione di insegnamento sia necessaria per questo. Come se fosse una punizione per qualche errore accaduto prima.

Se è importante usare qualcosa come checkstyle e metterlo in un hook pre-commit. Se il checkstyle fallisce, il codice non può essere impegnato. Checkstyle è abbastanza bravo a dare messaggi di feedback. Le persone capiranno perché il loro codice non ha rispettato lo standard e cosa devono fare per superarlo.

Ho imparato un buon stile di programmazione da uno degli sviluppatori senior di uno dei miei progetti precedenti. Rivede il mio codice per ogni commit durante la riunione di revisione del codice e lui mi spiegherà riga per riga se qualcosa può essere migliorato lì.

• Egli passa attraverso ogni denominazione delle variabili e dei metodi e spiega come chiamarli meglio.

• Va attraverso ogni metodo e mi dice come renderlo più leggibile e più efficiente.

• È stato molto gentile, ma il suo mentoring mi ha aiutato molto.

• Mi ci sono voluti solo tre mesi per allinearmi con lui e ora lui Raramente trova errori nel mio codice.

Seguo lo stesso metodo di insegnamento dei miei sviluppatori junior e funziona.

Clean code and messy code can both lead to identically functioning programs, so does cleanliness matter, and if so, why?

Una differenza tra codice pulito e disordinato è così grande:

• cambiare un codice disordinato è sempre un compito scoraggiante, perché di solito non ha una rete sicura chiamata unit test
• il codice disordinato tende ad avere funzioni e classi enormi e molto complessi. Cercare di capirli è inutile e molto difficile
• il codice disordinato di solito ha parti di codice copia / incollate, aumentando ulteriormente la complessità

D'altra parte, avendo un codice pulito, tutti i membri del team possono comprendere facilmente la logica sottostante e aggiungere nuove funzionalità senza troppi sforzi.

Esegui le revisioni del codice

Indica in particolare i problemi derivanti dallo stile di codifica errato o impedito da uno stile di codifica valido.

Parla molto del motivo per cui è importante.

A seconda di quanto sono junior i tuoi colleghi, renditi conto che devi imparare a scrivere codice prima di poter scrivere un codice valido.

Un'idea: mostra loro come potrebbe essere il codice se creato deliberatamente per non essere facile da leggere e comprendere ( link è un breve esempio, ad esempio). Chiedigli che ti piacerebbe ricevere codice come questo per mantenerlo?

Evidenzia l'importanza di

a computer language is not just a way of getting a computer to perform operations ... programs must be written for people to read, and only incidentally for machines to execute.

(citazione da SICP )

Ho appreso la programmazione per la prima volta dopo aver ricevuto un programma ben scritto e l'ho guidato riga per riga. (Ho imparato molto in quelle due ore che non ho ottenuto il mio intero corso di laurea.) Prova lo stesso con loro, guidandoli attraverso uno dei tuoi migliori moduli, indicando come e perché è stato costruito e disegnato in quel modo. Puoi farlo in una sessione di gruppo.

Se puoi, recita un dittatore benevolo. A seconda del sistema di controllo delle revisioni, potresti essere in grado di usarlo per aiutarti. Tuttavia, si potrebbe finire per essere il collo di bottiglia nel processo di sviluppo.

Distribuire un controllo stile automatico per verificare quante più regole di stile è possibile. (Molte regole di checkstyle dovrebbero essere portabili tra Java e C ++). Questo ti porterà in qualche modo là, ma non sostituirà le revisioni del codice. Portare i tuoi sviluppatori a codice peer review può aiutare a ridurre il carico.

Se si implementa un controllo di stile automatico, è possibile anche implementare uno strumento di analisi del codice statico. Questo dovrebbe aiutare ad eliminare alcuni dei bug che potrebbero mancare nelle revisioni del codice. Ti permetterà anche di concentrarti su questioni stilistiche piuttosto che cercare gli errori che il copione degli strumenti di analisi del codice statico. Ci possono ancora essere casi comuni che devono essere controllati.

Sviluppa una checklist per gli sviluppatori da utilizzare prima di verificare il codice. Questo può contenere altre cose che si desidera verificare prima del check-in. Vi è una crescente evidenza che le liste di controllo possono aiutare a ridurre gli errori. Incoraggia gli sviluppatori a creare la propria lista di errori che comunemente fanno, in modo che possano evitare di ripeterli.

Parlali della programmazione alfabetica di D. Knuth.

I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do

Donald Knuth, about literate programming.

A mio modesto parere, il fatto che l'obiettivo principale di un programma per computer sia comunicare entità intellettuali ad altri programmatori, è un argomento decisivo per l'importanza dello stile di codifica.

Penso che un aspetto sottovalutato dello stile di codifica sia che si manifesta in modo naturale. Quando vedo un codice sorgente che ho scritto molto tempo fa, di solito sento il desiderio irresistibile di sfondare il continuum spazio-temporale solo per darmi un pugno in faccia per le (mostrive) mostruosità che ho esibito nella suddetta fonte. Dal momento che stai mentori juniores, e tendono ad imparare velocemente (dato che ne hanno bisogno), fai la soluzione più semplice possibile: permetti loro di scrivere un brutto pezzo di codice (una volta!), Quindi fallo mantenere. Le probabilità sono, se sono bravi in ingegneria del software, si pentiranno dei loro peccati e refactoring il codice correttamente. Ovviamente, non pubblicherò la loro collezione di spaghetti come codice di produzione, sono certo che ci sono molte opportunità per fare uno junior dev a scrivere qualcosa di piccolo, quasi 'buttare via'.

Non esiste una scuola di software come la vita reale

DRY ha perfettamente senso quando devi modificare quella riga copiata 4 volte, e hai fatto solo 3, ecco perché il codice dereferisce un puntatore nullo e l'app si arresta in modo anomalo ...
Inoltre, l'energia che trascorrerai cercando di trasmettere metodologie "buone" su di loro sarà probabilmente molto, e non è sicuro che non la respingeranno con un "Qualunque cosa, funziona" come hai sottolineato.
Quindi dimostra loro in pratica che lo stile del codice è importante, dimostrando la sua migliore leggibilità anche a se stessi.

Il software di supporto è molto più utile per i programmatori di quanto pensino sia

Penso che sia un altro argomento, ma la maggior parte delle persone presume istintivamente di scrivere un buon codice (mi dichiaro colpevole). Quindi aggiustare il disordine di qualcun altro può essere buono per le proprie abitudini: non peccarebbe se fossi appena tornato da una vacanza all'inferno, giusto (viste religiose a parte)?

Penso che sarebbe un ottimo modo per addestrare i nuovi programmatori con la tecnica delle convenzioni di denominazione [è lo standard per nominare una variabile, un metodo o una classe]. Per un migliore flusso di programmatori che tocchino il codice sarà facilmente gestibile in modo tale da conoscere i nomi rilevanti utilizzati.

Ad esempio: le variabili statiche iniziano con s,         argomento Le variabili iniziano con a, ecc.,