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

Lavoro in una piccola squadra, circa 10 sviluppatori. Non abbiamo affatto standard di codifica. Ci sono alcune cose che sono diventate la norma, ma alcuni modi di fare le cose sono completamente disparati. Il mio grande è il rientro. Alcuni usano le schede, alcuni usano gli spazi, altri usano un diverso numero di spazi, il che crea un enorme problema. Spesso mi ritrovo in conflitti quando mi unisco perché qualcuno ha usato il proprio IDE per formattare automaticamente e usa un carattere diverso per rientrare rispetto a me. Non mi interessa quale usiamo, voglio solo che tutti usiamo lo stesso.

Altrimenti aprirò un file e alcune righe hanno parentesi graffe sulla stessa riga della condizione mentre altre le hanno sulla riga successiva. Ancora una volta, non mi importa quale a condizione che siano tutti uguali.

Ho sollevato la questione degli standard per il mio direttore diretto, uno contro uno e durante le riunioni di gruppo, e non è eccessivamente preoccupato per questo (ce ne sono molti altri che condividono la mia stessa opinione). Ho sollevato la mia specifica preoccupazione per i personaggi di rientro e ha pensato che una soluzione migliore sarebbe stata quella di "creare una sorta di sceneggiatura che potesse convertire tutto ciò quando spingiamo / estraggiamo dal repository". Ho il sospetto che non voglia cambiare e questa soluzione sembra eccessivamente complicata e soggetta a problemi di manutenzione lungo la strada (inoltre, risolve solo una manifestazione di un problema più ampio).

Qualcuno di voi ha incontrato una situazione simile al lavoro? Se sì, come hai fatto a gestirlo? Quali sarebbero alcuni punti positivi per aiutare a vendere il mio capo sugli standard? Avvio di un movimento di base per creare standard di codifica, tra quelli di noi interessati, sarebbe una buona idea? Sono troppo particolare, dovrei lasciarlo andare?

Grazie a tutti per il vostro tempo.

Nota: grazie a tutti per l'ottimo feedback finora! Per essere chiari, non voglio dettare uno stile per dominarli tutti. Sono disposto a concedere il mio modo preferito di fare qualcosa a favore di ciò che si adatta meglio a tutti. Voglio coerenza e voglio che questa sia una democrazia. Voglio che sia una decisione di gruppo su cui tutti sono d'accordo. È vero, non tutti riusciranno, ma spero che tutti siano abbastanza maturi da scendere a compromessi per il miglioramento del gruppo.

Nota 2: alcune persone vengono coinvolte nei due esempi che ho dato sopra. Sono più interessato al nocciolo della questione. Si manifesta con molti esempi: convenzioni di denominazione, enormi funzioni che dovrebbero essere interrotte, se qualcosa dovesse andare in un util o servizio, se qualcosa dovesse essere una costante o iniettata, dovremmo tutti usare versioni diverse di una dipendenza o la stessa, se un interfaccia da utilizzare in questo caso, come devono essere impostati i test unitari, cosa dovrebbe essere testato unitariamente (specifico di Java) se dovremmo usare le annotazioni o la configurazione esterna. Potrei andare avanti.

Un collega e io abbiamo avuto un problema simile nella nostra squadra quando ci siamo uniti per la prima volta (mi sono unito alla squadra per primo, si è unito circa un anno dopo). Non c'erano standard di codice reali. Siamo un negozio MS e non sono stati utilizzati nemmeno gli standard di codifica MS. 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. Quindi lui e io abbiamo concordato di seguire esplicitamente lo standard. Ho inviato un'e-mail al team (da entrambi) e ho comunicato loro che avevamo riscontrato una mancanza e che avremmo risolto la mancanza con il nostro documento. Abbiamo invitato critiche, idee, commenti, opinioni. Abbiamo ricevuto pochissimo feedback e solo un piccolo respingimento. Lui e io abbiamo subito iniziato a utilizzare gli standard, e quando abbiamo coinvolto sviluppatori junior nei nostri progetti, li abbiamo introdotti allo standard e hanno iniziato a usarlo. Abbiamo alcuni indizi inizialmente riluttanti, ma che hanno lentamente iniziato a utilizzare lo standard per molte cose.

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

Se vuoi standard, traccia il percorso. Fornisci un elenco suggerito di standard che ritieni possano essere utili alla tua squadra. Invialo a colleghi e lead per un feedback. Sono sicuro che altre persone nella tua squadra abbiano 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. Il team nel suo insieme dovrebbe essere d'accordo con gli standard. Se non riescono a concordare un insieme comune di standard, non riuscirà a convincere un manager a imporre gli standard su di essi.

Tu e gli altri che siete d'accordo con voi dovreste dare l'esempio. Inizia a utilizzare gli stessi standard di codifica, pubblicali e promuovili per il resto del team e invita feedback su come migliorarli.

Ecco la parte importante quando si cerca di promuovere gli standard: assicurarsi che l'obiettivo non sia trovare il modo migliore per fare le cose, ma piuttosto trovare un modo coerente di fare le cose. Per quanto alcune persone potrebbero non essere d'accordo, non esiste uno stile di parentesi graffa reale, uno stile di commento vero e proprio, ecc. Ciò che rende il codice più facile da leggere (e quindi più facile da mantenere) è uno stile coerente, non importa quale sia.

Puoi mostrare alcune prove del tempo che hai perso a causa dei problemi che ciò sta causando?

Se stai impiegando molto tempo a risolvere questi problemi, o se sta causando bug che richiedono tempo per essere risolti, questo è un costo che puoi ridurre drasticamente adottando standard di codifica.

Tieni quindi un registro dei problemi che incontri e del tempo necessario per risolverli, sia per te che (dove ne sei a conoscenza) i tuoi colleghi.

Quindi quando hai una quantità ragionevole di dati presentali ai tuoi colleghi. Dovrebbero vedere il vantaggio di adottare uno standard. In caso contrario, mostra i dati al tuo capo e al suo capo. Dimostra che disponendo di standard di codifica puoi risparmiare i soldi della tua azienda e dovrebbero sostenerti nel farli adottare.

Sulla tua situazione particolare, penso che la soluzione del tuo capo sia valida. 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 fino a quando il codice è leggibile. Se tutti facessero un formattazione automatica al loro stile al momento del check out e un formattazione automatica ad uno stile standard al momento del check-in, tutto andrebbe bene. (Purtroppo ho suggerito che dove lavoro e si è opposto per il 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 buoni quando applicati a luoghi in cui fa davvero la differenza nella qualità del codice: ad esempio metodi piccoli, classi che hanno una responsabilità chiaramente dichiarata, commenti utili e accurati per i bit più difficili, ecc. Sfortunatamente, quegli aspetti sono più difficili da controllare automaticamente, ma è fondamentale per lo sviluppo del software. Tutto quello che puoi davvero fare è insegnare agli altri buone pratiche e insegnare a te stesso a leggere il codice con la parentesi sulla riga sbagliata.

Per quanto riguarda gli 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 specifico stile di rientro, fino al numero di personaggi (e quando i progetti vanno così lontano, inevitabilmente scelgono qualcosa di stupido come 8 rientri spaziali). Non sudare le piccole cose.

Una soluzione semplice: fornire agli sviluppatori una serie limitata di scelte per parentesi graffa e rientro, ma imporre che lo stile di parentesi graffa e il rientro devono essere coerenti in un modulo. (Vuoi che foo.h e foo.cpp seguano lo stesso stile, vero?) I manutentori devono adattarsi allo stile esistente; non possono riscrivere un modulo per adattarsi al loro stile stravagante. Più stili all'interno di un modulo sono semplicemente confusi ed è un segno di sciattezza. Quando vedo questa assurdità, mi chiedo cos'altro c'è che non va.

Potresti anche pensare a vietare le schede per il rientro nei contenuti salvati di un file . La maggior parte degli IDE / editor fa un lavoro ragionevole traducendo le schede di input dell'utente in spazi e la maggior parte ha opzioni per rendere automatica quella traduzione. Molti fanno un lavoro schifoso quando il file contiene già schede, in particolare un miscuglio di schede e spazi.

Detto questo, penso che potresti avere un problema più profondo nel tuo progetto. Hai menzionato problemi con l'unione. Se ti ritrovi a dover fare molta fusione, potrebbe essere un segno di un cattivo partizionamento del progetto. Proprio come troppi cuochi rovinano il brodo, troppi programmatori che operano sullo stesso file rovinano il progetto. Perché ognuno di voi, Susie e voi toccate foo.cpp?

Questa è una delle aree in cui vengono condotte alcune ricerche. Fondamentalmente la domanda principale è se stai facendo recensioni di 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 aggiuntivo.

Ora, le revisioni del codice beneficiano di uno standard di codifica comune, in quanto ciò semplifica la lettura del codice di altre persone. Ciò fornisce un argomento in due passaggi per introdurre standard di codifica: alla fine, rende più economico produrre un buon codice.

Dato che ci sono già "molti altri" che sono con te su questo, suggerirei un incontro improvvisato. Invita tutti gli sviluppatori, prenditi un po 'di tempo e scopri quali cose disturbano te e i tuoi colleghi ogni giorno. All'inizio non cercare di trovare soluzioni specifiche, cerca solo di capire cosa deve cambiare nel modo in cui stai scrivendo il codice al momento.

Quindi, vedi se riesci a concordare tutti alcuni concetti di base. Il suggerimento di utilizzare lo stesso stile all'interno di ciascun modulo che @David Hammen ha sollevato è un buon inizio, e penso che la maggior parte degli sviluppatori potrebbe essere immediatamente d'accordo.

Se, una volta che hai quella pat, senti che puoi essere d'accordo su uno stile di base per quando scrivi un nuovo codice, questa è una buona aggiunta. Concentrarsi su cose che incidono effettivamente sulla manutenibilità; I problemi di denominazione sarebbero in cima alla mia lista personale perché se hai una mezza dozzina di stili di denominazione diversi in un singolo prodotto di qualsiasi notevole complessità, diventerà un mal di testa molto rapidamente, ma di nuovo, concentrati su ciò che tu e il tuo team ritenete importante . Redigere un breve documento che tutti possano almeno concordare di seguire (anche se potrebbero avere uno stile diverso per animali domestici) e inviarlo a tutti i membri del team. Trasformalo in un documento "vivente", assicurati di aggiornarlo con il 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 (a condizione che si concentri sulla leggibilità e sulla manutenibilità), ma dovrebbe essere in grado di vedere i benefici di tutti i membri del team seguendo uno stile comune quando si scrive il codice.

Ci sono alcune cose che sono dolorose. Il più doloroso è un IDE che riformatta automaticamente il codice, combinato con gli sviluppatori che hanno impostato i loro IDE in diversi modi. Ogni volta che confronti il ​​codice hai centinaia di modifiche dopo che qualcuno con impostazioni diverse ha modificato il codice. Questo è inaccettabile. Qui devi battere la testa di tutti, concordare una serie di impostazioni e rifiutare qualsiasi check-in da parte di chiunque utilizzi impostazioni diverse. Se cambio una singola riga di codice, le differenze 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 tu non lo migliori davvero. E un mix di stile A e stile B è sempre peggio sia dello stile A che dello stile B.

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

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

Tutti gli esempi che hai fornito riguardano essenzialmente spazi bianchi e formattazione. Se questo è il problema più grande, sono in qualche modo d'accordo con il tuo manager: non è un grosso problema.

Laddove gli standard sono davvero molto utili è la denominazione delle cose e la riduzione della complessità. Come nominare identificatori, classi, dove metterli, ecc. Mantenere coerenti i nomi è estremamente importante, specialmente in un grande progetto. Le regole per ridurre la complessità includono mantenere le funzioni in un certo numero di righe (suddividerle in funzioni più piccole) o mantenere gli elenchi di parametri al di sotto di un certo numero di argomenti (forse dovresti raggrupparli in un oggetto e passarlo in giro).

Se uno sviluppatore specifico nel tuo team scrive un codice che è più difficile da comprendere / eseguire il debug perché include molti blocchi di codice lunghi con nomi di variabili a lettera singola, questa è una buona ragione per adottare alcuni standard e non qualcosa che può essere risolto con un copione. È una buona cosa 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 molto spesso il codice degli altri. Ciò può accadere quando ognuno ha la propria area del codice e non si avventura troppo al di fuori di esso. Funziona abbastanza bene fino a quando qualcuno lascia l'organizzazione, cosa che potrebbe accadere per una serie di ragioni buone o cattive. Gli standard che aiutano la leggibilità renderanno più semplice per un nuovo sviluppatore la gestione di un pezzo di codice.

è in conflitto quando mi unisco perché qualcuno ha usato il proprio IDE per formattare automaticamente e usa un carattere diverso per rientrare rispetto a me

sembra che questo sia il tuo problema, non la formattazione, ma la riformattazione. Questo è un grosso problema per gli SCM e il consiglio è semplice: non farlo. Quindi la prossima volta che qualcuno riformatta tutti gli spazi in tabulazioni o trasforma le parentesi graffe nel loro stile preferito, devi schiaffeggiarle. Fagli invece fare l'unione; sorvolare su di loro cercando di disapprovare lo spreco di tempo causato dalla loro spensieratezza.

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

Quando qualcuno suggerisce un nuovo standard di codifica in cui lavoro, votiamo su di esso. Se ottiene il voto di maggioranza viene accettato, altrimenti viene respinto. Se non lo fai, non otterrai acquisti secondo i tuoi standard e non verranno utilizzati anche se sono documentati.

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

Ora, per il problema generico, trovo che sia meglio modulare semplicemente . Ogni persona ottiene un file diverso, se devi dare la manutenzione a un file mantieni intatti i suoi standard di codifica, anche se è diverso dall'altro. Devi scrivere nello stesso file? Crea un file di sottoinsieme e includilo invece.

Non provarlo!

Dare il buon esempio. Prova a rendere il tuo formato di codice il più orribile possibile e controlla molte modifiche formattate in modo orribile 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 vieni linciato dai tuoi colleghi (!!), potresti finire con uno standard di codifica.

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