Gestione degli standard di codifica sul lavoro (io non sono il capo)

Un collaboratore ed io abbiamo avuto un problema simile nella nostra squadra quando ci siamo uniti per la prima volta (mi sono unito al team per primo, è entrato circa un anno dopo). Non c'erano standard di codice reali. Siamo un negozio di MS e anche gli standard di codifica MS non sono stati utilizzati. Abbiamo deciso di dare l'esempio. Ci siamo seduti insieme e abbiamo redatto un documento che conteneva tutti i nostri standard: standard IDE, standard di denominazione, tutto ciò a cui potevamo pensare. Poi lui ed io abbiamo accettato di seguire lo standard esplicitamente. Ho inviato una email al team (da entrambi) e ho comunicato loro che avevamo trovato una mancanza e che avremmo risolto la mancanza con il nostro documento. Abbiamo invitato la critica, idee, commenti, opinioni. Abbiamo ricevuto molto poco in termini di feedback e solo un piccolo respingimento. Lui e io abbiamo immediatamente iniziato a utilizzare gli standard e, quando abbiamo introdotto sviluppatori junior nei nostri progetti, li abbiamo introdotti allo standard e hanno iniziato a utilizzarlo. Abbiamo alcuni lead che all'inizio erano riluttanti, ma hanno iniziato lentamente a utilizzare lo standard per moltissime cose.

Abbiamo scoperto che molti sviluppatori junior avevano riconosciuto lo stesso problema ma stavano aspettando che qualcun altro si facesse avanti e prendesse la decisione. Una volta che c'era un piano da seguire, molti erano ansiosi di adottarlo. I dadi più difficili da decifrare sono quelli che si rifiutano di codificare con qualsiasi altro mezzo, e di solito si codificano per uscire dall'immagine a lungo termine.

Se vuoi standard, fagli strada. Trova una lista di standard che ritieni possano essere utili alla tua squadra. Invialo ai colleghi e conduce per un feedback. Sono sicuro che altre persone nella tua squadra hanno idee simili, ma probabilmente non hanno il coraggio di fare qualcosa al riguardo. Come disse Gandhi, "Devi essere il cambiamento che desideri vedere nel mondo."

Gli standard non dovrebbero essere definiti e applicati da un manager. La squadra nel suo complesso dovrebbe essere d'accordo con gli standard. Se non riescono a raggiungere un accordo su un insieme comune di standard, ottenere un manager per forzare gli standard su di essi avrà esito negativo.

Tu e gli altri che sono d'accordo con te dovresti dare l'esempio. Inizia a utilizzare gli stessi standard di codifica, pubblicali e promuoverli al resto del team e invita i feedback su come migliorarli.

Ecco l'importante quando provi a promuovere gli standard: assicurati che l'attenzione non sia nel trovare il modo migliore di fare le cose, ma piuttosto nel trovare un modo coerente di fare le cose. Proprio come alcune persone potrebbero non essere d'accordo, non esiste uno stile di brace vero e proprio, nessuno stile di commento reale, ecc. Ciò che rende il codice più facile da leggere (e quindi più facile da mantenere) è uno stile coerente, qualunque esso sia.

Puoi mostrare qualche prova del tempo che hai perso a causa dei problemi che questo sta causando?

Se impieghi una notevole quantità di tempo per risolvere questi problemi, o perché causano errori che richiedono tempo per risolverli, questo è un costo che puoi ridurre drasticamente adottando gli standard di codifica.

Quindi tieni un registro dei problemi che incontri e il tempo necessario per risolverli - sia per te che (dove ne sei a conoscenza) i tuoi colleghi.

Poi, quando hai una quantità ragionevole di dati, presentati ai tuoi colleghi. Dovrebbero vedere il beneficio dell'adozione di uno standard. Se non mostrare i dati al tuo capo e al suo capo. Dimostrate che avendo gli standard di codifica potete risparmiare i soldi della vostra azienda e che dovrebbero aiutarvi a farli adottare.

Sulla tua particolare situazione, penso che la soluzione del tuo capo sia buona. Nessuno deve cambiare quello che hanno fatto per tutta la loro carriera, e va bene perché i bit di stile del codice che il compilatore ignora non contano finché il codice è leggibile. Se tutti hanno fatto una formattazione automatica al loro stile al momento del check-out e una formattazione automatica a uno stile standard al momento del check-in, tutto andrebbe bene. (Purtroppo ho suggerito che dove lavoro e si è opposto sulla base del fatto che il programmatore non avrebbe più scritto lo stesso codice esatto che vede il server di integrazione continua.)

Penso che gli standard di codifica siano validi se applicati a luoghi in cui fa davvero la differenza nella qualità del codice: ad esempio, metodi piccoli, classi che hanno una responsabilità chiaramente definita, commenti utili e accurati per i bit più duri, ecc. Sfortunatamente , questi aspetti sono più difficili da controllare automaticamente, ma questo è fondamentale per lo sviluppo del software. Tutto quello che puoi veramente fare è insegnare agli altri buone pratiche e insegnare a te stesso a leggere il codice con la coppia sulla linea sbagliata.

Riguardo agli standard di codifica: salirò a bordo con quasi tutti gli altri nel dire che gli standard di codifica sono una "cosa buona" (rispetto a nessuno standard).

Tuttavia, non lasciarti trasportare. Ho lavorato su alcuni progetti che dettavano uno stile di indentazione specifico, fino al numero di personaggi (e quando i progetti arrivano così lontano, inevitabilmente scelgono qualcosa di stupido come 8 rientro nello spazio). Non preoccuparti delle piccole cose.

Una soluzione semplice: dare agli sviluppatori una serie limitata di scelte per controventi e rientranze, ma imporre che lo stile di controvento e il rientro devono essere coerenti in un modulo. (Si desidera che foo.h e foo.cpp seguano lo stesso stile, non è vero?) I manutentori devono adattarsi allo stile esistente; non possono riscrivere un modulo per soddisfare il loro stile stravagante. Più stili all'interno di un modulo sono solo confusi ed è un segno di sciatteria. Quando vedo quell'assurdità mi chiedo che altro è sbagliato.

Potresti anche voler pensare a mettere al bando le schede per il rientro nei contenuti salvati di un file . La maggior parte degli IDE / editor svolge un lavoro ragionevole traducendo le schede di input degli utenti in spazi, e la maggior parte ha opzioni per rendere automatica la traduzione. Molti fanno un lavoro schifoso quando il file contiene già schede, in particolare un insieme misto di schede e spazi.

Tutto ciò che ho detto, penso che potresti avere un problema più profondo nel tuo progetto. Hai citato problemi con la fusione. Se ti ritrovi a dover fare un sacco di fusioni potrebbe essere un segno di una cattiva partizionamento del progetto. Proprio come troppi cuochi rovinano il brodo, troppi programmatori che operano sullo stesso file rovinano il progetto. Perché ciascuno di Joe, Susie e tu stai toccando foo.cpp?

Questa è una delle aree in cui viene svolta una ricerca. Fondamentalmente la domanda principale è se si stanno facendo revisioni del codice. Le revisioni del codice sono senza dubbio il mezzo più efficace per migliorare la qualità del codice. (Fonte: Software Engineering Institute, CMU). È sicuramente più efficiente di un tester supplementare.

Ora, le revisioni del codice traggono vantaggio da uno standard di codifica comune, in quanto facilita la lettura del codice di altre persone. Ciò fornisce un argomento in due fasi per introdurre gli standard di codifica: alla fine, rende meno costoso produrre un buon codice.

Dato che ci sono già "molti altri" che sono con te su questo, vorrei suggerire un incontro estemporaneo. Invita tutti gli sviluppatori, prendi un po 'di tempo e scopri quali cose stanno dando fastidio a te stesso e ai tuoi colleghi giorno per giorno. Non cercare di trovare soluzioni specifiche all'inizio, basta capire che cosa deve cambiare nel modo in cui stai scrivendo il codice al momento.

Quindi, vedi se puoi essere tutti d'accordo su alcuni concetti di base. Il suggerimento di utilizzare lo stesso stile all'interno di ogni modulo che @David Hammen ha sollevato è un buon inizio e uno penso che la maggior parte degli sviluppatori potrebbe facilmente accettare.

Se, una volta che hai toccato il fondo, ritieni di poter essere d'accordo su uno stile di base per quando scrivi un nuovo codice, questa è una buona aggiunta. Concentrati sulle cose che hanno un impatto sulla manutenibilità; i nomi dei nomi sarebbero in cima alla mia lista personale perché se hai una mezza dozzina di stili di denominazione diversi in un singolo prodotto di qualsiasi complessità notevole, diventerà un mal di testa molto rapidamente, ma ancora una volta, concentrati su ciò che tu e il tuo team sentire è importante . Disegna un breve documento che tutti possono almeno accettare (anche se potrebbero avere uno stile diverso) e inviarlo a tutti i membri del team. Rendilo un documento "vivo", assicurati di aggiornarlo nel tempo, ma assicurati di non renderlo troppo rigido e specifico.

A meno che il tuo capo non sia coinvolto nella scrittura del codice, non dovrebbe preoccuparsi troppo dello stile esatto adottato (purché si concentri sulla leggibilità e sulla manutenibilità), ma dovrebbe essere in grado di vedere i benefici di tutti i membri del team che seguono uno stile comune durante la scrittura del codice.

Ci sono alcune cose che sono dolorose. Il più doloroso è un IDE che riformatta automaticamente il codice, combinato con gli sviluppatori che impostano i propri IDE in modi diversi. Ogni volta che confronti il codice, hai centinaia di modifiche dopo che qualcuno con impostazioni diverse ha modificato il codice. Questo è inaccettabile. Qui è necessario battere le teste di tutti, concordare una serie di impostazioni e rifiutare qualsiasi controllo da parte di chiunque utilizzi impostazioni diverse. Se cambio una singola riga di codice, i diff dovrebbero mostrare una singola riga di codice modificata, e non centinaia.

Tutto il resto è innocuo o ci sono modi migliori per fare cose di cui gli altri possono essere convinti. Qui la regola dovrebbe essere: non scherzare con il codice di altre persone a meno che non lo si migliori davvero. E un mix di stile A e stile B è sempre peggiore rispetto allo stile A o allo stile B.

Assicurati di seguire le migliori pratiche. Quale è diverso per lingua. Ma lì non hai bisogno di standard (che potrebbero essere stati scritti da qualcuno ben intenzionato ma in realtà non così ben informato), ma tutti dovrebbero cercare di dare buoni esempi.

Sicuramente evitare le lotte di potere. Non c'è niente di peggio di un piccolo Hitler nella tua squadra che cerca di costringere tutti alla sua volontà. E questo è sfortunatamente il ragazzo che si offrirà volontario per scrivere i tuoi standard di codifica: - (

Tutti gli esempi che hai fornito riguardano fondamentalmente lo spazio e la formattazione. Se questo è il problema più grande, sono d'accordo con il tuo manager: non è un grosso problema.

Dove gli standard sono davvero molto utili è con i nomi e riducendo la complessità. Come nominare identificatori, classi, dove metterli, ecc. Mantenere i nomi coerenti è estremamente importante, specialmente in un grande progetto . Le regole per ridurre la complessità includono tenere le funzioni sotto un certo numero di righe (scomporle in funzioni più piccole) o mantenere gli elenchi di parametri sotto un certo numero di argomenti (forse dovresti raggrupparli in un oggetto e passarlo intorno).

Se uno sviluppatore specifico del tuo team scrive codice che è più difficile da capire / debug perché include molti pezzi lunghi di codice con nomi di variabili a lettera singola, questa è una buona ragione per adottare alcuni standard, e non qualcosa che può essere corretto con uno script Questa è una buona cosa da sottolineare (con tatto) come una cosa che gli standard possono migliorare.

Un altro motivo per cui il tuo manager potrebbe non vederlo come un problema è che in realtà non leggi i codici degli altri molto spesso. Questo può accadere quando tutti hanno una propria area del codice e non non osare troppo al di fuori di esso. Funziona abbastanza bene fino a quando qualcuno non lascia l'organizzazione, cosa che potrebbe accadere per una serie di buone o cattive ragioni. Gli standard che aiutano la leggibilità renderanno più semplice per un nuovo sviluppatore prendere in carico la manutenzione di un pezzo di codice.

conflicts when I merge because someone used their IDE to auto format and they use a different character to indent than I do

sembra che questo sia il tuo problema, non la formattazione, ma la riformattazione. Questo è un grosso problema per le SCM e il consiglio è semplice: non farlo. Quindi la prossima volta che qualcuno ridisegna tutti gli spazi alle schede o rifatta le parentesi graffe sul loro stile preferito, è necessario schiacciarle. Fagli fare invece l'unione; stenderci sopra a guardare disapprovando la perdita di tempo che la loro spensieratezza ha causato.

L'alternativa è mettere un formattatore di pre-commit, che riformatta sempre tutto il codice nello stile standard prima di effettuare il check-in. Se hai una squadra di sviluppatori che si riformatta di conseguenza, questa è una buona opzione: lo SCM vedrà sempre lo stesso formato, quindi i delta saranno piccoli e piacevoli da unire.

Quando qualcuno suggerisce un nuovo standard di codifica su cui lavoro, votiamo su questo. Se ottiene un voto a maggioranza è accettato altrimenti è respinto. Se non lo fai, non comprerai i tuoi standard e non saranno utilizzati anche se sono documentati.

A partire dal tuo problema specifico, la tua migliore scommessa probabilmente inizierà con il suggerimento di Joel e darà l'esempio. Raccogli 1 o 2 programmatori che si preoccupano di questo, raggiungi un accordo e avrai un po 'di forza da imporre ai più pigri.

Ora, per il problema generico, trovo meglio semplicemente modulare . Ogni persona riceve un file diverso, se si deve dare manutenzione a un file si mantiene intatti gli standard di codifica, anche se è diverso dall'altro. Hai bisogno di scrivere nello stesso file? Crea un file secondario e includilo.

Non provarlo!

Esemplare per esempio. Cerca di rendere il tuo codice il più orribile possibile e di apportare modifiche orribilmente formattate al grazioso codice di altre persone. Quando si verifica la (inevitabile) reazione, dì che quello che stai facendo va bene perché non esiste uno standard di codifica.

Se non ti vengono linciati dai tuoi colleghi (!!), potresti finire con uno standard di codifica.

Ovviamente, questa è una strategia ad alto rischio ...: -)