Come gestire diversi stili di programmazione in una squadra?

Abbiamo un piccolo team di sviluppatori (solo 3 sviluppatori) e recentemente abbiamo ottenuto un nuovo membro del team. Mentre è un programmatore intelligente, il suo stile di codifica è completamente diverso dal nostro. La nostra base di codice esistente contiene codice per lo più leggibile, pulito e gestibile, ma il nuovo membro del team sta cambiando rapidamente molti file, introducendo brutti hack e scorciatoie, usando definizioni ovunque, aggiungendo funzioni in luoghi sbagliati, ecc.

La mia domanda è se altri hanno già vissuto una situazione del genere prima e se qualcuno ha suggerimenti su come parlargli.

Lavoro con un team che è passato da 2 sviluppatori a 10 in meno di un anno. Ero il numero 3 e il primo a sollevare un problema relativo agli standard di codifica. I due sviluppatori originali hanno lavorato fianco a fianco per alcuni anni e avevano adottato uno standard comune che mi sembrava estraneo. Abbiamo avuto esattamente gli stessi problemi che stai descrivendo.

Quello che abbiamo fatto è stato:

Standard di codifica per la ricerca

Abbiamo trascorso alcuni giorni a verificare progetti open source affermati. Sapevamo che il team si sarebbe espanso rapidamente e stavamo cercando soluzioni reali basate su progetti reali e non su linee guida generiche. Inoltre non ci importava degli standard di codifica ottimali, ma di un insieme di regole e linee guida che avrebbero senso e non richiederebbero il refactoring di tutto il nostro codice di base. Stavamo cercando un hack per gli standard di codifica, se vuoi.

Noi tre abbiamo deciso che i migliori standard di codifica disponibili per un progetto PHP consolidato erano quelli seguiti da Zend Framework. Fortunatamente le persone di Zend Framework forniscono un documento sugli standard di codifica molto completo .

Creare i nostri standard di codifica

Ovviamente applicare gli standard di codifica di un altro progetto sul nostro progetto così com'è non ha senso. Usiamo il documento Zend Framework come modello:

• Per prima cosa abbiamo rimosso tutto ciò che non si applicava al nostro progetto
• Quindi abbiamo cambiato tutto ciò che abbiamo percepito come una questione di stile nel nostro stile
• E finalmente abbiamo scritto tutto

Quindi avevamo un documento abbastanza grande a portata di mano, memorizzato nella nostra fantasia wiki , è stata una bella lettura, concordata da tutti noi. E completamente inutile da solo.

Rimanere fedele alla nostra promessa

La nostra base di codice al momento era di circa 1 * 10 ^ 6 sloc. Sapevamo che da quando abbiamo adottato gli standard di codifica formali abbiamo dovuto iniziare a refactoring del nostro codice, ma al momento siamo stati spinti su altri problemi. Quindi abbiamo deciso di riformattare le nostre librerie di base, un semplice sloc 5 * 10 ^ 3.

Abbiamo assegnato uno di noi a essere il maestro degli standard di codifica (abbiamo usato volgarità locale al posto del maestro ) con la responsabilità di verificare e far rispettare gli standard. Ricicliamo il ruolo ogni pochi sprint. Sono stato il primo, ed è stato un sacco di lavoro, poiché ho dovuto monitorare quasi ogni impegno.

Abbiamo avuto diverse nuove discussioni e piccoli addendum al documento originale durante il mio mandato, e alla fine abbiamo avuto un po ' documento stabile. Lo cambiamo di tanto in tanto, ma la maggior parte di questi cambiamenti riguardano nuove funzionalità del linguaggio, in quanto PHP 5.3 è stato un rilascio importante in tutti tranne che nel nome.

Trattare con il nuovo ragazzo

Quando arrivò il nuovo ragazzo, era tempo di mettere alla prova i nostri standard di codifica. Dopo una breve introduzione alla nostra base di codice, gli abbiamo chiesto di valutare il nostro documento sugli standard di codifica. Ha quasi pianto. Sembrava che avesse fatto tutto diversamente.

Dato che all'epoca ero il maestro degli standard di codifica, dipendeva da me valutare il suo contributo e rivedere il documento di conseguenza. Le sue proposte erano:

• Questioni di stile personale (respinte sommariamente)
• Standard che avevano senso per il suo background Java ma non così tanto con PHP (respinto)
• Convenzioni che ha portato dalla sua breve esposizione con PHP (alcune sono state respinte, ma molte si sono rivelate convenzioni popolari che non abbiamo mai pensato o scoperto nella nostra ricerca iniziale)

Per le prossime due settimane gli fu assegnato un compito semplice: aggiornare diverse parti della nostra base di codice con gli standard. Ho dovuto scegliere con cura quelle parti in base ad alcune regole:

• Il codice dovrebbe essere relativamente facile per qualcuno che non ha familiarità con la nostra base di codice (e PHP in generale)
• Il codice dovrebbe essere su ciò che è stato assunto per fare

Ho monitorato il suo processo e ha fatto un ottimo lavoro. Abbiamo identificato diverse parti del codice impossibili da adattare al nostro documento e revisionate di conseguenza (codice e / o standard, a seconda di quale avesse più senso)

E poi è arrivato un altro ragazzo nuovo. Abbiamo ripetuto il processo (questa volta un master diverso) e ha funzionato di nuovo. E di nuovo.

In conclusione

1. Crea un documento sugli standard di codifica, ma assicurati che i tuoi standard non siano esclusivamente tuoi, ma riflettano standard comuni nella più ampia comunità della tua piattaforma.
2. Assegna un ruolo simile al nostro master per gli standard di codifica. Qualcuno per monitorare almeno il nuovo codice, e in particolare il nuovo codice dai nuovi membri. Ricicla il ruolo, poiché è estremamente noioso.
3. Valuta sempre l'input di un nuovo membro. Rivedi sempre i tuoi standard se ha senso. Il documento relativo agli standard di codifica dovrebbe evolversi, ma lentamente. Non vuoi ri-refactificare il tuo codebase ad ogni iterazione.
4. Concedi un po 'di tempo affinché ogni nuovo membro apprenda e si adatti ai tuoi standard e alle tue convenzioni. Impara facendo le opere migliori in queste situazioni.
5. Wiki fa miracoli per tali documenti.
6. Le revisioni del codice fanno miracoli per ogni situazione!

Ad un certo punto del processo è stato suggerito di utilizzare un hook pre-commit per automatizzare il controllo degli standard. Abbiamo deciso di non farlo per una serie di motivi, ci sono alcune discussioni interessanti su StackOverflow sul problema:

• Formattazione automatica del codice SVN al momento del check-in?
• Controllo della versione e formattazione del codice
• PHP codesniffer (phpcs) - come consentire l'override quando si utilizza come parte di un hook pre-commit svn?
• Hook pre-commit SVN da attivare per una determinata cartella
• Implementazione di standard di codifica PHP

Alcuni sono specifici di PHP, ma le risposte si applicano a tutte le piattaforme.

Sì, l'ho già provato. Quando lavorano in una squadra, i membri della squadra devono concordare determinate regole e convenzioni, e questo include lo stile.

Dovresti far sedere la tua squadra insieme e redigere una serie di regole, standard di codifica , a cui dovrai aderire ad ogni parte del codice registrato.

Molto probabilmente, la base per il tuo set di regole, almeno per quanto riguarda lo stile, sarebbe il codice esistente. Una volta fatto, tutti devono conformarsi e dovrebbe essere ispezionato come parte della revisione del codice . Il codice che non rispetta gli standard non deve essere controllato.

Non deve essere un voto democratico, tra l'altro, è una delle cose in cui il caposquadra può effettivamente eseguire una certa autorità. Detto questo, non penso che tu possa imporre standard che la maggior parte della squadra rifiuta. È possibile imporre standard che una singola persona, specialmente una nuova, rifiuta.

Come parlare con lui ... Ogni programmatore esperto sa che ogni posto e squadra ha le sue convenzioni e il suo stile, che dovrebbero essere seguiti. Puoi dirgli che è più che benvenuto nel suggerire miglioramenti, ma deve rispettare le regole del team e non dovrebbe cambiare lo stile del codice esistente ma piuttosto usare lo stesso stile quando aggiunge un nuovo codice.

Inoltre, puoi dire (se sei il manager o parlarne con il tuo manager) a quella persona di non fare determinate cose che ritieni inappropriate (hai menzionato le definizioni, l'ordine, gli hack e le scorciatoie e così via).

1. Qualcuno è responsabile - devono comportarsi come tali.
2. Se lo stile di programmazione è così importante, perché questo non è stato spiegato a questa persona e far loro sapere che non avranno accesso a nessun codice fino a quando non impareranno le regole.
3. Revisione del codice - apparentemente non ne hai o è molto debole. Vedi # 1.

Prendi nota nel tuo processo di assunzione, che seguire gli stili di codifica accettati è un requisito per l'occupazione. Cosa fai a coloro che non seguono le regole? Inizia rimuovendo il loro accesso al codice live fino a quando non ottengono con il programma.

.

Ecco cosa si può fare:

1. Scrivi un documento che spiega lo stile di codifica richiesto e fai in modo che tutti i membri del team lo imparino. Raccogliere informazioni da ogni membro del team.
2. dividere i compiti in modo tale che ogni membro del team sia responsabile del proprio pezzo e possa decidere le convenzioni di quella parte del codice. Se vengono rilevati problemi, chiunque lo abbia scritto risolverà i problemi.
3. aggiungere uno strumento automatico al controllo versione che corregge rientri e altre cose ogni volta che il codice viene impegnato nel controllo versione
4. Programmatori diversi hanno sempre stili di programmazione diversi e in seguito può essere difficile cambiare. Il modo migliore per gestirlo è condividere le informazioni tra i membri del team in modo che tutti imparino quali stili le persone hanno usato. Se hai un membro del team che scrive codice diverso, è una possibilità per i membri del tuo team esistente di imparare il nuovo stile.
5. Un buon trucco è non modificare mai il codice esistente. Invece di modificare il codice, scrivere un nuovo codice sostituendo le righe vuote con un nuovo codice. E una volta che il codice è pronto, apportare solo la minima quantità di modifiche al sistema esistente per utilizzare il nuovo codice. Questo evita di modificare il codice esistente, eventualmente rompendo ciò che già funzionava bene.

Ecco cosa evitare:

1. decidere che il codice di qualcuno è migliore o peggiore rispetto agli altri membri del team. Semplicemente non funziona così: tutti conoscono un certo sottoinsieme della lingua abbastanza bene da usarlo nel codice. Ogni programmatore ha scelto un sottoinsieme diverso da imparare e, a meno che non lo abbiano imparato insieme, sembrerà diverso.
2. Cambiare il modo in cui qualcuno scrive il codice. Tutto ciò che ottieni forzando le persone a scrivere uno stile non familiare è che ottieni una grande quantità di bug nel codice. Le persone semplicemente non conoscono abbastanza dettagli di qualcosa che usano la prima volta. I programmatori scelgono sempre un sottoinsieme di linguaggio e lo usano da solo. Se i tuoi programmatori hanno scritto migliaia di righe di codice piene di goto, allora le goto ti daranno il codice con il minor numero di bug.
3. Inoltre, non dovresti pensare che la tua base di codice esistente sia roba piacevole, pulita e gestibile. C'è sempre qualcosa da migliorare. Ma anche ogni cambiamento offusca l'idea di design originale che gli è stata scritta. Cerca di scrivere il codice perfetto la prima volta, in modo che le modifiche non siano necessarie in seguito. (il nuovo ragazzo non avrebbe bisogno di "rompere" il tuo codice perfetto, se è stato fatto correttamente la prima volta)

La nostra base di codice esistente contiene principalmente codice leggibile, pulito e gestibile

Una cosa che ho imparato negli anni è che la leggibilità è negli occhi di chi guarda. Ho visto molti casi in cui lo stile di codifica del pulcino di qualcuno è giustificato come "leggibile", e ho visto persone perfettamente ragionevoli discutere su quali stili di codifica sono i più "leggibili". Forse questo ragazzo non vede il tuo stile come leggibile?

Detto questo, il nuovo ragazzo dovrebbe conformarsi ai tuoi standard, non viceversa.

Prendi in considerazione l'utilizzo di richieste pull per il nuovo codice nel repository. Questo offre un posto comodo per fare la revisione del codice. Il codice che non supera la revisione del codice non viene unito nel repository fino a quando non è in forma.

Fai solo attenzione a non rendere le richieste pull troppo grandi. Nella mia esperienza, non dovrebbero essere più grandi di tra mezza giornata a un massimo di due giorni o avrai troppi conflitti di unione.

I sistemi vcs online come bitbucket o github supportano questa funzionalità. Se preferisci un approccio on-premise, la scorta sembra la migliore scommessa al momento.

C'è una semplice regola che puoi seguire: se modifichi un file con codice, usi lo standard di codifica usato in quel file. Se si crea un nuovo file, si utilizza qualsiasi buon standard di codifica. (Inoltre: se il compilatore può fornire avvisi, abiliti tutti gli avvisi ragionevoli, attiva gli avvisi = errore se possibile e non consente alcun codice con avvisi. Inoltre: Se utilizzi strumenti che apportano modifiche all'ingrosso in un file, come la modifica schede per spazi o simili, NON usarli).

Il motivo per cui ci sono enormi argomenti sugli standard di codifica è che uno standard non è migliore o peggiore di un altro (di solito) ma solo diverso. L'unica cosa davvero negativa è mescolare stili di codifica.

Ovviamente mi aspetto che qualsiasi programmatore decente possa scrivere codice seguendo qualsiasi standard di codifica, che preferisca o meno quel particolare standard.

E d'altra parte, ci sono standard di qualità. Non accettare mai codici che non soddisfano i tuoi standard di qualità.