Come convincere i programmatori a seguire le regole di base


20

Ci sono diverse regole che devo continuare a chiedere ai programmatori di seguire molto spesso. Scrivono codice e, se funziona, il lavoro è appena fatto, per loro. La maggior parte delle regole di base potrebbe essere:

  • Commettere cambiamenti
  • Non scrivere problemi relativi al modello in Visualizza o Controller
  • Evitare l'hardcoding

Puoi parlarmi della tua esperienza? Come lo gestisci?


2
Dovresti chiedere su programmers.stackexchange.com. Fai recensioni di codice? Hai uno strumento di revisione del codice come Crucible? Consiglierei di fare revisioni approfondite del codice e insistere su tutti i problemi che devono essere risolti prima di eseguire qualsiasi altro lavoro.

15
Puoi provare a lasciare la testa di cavallo sul loro letto che funzionava in Padrino.
Gaurav,

4
Ho avuto un grande successo con l'alta tensione. Il tuo chilometraggio può variare.
Tim Post

2
@Tim: un giornale arrotolato è più ecologico
Steven A. Lowe,

@Steven, immagino che sarebbe. Per prima cosa riutilizzi il giornale, poi lo ricicli. Suppongo che ci sia un'arte per intimidazione verde.
Tim Post

Risposte:


6

Tutti i knowledge worker devono essere sfidati a svolgere un lavoro di qualità. La qualità ne risentirà se sentiranno vincoli temporali arbitrari posti su di loro. Perché non rendere le cose "abbastanza buone" quando tutti sono preoccupati di rispettare le specifiche e rispettare le scadenze?

Il tuo elenco di reclami sono sintomi di un'azienda che premia solo il raggiungimento di obiettivi a breve termine e non ha alcun desiderio di enfatizzare l'alta qualità. Gestisci un hotel a cinque stelle o una fermata di camion?


1
+1 per sottolineare questo è un problema culturale e deve essere affrontato dal punto di vista della motivazione.
Alex Feinman,

è sia un problema culturale dell'azienda come accennato da JeffO. ma a volte quella cultura viene inventata dal basso verso l'alto quando programmatori e sviluppatori non hanno visione del codice di qualità o della necessità di esso. quando frequentavano la scuola di informatica, i loro professori avrebbero dovuto schiaffeggiarli un paio di volte ai lati della testa.
robert bristow-johnson,

@ robertbristow-johnson - Buon punto.
JeffO,

14

Per poter seguire le regole di base, devono sapere quali sono le regole e devono concordare con esse.

Il modo per gestirlo è creare congiuntamente un documento orientativo sulla codifica che tutti possano concordare. Non provare a forzarlo su di loro, se lo fai si ritorcerà contro.

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 senza fine. Stai cercando di mettere insieme molte menti, quindi potresti voler impostare il palcoscenico con una nota positiva che tutti dovresti essere rispettoso e mantenere una mente aperta (la scrittura del codice è personale ...).

Queste linee guida dovrebbero essere cambiate in modo vivo ogni volta che il team ritiene che ci sia qualcosa da aggiungere o chiarire.


2
Anche se sono d'accordo, sono anche in disaccordo con "Non provare a forzare questo su di loro, se lo fai si ritorcerà contro". - Quando tutto è stato detto e fatto, se qualcuno è d'accordo o meno sulle regole di base è irrilevante. Il capo stabilisce le regole, le segue o trova un altro lavoro. Non siamo così speciali che il rapporto datore di lavoro / dipendente non si applica.
Steven Evers,

12

Qual è il tuo ruolo? Se sei solo un altro sviluppatore con un interesse particolarmente forte per la qualità del codice, probabilmente non hai l'autorità per indurli ad ascoltarti, e forse dovresti far passare queste idee al management per stabilire standard di codice che dovrebbero / debbano essere seguita. Se sei un manager / team leader / architetto e hai qualche autorità, puoi stabilire tu stesso queste pratiche. Istituire un documento sugli 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.


1
Essere d'accordo. Questa è una questione politica, non tecnica.

E eventuali standard di codice dovrebbero essere concordati almeno parzialmente dal gruppo. Strumenti come StyleCop aiutano molto.
Giobbe

Il mio capo sta cercando di spingere la sua "qualità del codice", ma non decolla, perché la gente non ci crede. avere potere non è sempre la risposta.
IAdapter

@ 0101 Molto vero. Il potere aiuta a spingere il messaggio. Il messaggio deve essere realizzato in modo tale da essere accettato e seguito.
RationalGeek,

7

Finora deve essere una combinazione ragionevole di tutte le risposte. Alla fine, quando parli di un gruppo di persone intelligenti (sviluppatori), devi dare loro ragioni per cui il comportamento è importante e dare loro un controllo sufficiente su come quel comportamento viene implementato da essere investito nel farlo nel modo giusto. I mandati dall'alto sono generalmente sciolti con le persone intelligenti, perché se non hanno concordato che il problema è un problema, è probabile che trascorrano più tempo a lavorare attorno al mandato che a seguire la regola.

Ecco alcune delle mie tattiche:

Commettere modifiche:

Innanzitutto, il team deve concordare quando impegnarsi e cosa impegnare. Assolutamente essenziale è un'impostazione di costruzione che abbia un senso, in modo che le persone non resistano solo perché non sanno dove mettere qualcosa. E un consenso su quando / quanto spesso effettuare il check-in. "Non interrompere la build" è una buona regola ovvia, ma come viene verificato e chi viene informato? Un'altra linea di base è "non viene eseguita se non è stata effettuata la registrazione".

La maggior parte degli sviluppatori che conosco sono più che felici di controllare il codice IF:

  • Il processo di check-in è semplice
  • Il processo di sincronizzazione è semplice (factoring nelle modifiche di altri sviluppatori)
  • Vedere le modifiche e spostarsi tra le versioni è facile

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 è pionieristico al Rational Team Concert dopo aver usato Clearcase. Non intendo pubblicizzare strumenti, ma la nuova ondata (per me) di check-in in streaming con un sacco di piccole e veloci fusioni rende molto più allettante il check-in anticipato e spesso.

Lasciare che gli sviluppatori si occupino dell'eliminazione del dolore da CM generalmente aumenta la quantità di check-in che accade.

Aderendo all'architettura - Non scrivere i problemi del modello in viste e controller

Lo sto mettendo nel gruppo di "fare l'architettura correttamente". Sono d'accordo con chiunque abbia detto recensioni dei pari - la pressione dei pari è ottima per questo. Uno dei modi in cui generalmente vedo le persone entrare in gioco per le migliori pratiche in quest'area è quando i loro colleghi chiedono loro perché l'hanno fatto nell'altro modo (il modo non così giusto). Generalmente la domanda "perché" condurrà le persone lungo il percorso di rendersi conto da sole perché avrebbero dovuto farlo diversamente. Quando le persone hanno una ragione ben compresa per la migliore pratica, è molto più facile aderirvi.

Inoltre, se c'è una qualche formalità che collega una persona a una decisione, allora può essere più facile assegnare bug in quella zona ... quindi se una persona è responsabile per la correzione di bug in un'area di progettazione difettosa, la necessità di ottenere qualcosa prima possono passare a qualcosa di nuovo ed eccitante può essere un grande motivatore.

Evitare l'hardcoding

Comincerei con chiari standard di codifica e integrando una revisione standard di codifica nelle revisioni tra pari. La codifica hardware è una di quelle cose che possono essere facilmente una casella di spunta in un'agenda di peer review.

Temo che questo genere di cose sia l'unica cosa in cui l'ho visto diventare il ruolo del team che ha portato all'applicazione della regola. Nei team che ho gestito, generalmente non permetteremo a qualcuno di andare avanti fino a quando non avranno corretto i commenti da una revisione tra pari del loro codice. E "no hard coding" è un commento frequente di peer review.

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 di dolore e iniziare ad affrontarli in gruppi. Penso che diventi il ​​ruolo del leader sapere davvero qual è il punto dolente per la squadra rispetto a una seccatura fastidiosa di un particolare individuo.

Se la tua squadra si sta perdendo nel fare una buona pratica particolare, penso che la prima domanda debba essere "quanti danni sta causando?" se la risposta è "minima", probabilmente non vale la pena. Alcune buone pratiche sono più rilevanti per specifici tipi di sistemi - sebbene siano nel complesso buone, 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 danno?" è "MOLTO !!!", quindi puoi iniziare a costruire un caso per mostrare alla squadra che tutto questo dolore e sofferenza potrebbero essere rimossi fissando questo punto debole nelle migliori pratiche. Molte persone sono felici di evitare il dolore e la sofferenza e cambia il dialogo da "fai questo perché te l'ho detto", a "abbiamo deciso di farlo perché è meglio".


Commento lungo, ma il tuo approccio è fantastico. Per far sì che le persone aderiscano a queste linee guida, devono credere che sia un vantaggio. Sarei interessato a sentire alcuni esempi di come ha funzionato per la tua squadra.
jmort253,

Il mio esempio preferito è la configurazione coerente dell'ambiente di test. Non DEVO far valere la strada giusta. Avevo un ragazzo responsabile del documento di installazione. Ho detto - "è tutto ciò che puoi fare - puoi fare tutto il necessario per creare un meccanismo di installazione che garantisca un'installazione coerente - tutti hanno il potere di infastidirti se l'installazione è incasinata". In meno di un mese avevamo uno strumento solido e un documento molto breve. E lo strumento è stato installato come scorciatoia su ogni desktop. Non avevo bisogno di applicazione, una corretta installazione era già il percorso di minor resistenza. Ora il nostro obiettivo è rimuovere il collegamento, rendendolo automatizzato.
bethlakshmi,

6

Revisione del codice. Accetta solo codice ben scritto che non presenta errori.


3
Questa non è una soluzione per il problema di fondo. Non perdere tempo con le revisioni del codice, quando invece potresti risolvere il problema della causa principale.
Martin Wickman,

Se riesci a costringerli a rielaborare le cose ancora e ancora, la loro pigrizia intrinseca li farà iniziare a conformarsi nel tempo.
David Thornley,

D'accordo, le persone devono solo essere responsabili e svolgere il proprio lavoro senza che gli venga detto. La revisione del codice dopo ogni modifica è una grande perdita di tempo.
jmort253,

5

Almeno :

  • Rendere più facile per loro seguire le linee guida (strumenti come resharper, StyleCop) Se è facile, hanno maggiori probabilità di adottare.

Inoltre, scegli cosa funziona in base alla tua organizzazione, agli sviluppatori e al tuo ruolo all'interno del team.

  • Lascia che facciano correzioni di bug e cambino richiesta regolarmente
  • Associa il programma a uno sviluppatore esperto
  • Revisioni del codice in modo costruttivo
  • Procedure dettagliate sul codice
  • Inizia la formazione, usa libri come Code Complete e The pragmatic programmatore.

5

Il mio ruolo è Manager, ma come una 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. Sparare non suona come un buon approccio, in quanto ciò significa perdere beni meritevoli.

Darò un'occhiata a tutti quegli strumenti e rimango aperto a tutti gli altri che mi dici.


3
Se i tuoi beni sono così degni, forse questi problemi non sono così importanti? Devi scegliere e scegliere le tue battaglie alcune volte.
JeffO,

La mia domanda riguarda il miglioramento di ciò che ho, che è più difficile ma efficace della ricerca e sostituzione
Llistes Sugra,

Licenziare persone che non seguiranno le regole di codifica NON sta perdendo buoni beni, si sta sbarazzando di deadwood.
HLGEM,

@HLGEM - A meno che la persona che non segue le regole sia solo un ninja del codice in grado di risolvere qualsiasi problema nell'organizzazione. Il dottor House non segue le regole, ma se l'ospedale lo licenziasse, ci sarebbero molte persone immaginarie che moriranno. it.wikipedia.org/wiki/Gregory_House
jmort253

4

Esistono 3 modi per risolvere questo problema:

  1. Analisi statica del codice sorgente per verificare la presenza di problemi con la convenzione di codifica. Usa strumenti come cppcheck e quelli di grammatech . Wikipedia ha una buona lista: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis . In genere la maggior parte dei sistemi di controllo del codice sorgente ha hook con cui è possibile verificare tali problemi direttamente durante il check-in. Per gli hook CVS guarda questo link: http://goo.gl/F1gd2 . La mancata osservanza implica un check-in non riuscito e più di 3 fallimenti indicano che lo sviluppatore deve spiegare se stesso al team.

  2. Durante il processo di codifica stesso segnala problemi allo sviluppatore. Avere script personalizzati integrati con l'IDE di tua scelta è un ottimo modo per farlo. Dai un'occhiata a questo link: http://goo.gl/MM6c4

  3. Segui i processi agili e assicurati che la revisione del codice faccia parte dello sprint


1
+1, ho hook di commit che eseguono tutto ciò che è stato modificato tramite splint (e molti altri lint), nonché strumenti per assicurarmi di non includere inutilmente le intestazioni, oltre a assicurarmi che il rientro sia tab non spazi, ecc.
Tim Posta

Le soluzioni tecniche non aiuteranno se gli sviluppatori non sono obbligati a usarle.
Robert Harvey,

2

Ecco il mio piano in 3 passaggi:

  1. Licenzia i programmatori
  2. Assumi alcuni ingegneri del software
  3. ...
  4. Profitto!

: D

In tutta serietà, se non credono nel fare altro che scrivere codice, è necessario un team più completo. Una programmatrice in cui ho lavorato ha usato diverse directory sul computer come CM. Abbiamo combattuto con il loro programmatore per quasi un anno (poiché le modifiche avrebbero introdotto dei bug mentre copiavano e incollavano il vecchio codice). Alla fine li abbiamo appena licenziati.


2
  1. Fai notare a loro, quando violano le regole di base.
  2. Attendi che producano bug che non riescono a rintracciare o che devono confrontarsi con richieste di funzionalità che non possono implementare a causa del loro codice non flessibile.
  3. Ricorda loro quello che hai detto prima.
  4. Lasciali affogare nella loro merda per un po '.
  5. Prenditi il ​​tempo necessario per riformattare il codice in questione, isolare i bug / fornire infrasturcutre per collegare nuove funzionalità. Prenditi del tempo per spiegare cosa hai fatto.

In alternativa, la cosa più crudele ma molto persuasiva da fare è lasciare che mantengano una base di codice scritta in modo estremamente scadente, dato un programma stretto. : D
E poi, per una modifica, lascia che mantengano una base di codice ben scritta, dato un programma stretto.

In generale, la riluttanza ad adattare determinati standard significa una mancanza di esperienza nel lavoro di gruppo.

Alla fine le persone imparano solo dagli errori. Non risolvere MAI problemi, basati sulla testardaggine di qualcun altro. Se è davvero vitale per il progetto (cioè la tua azienda verrà citata in giudizio se non consegnerai entro N giorni), quindi rimuovili prima dal progetto.


Amo questo. Ottima ricetta per far odiare qualcuno. ;)
Roman Zenka,

@Roman Zenka: Forse sì. Ma se la scelta è tra l'essere odiato e l'essere frustrato, perché stai avendo un NNPP nella squadra, preferisco la prima opzione;)
back2dos,

A questo punto, devono essere rimossi dal libro paga.
JeffO,

Ci ho davvero lavorato! E non mi odiano. La conclusione è che ognuno è a proprio agio nella propria merda. E questo rende questo compito così difficile.
Llistes Sugra,

1

Penso che il tuo programmatore non cambierà il suo atteggiamento nei confronti di questi problemi che hai menzionato fino a quando non si renderanno conto che queste cose porteranno un beneficio o un vantaggio per loro. Prova a spiegare loro perché vuoi che facciano queste cose. Ancora meglio, lascia che sperimentino i vantaggi.


1

Assumi un ingegnere software professionista. E poi spara più debole. Quindi sostituire lentamente quelli che non possono adottare. Avere tali persone a volte porta più danni che profitti a lungo termine.

L'idea principale qui, che il professionista inizierà a fare la maggior parte del lavoro e licenziare gli altri non ridurrà preziose risorse umane.


1
Questo è un ottimo modo per compensare la mancanza di capacità di leadership e capacità di guidare persone meno esperte. Se le tue abilità di persuasione fanno schifo, inizia a licenziare tutte le persone che non sono d'accordo con te.
jmort253,

@ jmort253, Se avessi la possibilità, licenzierei ogni programmatore che non si impegna a controllare la versione su base regolare. Dalle parole dell'autore, capisco che TUTTI i programmatori sono molto inesperti e non vogliono imparare e migliorare se stessi.
Konstantin Petrukhnov,

1

È un po 'disgustoso, ma ho lasciato Code Complete nel bagno per alcuni mesi. Non sono sicuro che fosse efficace, ma al momento sembrava una buona idea.


0

Quindi quali sono le conseguenze per non seguire le regole e le ricompense per aver seguito le regole? Se la risposta è la stessa - niente - buona fortuna per ottenere trazione. Suggerisco un approccio a più livelli. Prima mettili insieme e discuti se acquistano le regole. Il prossimo passo è includerli nelle revisioni del codice. Puoi anche provare carote e bastoncini. Qualcosa come chiunque lasci un file estratto durante la notte deve portare le ciambelle al prossimo incontro settimanale. Una carota potrebbe essere chiunque segua le regole per un mese intero a fine settimana a Las Vegas. Per due.

O licenzia il peggior colpevole e lascia che gli altri lo sudino.


EEEP! Hai un tipo di checkout unico di VCS? Vai con il secolo, amico!
David Thornley,

0

Farli subiscono le consecuences che si desidera evitare utilizzando tali regole, è l'unico modo in cui sono davvero a capire il motivo per cui si sta chiedendo, ad esempio: fare un piccolo pasticcio controllata che essi devono corretta.


0

Se questo equipaggio ha davvero problemi a controllare le modifiche, aderendo alla separazione delle preoccupazioni e non codificando le costanti magiche, licenzierei l'intero equipaggio e lo sostituirò con veri programmatori 1 che si preoccupano davvero del loro mestiere il prima possibile. Che si tratti di uno alla volta o di massa non potrei dirlo, ma questi burloni devono andare.

Il tipo di codifica che stai descrivendo è adatto per gli script usa e getta usa e getta. Non è come si costruisce un'applicazione reale. Se vengono pagati come programmatori professionisti, è loro compito conoscere questo genere di cose.


1 Questo è spesso usato come un termine scherzoso 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 principiante e non avrei bisogno di dirmi queste cose perché mi interessa il mio mestiere. Questi non sono veri programmatori con cui hai a che fare.


Sono d'accordo con tutto tranne la parte di fuoco. Buona fortuna a lasciare qualsiasi altra attività critica su cui stai lavorando come manager, comprese le scadenze per il rispetto e le pietre miliari dei clienti, per sostituire tutto il tuo personale esperto con persone che possono commentare il codice ma che non hanno conoscenza del dominio.
jmort253,

0

Il lavoro di un manager non è quello di essere amico del dipendente, a volte devi essere il cattivo. Applicare standard di codifica e commit, rifiuto di seguire l'architettura vietata, mancato utilizzo degli strumenti prescritti, ecc. Sono i tempi in cui devi essere impopolare.

Esprimi chiaramente le politiche. Esegui una revisione formale del codice e verifica se le politiche vengono seguite. Non consentire loro di passare a un'altra attività fino a quando tutti i problemi derivanti dalla revisione del codice non vengono risolti.

Se la politica riguarda il non commettere codice, questo richiede un avviso scritto se non possono farlo quando viene loro chiesto di farlo. Se non commettono codice, per quanto ti riguarda non ne hanno scritto nessuno.

Se non migliorano dopo che gli è stata data una ragionevole possibilità di migliorare, licenziali. Gli sviluppatori non professionisti sono un ostacolo per il tuo team, indipendentemente dal tipo di codice che scrivono. Stanno colpendo gli altri con la loro mancanza di professionalità e non deve essere tollerato. Non sono brave persone da trattenere in ogni caso. I bravi sviluppatori commettono il loro codice, i bravi sviluppatori seguono le decisioni sull'architettura anche se non sono d'accordo con loro e i bravi sviluppatori non scrivono codice. Non ti mancherà nulla tranne il mal di testa sbarazzandoti dei programmatori di cowboy.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.