Gli standard / lo stile di codifica devono essere applicati dal server di integrazione continua che esegue strumenti di analisi statica (ad es. PMD, StyleCop / FxCop) e non riesce a costruire se gli standard non vengono seguiti? Quali tipi di regole non dovrebbero essere usati per fallire la compilazione?
Risposte:
Gli standard di codifica dovrebbero essere lì per un motivo ... e la non conformità dovrebbe essere verificata.
Tuttavia, non tutte le violazioni devono essere considerate come errori, proprio come non tutte le violazioni della compilazione. Dove si disegna la linea deve essere una società e una decisione strumento.
Ad esempio, MISRA definisce le sue regole come Obbligatorie e Advisory ... Suggerirei che Advisories consentirebbe alla costruzione di procedere.
Non è del tutto inaudito e saprai se funzionerà per te solo provandolo. Ci sono alcuni passaggi che potresti prendere prima.
Innanzitutto il team dovrebbe decidere insieme gli standard. Quindi strumenti come ReSharper dovrebbero essere utilizzati per dire agli sviluppatori se non aderiscono agli standard. Fare revisioni tra pari su ogni attività potrebbe aiutare ulteriormente.
Dopo aver eseguito tali passaggi, è possibile prendere in considerazione l'inserimento di controlli standard di codifica nel server CI. Tuttavia, dovrebbe essere ancora considerato se è saggio avere una pausa per non aderire agli standard di codifica. Il rischio è che avrai molte build rotte che potrebbero vanificare il significato di build rotte.
Invece di interrompere la compilazione, è possibile eseguire gli strumenti e fare in modo che creino report. Se le violazioni standard del codice sembrano aumentare, puoi riunire il team e capire perché sta accadendo.
Gli standard / lo stile di codifica devono essere applicati dal server di integrazione continua che esegue strumenti di analisi statica (ad es. PMD, StyleCop / FxCop) e non riesce a costruire se gli standard non vengono seguiti?
Tali controlli di integrazione continui devono essere molto, molto veloci. Eventuali ritardi significativi significheranno che i programmatori si impegneranno e perderanno traccia del loro processo di pensiero in attesa dei risultati. Prenderlo più a lungo e si impegneranno e prenderanno una tazza di caffè o chiacchiereranno con i loro compagni di ufficio sull'ultima prestazione confusa di alcune squadre sportive. Quei ritardi sono altamente controproducenti. È meglio lasciare alcune cose alla build notturna o alla revisione del codice.
Quali tipi di regole non dovrebbero essere usati per fallire la compilazione?
Quelle soggettive, per cominciare. Come imponi la regola "Il codice deve essere auto-documentato o ben commentato"? La regola "nessun numero magico"? Queste sono cose che è meglio lasciare alla revisione del codice.
Un'altra categoria sono le violazioni delle regole a cui è già stata concessa una deroga. Data qualsiasi base di codice considerevole, ci sarà inevitabilmente un pezzo di codice in cui la violazione dello standard è esattamente la cosa giusta da fare.
Nell'ambito di un piano di miglioramento della qualità del software, abbiamo recentemente codificato una serie di sniffer di codice da integrare nel nostro processo di creazione.
Costruiamo molto, essendo un'applicazione PHP non esiste una vera compilation quindi la build è davvero un test unitario / analisi statica / runner, e possiamo permetterci di spendere alcuni cicli su questo.
Abbiamo riscontrato alcuni problemi di qualità del codice e alcuni codici legacy con molti problemi.
Partendo dal presupposto che se non fallisce il commit verrà ignorato, abbiamo iniziato a confermare i commit rispetto al nostro standard di codice "desiderato", e fallendo commit con errori che non soddisfano lo standard.
La manutenzione si è fermata, anche la soluzione più semplice a un componente legacy ha richiesto allo sviluppatore di riformattare enormi quantità di sorgente e la build è stata interrotta il più delle volte. Inutile dire che abbiamo modificato gli errori in avvisi, e ora sono ignorati e "per lo più" inutili.
Quindi direi questo (imparato dalla dura esperienza).
Assicurati che lo standard della tua base di codice sia abbastanza vicino allo standard che imponi di non aver bisogno degli sviluppatori per riformattare volumi di codice, all'istante. Oppure .. Sei preparato e ti aspetti un aumento degli sforzi.
Essendo una piccola squadra con un enorme fabbisogno di consegna, non potevamo permetterci di passare alla grande operazione di re-factor. I nostri standard di codifica sono ora gestiti principalmente tramite revisione manuale e l'eredità viene riscritta come parte di un piano di miglioramento continuo.
Quando ho detto che gli avvertimenti sono "per lo più" inutili, ora li usiamo per registrare statistiche che ci consentono di misurare i kpi che dovrebbero continuare a mostrare miglioramenti.
Quando applicheremo nuovamente il codice sniffer, inizieremo la luce e introdurremo alcuni sniffer alla volta fino a quando non avremo applicato lo standard.
Dipenderà dal tuo obiettivo e dalla tua strategia .
Forzare tutti i buoni standard menzionati nel server CI potrebbe sembrare molto redditizio. Tuttavia, potrebbe non essere pratico per il grande team di sviluppo (più di 6 sviluppatori), se viene eseguito su ogni commit sul server. Attendere che il server risponda dopo il commit NON dovrebbe essere un lungo ritardo. Potrebbe potenzialmente causare dei tempi di inattività.
Tuttavia, è assolutamente legittimo bloccare un commit se il codice (il set di modifiche effettivamente) presenta problemi di dipendenza o non viene compilato. Tuttavia, il fallimento del codice a causa del layout del codice e di alcune convenzioni di denominazione potrebbe essere troppo grave e non una restrizione vitale per le regole di commit del server CI.
Ma è molto probabile che sia una regola utile se applicato durante la build serale.
Inoltre, gli strumenti di re-factoring possono aiutare a implementare e apprendere gli standard - come l' utilizzo di Resharper o JustCode da parte degli sviluppatori.