Come dovrei introdurre uno standard di codifica per il mio team?

How should I go about doing this and introducing this standard to my team without causing friction?

Dici anche:

Two out of my three co-workers have approached me to create a standard coding document that we can use and enforce moving forward

Sembra che tu abbia già un certo buy-in dalla maggior parte della squadra. Fai la creazione del documento qualcosa che è fatto da tutti voi (tutti e quattro se possibile). Se questo richiede troppo tempo, crea il tuo documento e mostralo come una bozza ai tuoi colleghi. Una volta che tutti avete concordato e finalizzato una versione che siete a posto.

Un buon punto di partenza è uno sguardo alle diverse stylecop regole - non devi rispettarle tutto, ma questi ti daranno un'idea di cosa dovrebbe contenere il tuo documento. Come ulteriore vantaggio, puoi facilmente implementare stylecop nelle tue soluzioni e persino integrarlo in una build automatizzata (in caso di violazione della build in caso di violazioni).

Per riassumere:

Guarda gli strumenti e gli standard esistenti per decidere cosa vuoi nel tuo.

Per evitare di sembrare un dittatore, rendi la modifica una collaborazione.

Beyond basic naming conventions what, if anything, should I include in a coding standards document

Niente.

Prenditi il tuo tempo. Vai piano. Non perdere tempo a scrivere. Convenzioni di codifica only funzionano quando fanno parte della cultura comune.

Se non fanno parte della cultura, vengono semplicemente ignorati.

How should I go about doing this and introducing this standard to my team

Recensioni del codice. È un ottimo posto per introdurre il problema risolto dalle convenzioni di codifica.

La maggior parte delle volte le convenzioni sono semplicemente una perdita di tempo. Quando hai un problema reale (ad es. Programmi illeggibili) che puoi risolvere tramite convenzioni di codifica, puoi raggiungere rapidamente il 100% della conformità.

Le convenzioni di codifica che sono semplicemente preferenze personali non risolvono un problema. E infatti, durante una revisione del codice, potresti scoprire qualcosa di meglio e in realtà cambiare le tue preferenze personali.

Non canonizzare troppo in un documento di convenzioni di codifica. Lavorare in modo cooperativo per arrivare a una comprensione comune.

I don't want to get into architectural guidelines as that will cause friction and we have a very large, and smelly, existing codebase that wouldn't adhere to it,

Cattiva politica.

Uno standard di architettura è mai qualcosa con adesione al 100%. Non può essere. È sempre una descrizione "lungimirante", verso cui evolve lo sviluppo.

Ogni buona idea architettonica porterà a una nuova direzione architettonica. E questo è l'aspetto dell'innovazione: un percorso, non un obiettivo.

and we're nowhere near at the point of coming up with a refactoring strategy.

Buona. Non svilupparne uno. Con questo intendo "non soffocare l'innovazione scrivendo troppe cose che potrebbero o meno essere l'approccio migliore possibile".

Con qualcosa come le convenzioni di codifica, direi che ogni convenzione specifica dovrebbe essere al 100% unanime o trovare una via di mezzo che la renda al 100% unanime.

• Imposta una scadenza per il completamento del documento, questo costringerà gli altri a prenderlo sul serio.

• Esegui il lavoro di compilazione del documento, nessuno ti sentirà come se ti stesse aiutando, ma se possiedi il lavoro allora nessuno ti batterà su di esso.

• Invia proposte per varie convenzioni di codifica basate su diversi stili che esistono ora nella base di codici. Raccogli feedback e organizza una riunione in cui possono essere votati.

• Nessuno lascia la riunione fino a quando ogni convenzione non ha raggiunto un accordo unanime al 100%

• Le nuove persone del team dovranno rispettare il documento e non avranno voce in capitolo. È come la Costituzione a quel punto.

Oh e nessuna notazione ungherese. Seriamente, preferirei scrutare i miei occhi piuttosto che guardare il codice in notazione ungherese.

Gli standard di codifica saranno una sfida da accettare. Ad alcune persone piace scrivere nella loro sandbox e fare le loro cose nonostante possa causare problemi se si rompe e altri stanno cercando di risolverlo.

Se stai usando Visual Studio con .NET, dai un'occhiata a StyleCop. È possibile utilizzare i set di regole predefiniti o scrivere i propri. Quindi fai in modo che tutti siano d'accordo prima che le revisioni del codice (se li hai) siano conformi alle impostazioni.

Da un punto di vista tecnico:

Fai notare le incoerenze che sono davvero un problema per il team e definisci le regole di codifica per risolvere questi problemi.

Da un punto di vista relazionale:

Se vuoi coinvolgere il senior, prendi ispirazione dalle sue convenzioni di codifica.

Finché non sei il nuovo manager della tua squadra, hai bisogno del consenso per avere uno standard di codifica (e se tu fossi il manager, dovresti davvero cercare di ottenere un consenso nel team prima di prendere una tale decisione "da sopra"). E può sembrare semplice, ma solo parlare - specialmente parlando con il quarto sviluppatore - può risolverlo.

Hai una società Wiki? Oppure, in caso contrario, un server su cui è possibile rilasciarne uno?

Se è così, crea una pagina. Chiamalo un documento vivente. Metti giù alcuni standard non contenziosi e incoraggia tutti gli altri a collaborare. Continuate ad aggiungere articoli ogni qualche settimana, incoraggiate la discussione ma in un modo che dice "se nessuno è in disaccordo, dovremmo aspettarci che questo venga seguito". Se puoi, convincere tutti a iscriversi ai documenti standard, in modo da poter vedere eventuali modifiche apportate dai colleghi.

Prova anche a convincere la squadra ad iniziare le revisioni del codice. Ogni lavoro passa attraverso due sviluppatori. Ciò incoraggerà la discussione e l'applicazione degli standard, e farà in modo che tutti siano uguali, non uno sviluppatore che impone le regole.

Modifica in risposta al commento:

Puoi vendere recensioni di codice come un modo per Dev # 4 per diffondere la sua saggezza. Anche quando il suo codice è in fase di revisione, è un'opportunità per le persone di vedere il suo codice magico e crogiolarsi in soggezione. In realtà, è un modo di promuovere la discussione. Dove il programmatore e il revisore non sono d'accordo, dovrebbe andare al team. Dove la squadra non può essere d'accordo, la ricerca dovrebbe essere fatta.

A proposito di ricerca, fai un po 'di revisione del codice. A nessuno la cui opinione conta tanto pensa che siano una cattiva idea. Mettilo in squadra, incluso il CIO, in una email con molti link. È difficile discutere contro di loro senza sembrare un idiota ostruzionismo.

Ecco alcuni per iniziare:

• link
• link
• link

Per quanto riguarda un Wiki, consiglierei davvero di dedicare del tempo a crearne uno (i wiki danno l'illusione della collaborazione, anche quando non è realmente lì). Ma se non è possibile, un documento di Word su un'unità condivisa farà il lavoro.

Gli standard per i commenti e gli spazi bianchi sono buoni, insieme agli strumenti per migrare tra diversi stili. Io uso le schede nel mio codice Python, che è considerato in cattivo stile. Tuttavia, una semplice funzione VIM converte tra i due se necessario.

Inoltre, pensa ai livelli di comprensione del codice. Lo scopo di uno stile è quello di comunicare informazioni al programmatore leggendo il codice. Se riesci a capire reduce(lambda x, y: x+y, map(lambda x: x + 1, theList)) , i tuoi colleghi preferiscono vedere:

for pos,item in enumerate(theList):
    theList[pos] = item + 1
tmp = 0
for item in theList:
    tmp = tmp + item

Quindi questo è importante per l'hash out. Lo stesso con lo spazio bianco. Devi capire quale livello di compressione del codice è a tuo agio.

Infine, come vengono tagliati i nuovi progetti e i progetti attuali? Una classe per file, le funzioni di utilità seguono uno schema di denominazione, nessuna variabile globale o dispersione dell'ambito, i file di progetto casuali sono ortogonali e vagamente accoppiati e così via. Ciò fornisce una base di comprensione importante per tutti. Non importa quale sia lo standard di codifica, se ogni progetto è così intrecciato che devo passare attraverso l'intera base di codice e davvero ingannare il progetto prima di twiddle foo() .