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

7

In primo luogo un po 'di background: il mio attuale manager di sviluppo sta cogliendo un'altra opportunità alla fine di questa settimana, lasciando il nostro team con quattro sviluppatori a tempo pieno, uno stagista part-time e un web designer (che è tecnicamente parte del Marketing, non AppDev ). Al momento non stiamo promuovendo o assumendo un nuovo manager.

Il precedente manager non si è mai preso il tempo di elaborare una serie di standard di codifica da rispettare (per metterlo in prospettiva: il mio anniversario di un anno in questo lavoro è tra due settimane e ho parlato con lui sugli standard da quando ho iniziato). A causa di questo, tutti noi quattro sviluppatori scriviamo il codice a modo nostro: alcuni di noi seguono le convenzioni di denominazione Microsoft per .NET, alcuni usano la notazione ungherese, alcuni usano un mix (ad esempio mix PascalCase e camelCase per i nomi dei parametri) , ed è del tutto casuale quando apri un file di codice quale sarà lo standard che seguirà - l'unica cosa consistente è che le parentesi graffe si trovano su linee separate.

Due dei miei tre colleghi mi hanno contattato per creare un documento standard di codifica che possiamo usare e far rispettare in avanti (anche se tecnicamente non sono lo sviluppatore più anziano, il quarto sviluppatore è qui da diversi anni, due i colleghi di lavoro e lo stagista mi considerano un consiglio / orientamento, ma non abbiamo un team leader). Avevo intenzione di farlo per un po ', ma il manager che partiva ora lo metteva sempre sul backburner; la sua partenza ora ci dà la possibilità di prendere un po 'di tempo e configurare le cose correttamente per facilitare un ambiente software corretto e non il guazzabuglio affrettato che abbiamo attualmente.

Come dovrei fare questo e introdurre questo standard nella mia squadra senza causare attriti? Non voglio far sembrare che sto "rilevando", anche se mi è stata offerta la posizione di manager, l'avrei accettata. Come ho detto due su tre altri sviluppatori sono a bordo con me creando uno, ma il quarto (il vero "senior" in termini di tempo) può o non può accettarlo. Ho in programma di iniziare con le convenzioni .Net di Microsoft (ad esempio non utilizzare la notazione ungherese), aggiungere alcune preferenze personali (ad esempio _camelcase per i campi) e richiamare in modo specifico alcune strane pratiche che usiamo qui per non essere utilizzate (ad es. una classe con un carattere di sottolineatura all'inizio), ma cos'altro dovrei includere? Non voglio entrare nelle linee guida dell'architettura perché causerà attriti e abbiamo una base di codice molto ampia e maleodorante che non aderirebbe ad essa, e non siamo affatto vicini al punto di venire con una strategia di refactoring.

Per riassumere: oltre le convenzioni di denominazione di base, cosa dovrei includere in un documento di standard di codifica (esempi sarebbero grandi - non sono riuscito a trovare esempi concreti di come dovrebbe essere un documento del genere), e come dovrei presentarlo alla mia squadra senza sembrare il nuovo dittatore.

    
posta Wayne Molina 19.12.2011 - 21:31
fonte

8 risposte

10

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.

    
risposta data 19.12.2011 - 21:38
fonte
6

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".

    
risposta data 19.12.2011 - 23:59
fonte
4

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.

    
risposta data 19.12.2011 - 21:45
fonte
1

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.

    
risposta data 19.12.2011 - 22:08
fonte
1

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.

    
risposta data 20.12.2011 - 11:57
fonte
0

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.

    
risposta data 19.12.2011 - 21:45
fonte
0

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:

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.

    
risposta data 19.12.2011 - 21:47
fonte
0

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() .

    
risposta data 19.12.2011 - 22:30
fonte

Leggi altre domande sui tag