Ci sono diverse regole che devo continuare a chiedere ai programmatori di seguire molto spesso. Scrivono il codice e, se funziona, il lavoro è fatto, per loro. La maggior parte delle regole di base potrebbe essere:
Puoi parlarmi della tua esperienza? Come gestisci questo?
Tutti i knowledge worker devono essere sfidati a fare un lavoro di qualità. La qualità ne risentirà se ritengono che vi siano vincoli temporali arbitrari. Perché non solo creare cose che sono "abbastanza buone" quando tutti sono interessati a soddisfare le specifiche e rispettare le scadenze?
La tua lista di reclami sono i sintomi di un'azienda che ricompensa solo incontrando obiettivi a breve termine e non ha alcun desiderio di porre l'accento sull'alta qualità. Stai gestendo un hotel a cinque stelle o una fermata dell'autobus?
Per poter seguire le regole di base, devono sapere quali sono le regole e devono essere d'accordo con loro.
Il modo per gestirli è creare congiuntamente un documento di guida alla codifica con cui tutti possono essere d'accordo. Non provare a forzare questo su di loro, si ritorcerà contro se lo fai.
Quindi riunisci il team e inizia a lavorare su una definizione comune delle tue regole di base!
Fallo come un laboratorio in cui tutte le voci sono ascoltate. Timebox per evitare discussioni infinite. Stai cercando di riunire più menti, quindi potresti voler preparare il palco con una nota positiva che tutti dovresti essere rispettoso e mantenere una mente aperta (la scrittura del codice è personale ...).
Queste linee guida dovrebbero essere vivi cambiate ogni volta che il team ritiene che ci sia qualcosa che dovrebbe essere aggiunto o chiarito.
Qual è il tuo ruolo? Se sei solo un altro sviluppatore con un particolare interesse per la qualità del codice, probabilmente non hai l'autorità per convincerli ad ascoltarti, e forse dovresti spiegare queste idee alla direzione per stabilire degli standard di codice che dovrebbero / devono essere seguita. Se sei un manager / team lead / architect qualunque e hai qualche autorità, allora puoi stabilire queste pratiche tu stesso. Installa un documento standard e un processo di revisione del codice per eliminare queste cose.
Non sarà un interruttore magico che puoi attivare; sarà un processo lento e non sarà mai stato al 100%. Questa è stata comunque la mia esperienza.
Deve essere una combinazione sensata di tutte le risposte finora. Alla fine, quando parli di un gruppo di persone intelligenti (sviluppatori), devi dare loro i motivi per cui il comportamento è importante e dare loro un controllo sufficiente su in che modo viene implementato quel comportamento che sono investiti nel farlo bene. I mandati dall'alto sono generalmente sciolti con persone intelligenti, perché se non hanno concordato che il problema è un problema, è probabile che passino più tempo a lavorare attorno al mandato che seguire la regola.
Ecco alcune delle mie tattiche:
Cambiamenti di commit:
In primo luogo, il team deve essere d'accordo su quando impegnarsi e su cosa impegnarsi. Assolutamente essenziale è una configurazione di costruzione che abbia senso, in modo che le persone non stiano trattenendo solo perché non sanno dove mettere qualcosa. E un consenso su quando / quanto spesso fare il check-in "non rompere la build" è una ovvia buona regola, ma come viene controllato e chi viene informato a riguardo? Un'altra linea di base è "non è fatta se non è stata verificata".
La maggior parte degli sviluppatori che conosco sono più che felici di verificare il codice SE:
Una cosa che ho notato di recente è che i check-in sono diventati più frequenti e meno dolorosi quando siamo passati a un nuovo strumento CM. Il nostro team è stato pioniere del Rational Team Concert dopo aver utilizzato Clearcase. Non intendo pubblicizzare strumenti, ma la nuova (per me) ondata di controlli di streaming con un sacco di fusioni piccole e veloci rende molto più allettante il check-in anticipato e spesso.
Lasciando che gli sviluppatori siano incaricati di eliminare il dolore da CM generalmente aumenta la quantità di check-in che accade.
Aderire all'architettura - Non scrivere i problemi del modello nelle viste e nei controllori
Lo metto nel gruppo generale di "fare l'architettura correttamente". Sono d'accordo con chi ha detto le recensioni dei colleghi - la pressione dei colleghi è grande per questo. Uno dei modi in cui in genere vedo le persone entrare nell'ovile per le migliori pratiche in quest'area è quando i loro coetanei chiedono loro perché l'hanno fatto nell'altro modo (il modo non proprio corretto). Generalmente la domanda "perché" spingerà le persone a intraprendere il cammino per rendersi conto di loro perché dovrebbero averlo fatto in modo diverso. Quando le persone hanno una ragione ben compresa per la migliore pratica, è molto più facile aderirvi.
Inoltre, se ci sono alcune formalità che collegano una persona a una decisione, allora può essere più facile assegnare bug in quella zona ... quindi se una persona è responsabile della correzione dei bug in un'area di progettazione difettosa, la necessità di ottenere qualcosa giusto prima che possano passare a qualcosa di nuovo ed eccitante può essere un grande motivatore.
Evita codifica hard
Vorrei iniziare con standard di codifica chiari e integrare una revisione standard di codifica nelle revisioni tra pari. L'hard coding è una di quelle cose che possono facilmente essere una casella di controllo in un programma di revisione tra pari.
Ho paura che questo genere di cose sia l'unica cosa in cui l'ho visto diventare il ruolo della squadra che ha il compito di rafforzare la regola. Nei team che ho corso, generalmente non lasceremo che qualcuno si muova fino a quando non avranno risolto i commenti da una peer review del loro codice. E "nessun hard coding" è un frequente commento di revisione tra pari.
In generale
Con quasi tutte le migliori pratiche, penso che devi scegliere le tue battaglie. Nessuna squadra diventerà assolutamente perfetta. Ma puoi tenere d'occhio i tuoi principali punti dolenti e iniziare ad affrontarli in gruppi. Penso che diventi il ruolo del leader per sapere veramente quale sia il punto dolente per la squadra rispetto a un fastidioso capriccio di un particolare individuo.
Se la tua squadra sta perdendo una particolare pratica, penso che la prima domanda debba essere "quanto danno sta causando questo?" se la risposta è "minima", probabilmente non ne vale la pena. Alcune best practice sono più rilevanti per specifici tipi di sistemi - mentre sono buoni nel complesso, potrebbero non valere la pena di combattere per sistemi in cui la pratica non è un evento frequente o una parte importante del sistema.
Se la risposta a "quanto è strano?" è "ALOT !!!", quindi puoi iniziare a costruire un caso per mostrare alla squadra che tutto questo dolore e questa sofferenza potrebbero essere rimossi fissando questo punto debole nelle migliori pratiche. La maggior parte delle persone è felice di evitare dolore e sofferenza e cambia il dialogo da "fai questo perché te l'ho detto", a "abbiamo deciso di farlo perché è meglio".
Revisione del codice. Accetta solo codice ben scritto che non ha errori.
Almeno:
Inoltre, scegli ciò che funziona in base alla tua organizzazione, agli sviluppatori e al tuo ruolo all'interno del team.
Il mio ruolo è Manager, ma come piccola squadra sviluppo e preferisco gestire come allenatore.
Gli elettrodi sulla sedia collegati a un parser di codice sono già stati segnalati, ma i programmatori non sembrano aver paura. L'attivazione non sembra un buon approccio, poiché ciò significa perdere risorse degne di essere utilizzate.
Darò un'occhiata a tutti questi strumenti e rimango aperto a qualsiasi altro tu mi dica.
Ci sono 3 modi con cui affrontiamo questo problema:
Analisi statica del codice sorgente per verificare la presenza di problemi con la convenzione di codifica. Utilizza strumenti come cppcheck e quelli di grammatech . Wikipedia ha una buona lista: link . In genere, la maggior parte dei sistemi di controllo di origine dispone di hook tramite il quale è possibile verificare tali problemi direttamente durante il check-in. Per gli hook di CVS, consulta questo link: link . La mancata conformità significa un check-in fallito, e più di 3 guasti significa che lo sviluppatore deve spiegarsi al team.
Durante la procedura di codifica, segnala i problemi allo sviluppatore. Avere script personalizzati che sono integrati con l'IDE di tua scelta è un ottimo modo per farlo. Controlla questo link: link
Segui processi agili e assicurati che la revisione del codice faccia parte dello sprint
Ecco il mio piano in 3 fasi:
: D
In tutta serietà, se non credono nel fare altro che scrivere codice, è necessario un team più completo. Un programmatore in cui lavoravo usava diverse directory sul computer come il suo CM. Abbiamo combattuto con il loro programmatore per quasi un anno (poiché i cambiamenti avrebbero introdotto bug mentre copiavano e incollavano il vecchio codice). Alla fine li abbiamo appena licenziati.
In alternativa, la cosa più crudele ma molto persuasiva è lasciare che mantengano una base di codice scritta in modo estremamente scadente, dato un programma serrato. : D
E poi, per cambiare, lascia che mantengano una base di codice ben scritta, dato un programma serrato.
Generalmente, la riluttanza ad adeguare determinati standard significa mancanza di esperienza nel lavoro di squadra.
Alla fine le persone imparano solo dagli errori. Non risolvere MAI problemi, che sono basati sulla testardaggine di qualcun altro. Se è davvero vitale per il progetto (ad esempio, la tua azienda verrà citata in giudizio se non la consegni entro N giorni), quindi prima rimuovi dal progetto.
Penso che il programmatore non cambierà il loro atteggiamento nei confronti di questi temi che hai menzionato fino a quando non si renderanno conto che queste cose porteranno a un vantaggio oa un vantaggio per loro. Cerca di spiegargli perché vuoi che facciano queste cose. Ancora meglio, lascia che sperimentino i vantaggi.
Assumi un ingegnere software professionista. E poi il fuoco più debole. Poi lentamente sostituire quelli che non possono adottare. Avere persone del genere a volte porta più danni che profitti a lungo termine.
L'idea principale qui, quella professionale inizierà a fare la maggior parte del lavoro, e licenziare gli altri non ridurrà la preziosa risorsa umana.
È un po 'schifoso, ma ho lasciato il codice completo in bagno per alcuni mesi. Non sono sicuro che fosse efficace, ma all'epoca sembrava una buona idea.
Quindi quali sono le conseguenze per non seguire le regole e i premi per seguire le regole? Se la risposta è la stessa - niente - buona fortuna ottenere qualsiasi trazione. Suggerisco un approccio a più livelli. Per prima cosa mettili insieme e discuti se comprano le regole. Il prossimo passo è includerli nelle revisioni del codice. Puoi anche provare carote e bastoncini. Qualcosa come chi lascia un file estratto durante la notte deve portare ciambelle alla prossima riunione settimanale. Una carota potrebbe essere chiunque segua le regole per un mese intero a Las Vegas. Per due.
Oppure licenzia il peggior trasgressore e lascia che il resto lo sudori.
Fai in modo che subiscano le conseguenze che vuoi evitare usando quelle regole, è l'unico modo in cui capiranno davvero perché ti stai chiedendo, ad esempio: crea un piccolo casino controllato che loro hanno correggere.
Se questa troupe ha davvero problemi nel controllare i cambiamenti, aderendo alla separazione delle preoccupazioni e non alle costanti magiche hard-coding, allora licenzierei l'intero equipaggio e li sostituirò con dei veri programmatori 1 che effettivamente si preoccupano sul loro mestiere il prima possibile. Essere uno alla volta o in massa non potrei dire ma questi jolly devono andare.
Il tipo di codice che stai descrivendo è adatto per script usa e getta, usa e getta. Non è come si costruisce un'applicazione reale. Se vengono pagati come programmatori professionisti, è il loro lavoro sapere questo genere di cose.
1 Questo è spesso usato come un termine scherzo per le persone immaginarie che scrivono il loro codice direttamente in binario o qualcosa di altrettanto ridicolo. Qui, non sto scherzando. Sono un programmatore abbastanza rookie e non avrei bisogno di sentirmi dire queste cose perché mi interessa il mio mestiere. Questi non sono dei veri programmatori con cui hai a che fare.
Il lavoro di un manager non deve essere l'amico del dipendente, a volte devi essere il cattivo. Applicare gli standard di codifica e il commit, il rifiuto di seguire l'architettura, l'impossibilità di usare gli strumenti prescritti, ecc. Sono i tempi in cui bisogna essere impopolari.
Esprimi le politiche in modo chiaro. Esegui revisioni formali del codice e controlla se le norme vengono seguite. Non permettere loro di spostarsi su un'altra attività finché non vengono giudicati tutti i problemi derivanti dalla revisione del codice.
Se la politica riguarda il non commit del codice, questo richiede un avvertimento scritto se non possono farlo quando viene loro richiesto di farlo. Se non stanno eseguendo il codice, per quanto ti riguarda non ne hanno scritto nessuno.
Se non migliorano dopo aver ricevuto una ragionevole possibilità di migliorare, licenziarli. Gli sviluppatori non professionali sono un ostacolo per il tuo team, indipendentemente dal tipo di codice che scrivono. Stanno influenzando gli altri con la loro mancanza di professionalità e non devono essere tollerati. Non sono brave persone da mantenere in ogni caso. I buoni sviluppatori commettono il loro codice, i buoni sviluppatori seguono le decisioni architettoniche anche se non sono d'accordo con loro e i buoni sviluppatori non fanno il codice. Non ti mancherà nulla tranne il mal di testa liberandoti dai codificatori dei cowboy.
Leggi altre domande sui tag code-reviews project-management