Come posso promuovere la codifica pulita sul mio posto di lavoro?

Non hai menzionato il tuo livello di esperienza in materia. Se non sei un programmatore senior, tuttavia, la cosa migliore che puoi fare è fare bene il tuo lavoro. Hai anche detto che il tuo manager ama il lavoro pulito - è grandioso. Se puoi parlargli di questo (magari in un ambiente semi-professionale) dovresti condividere le tue preoccupazioni riguardo al problema con lui. HE è nella posizione di cambiare flusso di lavoro.

Che cosa significa codice pulito per te?

Sono certo che la tua definizione sia ottima, ma gli altri ragazzi sul posto di lavoro probabilmente hanno una propria definizione. Non hanno torto, sono solo diversi dai tuoi.

Dovresti creare linee guida per la codifica su cui tutti i tuoi colleghi possono essere d'accordo, e dovresti farlo insieme con i tuoi colleghi programmatori. Non provare a forzare questo sulle persone, si ritorcerà contro se lo fai.

Quindi riunisci il team e inizia a lavorare su una definizione comune di "codice pulito"! Non ci sono regole dure per questo. Stai cercando di riunire diverse menti e questo può portare a conflitti, quindi potresti voler preparare il palco con una nota positiva che tutti dovrebbero essere rispettosi e mantenere una mente aperta (la scrittura del codice è personale ...).

Il libro Pulisci codice potrebbe tornare utile. Potresti usare degli esempi tratti da quel libro per parlare e vedere se trovi qualche terreno comune lì dentro?

Ci sono due cose che possono fare miracoli per garantire una costante e una barra alta per la qualità del codice.

Esegui revisioni di codici

Dovresti sforzarti per ogni controllo - non importa quanto sia banale - essere rivisto da un'altra persona del team. Nessuna eccezione. A prima vista, questo sembra che si intrometterà, soprattutto per gli sviluppatori senior che pensano di non avere nulla da guadagnare facendo rivedere il proprio codice da persone meno esperte. Tuttavia, avere revisioni periodiche del codice avrà un impatto incommensurabile per ogni sviluppatore del team.

Definisci uno standard e rimani con esso

In Google abbiamo una guida in stile di codifica per ogni lingua che utilizziamo: C ++ , < a href="http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml"> Java , Python , ecc. Mentre gli ingegneri sono liberi di non essere d'accordo con la guida di stile, non è opzionale. (Ed è rigorosamente applicato nelle revisioni del codice.) Di conseguenza, l'intero codebase - centinaia di migliaia di righe di codice - è molto coerente.

Penso che se sei appassionato di codice pulito, questo si ripercuoterà sui tuoi colleghi. La mentalità "Funziona, deve essere ok" che può essere cambiata da persone che sostengono un buon design e codice pulito in modo entusiasta.

Sebbene diverse risposte utili siano state pubblicate qui per un po ', credo che ci sia spazio per un'altra. Il mio suggerimento è, come altri hanno detto, di fare revisioni del codice. Ma vale la pena menzionarlo di nuovo perché il termine "revisione del codice" è così vago ... quasi altrettanto vago di "codice pulito" :-). Ho dedicato molto tempo e impegno a lavorare su questo obiettivo inafferrabile. E in particolare negli ultimi due anni, alimentato da colleghi che condividevano la mia passione, ho distillato le mie nozioni, fondendomi con idee chiave di importanti sviluppatori, in una serie intitolata Zen of Code Reviews .

I miei articoli sono unici, per quanto ne so, in quanto copro entrambi lati del corridoio: eseguendo una revisione del codice come autore e facendo una revisione del codice come recensore . Anche se correlati, le abilità per ciascuno sono alquanto diverse. Ed essere in grado di fare entrambe le cose porterà a una migliore qualità del codice. La revisione del codice è importante tanto quanto scrivere codice. Realmente. Promuove il trasferimento delle conoscenze, incoraggia la coerenza e la comunicazione del team, aiuta a migliorare il tuo mestiere e, ultimo ma non meno importante, riduce il software buggy in modo molto conveniente - dal più vicino possibile al lancio .

I primi due forniscono suggerimenti e tecniche per preparare una revisione del codice. In poche parole:

• Come autore, hai una conoscenza approfondita del motivo per cui ogni riga modificata è presente nella revisione del codice. Molti sono ovvi per un revisore esperto, ma molti non lo sono. Raccogli i punti annotando la revisione del codice prima di inviarlo ai revisori.
• Ancora prima, considera attentamente cosa comprende la revisione del codice: assicurati di includere tutte le modifiche pertinenti per un problema e prova a non includere più di un problema.
• Assicurati di eseguire un controllo del controllo del codice sorgente (per risincronizzare il codice con il principale) prima di inviarlo.
• Controlla il tuo codice prima di inviarlo, riga per riga!

Part 1: Pre-Review Comments: Empower your colleagues to give you better feedback on your code review

Part 2: Best Practices: Guidelines for preparing a code review

E gli altri due articoli forniscono consigli pratici su come essere un revisore migliore:

• Leggi prima Jira / issue / ticket / requirement (qualunque cosa tu lo chiami)
• Verifica che i test unitari coprano i requisiti.
• Rivedi i test unitari per la classe di equivalenza e la completezza del valore al contorno.
• Verifica che ogni test dell'unità funzioni quanto basta, non testando più cose.
• Rivedi il codice per l'adesione ai principi SOLID.
• Fai attenzione a reinventare ruote, codice complicato e codice complicato.
• Evita la magia (stringhe magiche, intarsi magici e, sì, anche i booleani magici).
• Cattura l'effetto farfalla - ci sono increspature che sono state perse (ad esempio incoerenze nella denominazione).

Part 3: The Reviewer's Tale: Guidelines for performing a code review

Part 4: Review As If You Own the Code

Guida con l'esempio. Controlla il tuo codice.

Nella mia esperienza la maggior parte delle applicazioni "RPG + Java" sono scritte da programmatori provenienti dal lato RPG, e non dal lato Java, e la mentalità dei due mondi è molto diversa che credo sia una delle ragioni per cui avere problemi di progettazione di base.

Gli strumenti IBM ufficiali sono basati su Eclipse, quindi se lo usi, puoi usare la maggior parte dei trucchi e suggerimenti disponibili per Eclipse, e devi trovare cose che danno molto in cambio di poco sforzo, perché in pratica hai bisogno per mostrare queste persone che vale la pena di fare.

Una delle cose più efficienti che ho trovato per questo è l'azione di salvataggio dell'editor Java, dove puoi chiedere di riformattare la tua fonte ogni volta che salvi un file. In breve tempo ciò si tradurrà in un layout di codifica più uniforme che semplifica la lettura delle cose. Ho scritto le mie conclusioni qui.

Se per prima cosa hai la nozione che potresti avere suggerimenti utili, è molto più probabile che le persone ascoltino ...

"Tutti scrivono codice errato". Digestalo e poi riconoscilo. Questo imposta l'intera squadra su un piano che rompe la gerarchia e instilla in tutti quelli che sono tutti uguali. È molto importante per un programmatore anziano dimostrare questo comportamento e atteggiamento. Con queste premesse, pratica la programmazione delle coppie durante la quale dovresti discutere, discutere (nel tempo) e convergere in una decisione su ciò che è giusto dopo aver conversato perché qualcosa potrebbe essere sbagliato. Mentre la programmazione di coppie una persona è superiore rispetto ad altre - entrambi sono programmatori umili e aperti. Quale modo migliore per promuovere buone pratiche di codifica! :)

Un modo in cui non ho visto menzionato in nessuna delle risposte finora è l'istruzione. Fai in modo che la tua azienda sponsorizzi l'ingresso per coloro che vogliono andare al tuo JavaZone o RubyConf più vicino o qualunque conferenza sia adatta e conveniente per te. Trova i corsi rilevanti e invia gli sviluppatori selezionati a partecipare. Se la tua azienda è abbastanza grande, potrebbe essere anche possibile organizzare seminari e corsi interni su argomenti come le migliori pratiche, corsi di perfezionamento per la tua lingua, ecc. Prendi un buon docente sull'argomento e prepara un corso su misura per la situazione della tua azienda. / p>

La mia azienda lo sta facendo parecchio, e mentre c'è ancora chi rifiuta ostinatamente di essere interessato, la consapevolezza generale di problemi come questi sta crescendo - e lo stato generale della nostra base di codici sta migliorando. Anche il corso di "Basic C" che abbiamo fatto per diversi round si è dimostrato illuminante per gli sviluppatori che hanno scritto C per ben 10-15 anni. Non perché siano cattivi programmatori, ma perché tendi a cadere nelle abitudini e dimentichi il motivo, e anche il linguaggio e l'esperienza collettiva su come usarlo sta cambiando lentamente.