Alla fine della mia corda [chiuso]


17

Sono un appaltatore di una grande azienda. Attualmente, ci sono tre sviluppatori nel progetto, me compreso.

Il problema è che gli altri 2 sviluppatori non lo capiscono davvero. Per "esso" intendo quanto segue:

  • Non comprendono le migliori pratiche per la tecnologia che stiamo utilizzando. Dopo 6 mesi che io e altri abbiamo dato loro degli esempi ci sono terribili anti-schemi in uso.
  • Sono programmatori "copia e incolla" che producono principalmente codice spaghetti.
  • Rompono costantemente le cose, implementando i cambiamenti ma non facendo un test del fumo di base per vedere se tutto va bene
  • Si rifiutano / raramente di chiedere revisioni del codice.
  • Rifiutano / raramente fanno anche cose di base come la formattazione del codice.
  • Nessuna documentazione su nessuna classe (jsdocs)
  • Paura di eliminare il codice che non fa nulla
  • Lascia ovunque blocchi di codice commentati anche se abbiamo il controllo della versione.

Mi trovo sempre più frustrato mentre formatto il codice degli altri, correggo i bug, scopro la funzionalità che è rotta e creo astrazioni per rimuovere gli spaghetti.

Non so davvero cosa fare. Cerco di non sentirmi frustrato, ma è solo un casino. Mi piacciono queste persone come persone, ma sento che la situazione dei codici è così grave che potrei spostarmi più velocemente se navigassero sul Web tutto il giorno.

Sarebbe fuori linea chiedere al nostro responsabile di rivedere gli altri svn commit access; i commit possono essere eseguiti solo dopo una revisione da parte di qualcuno che è ben informato su ciò che stiamo facendo? Come appaltatore, non sono sicuro che sia la mossa migliore.

Esiste un modo sottile / non così sottile per chiarire quante cose sto risolvendo?


1
Ho aperto una domanda in risposta a questa, che penso generalizzi il vero problema che sta avendo la tua squadra: programmers.stackexchange.com/questions/127117/… . Per quanto riguarda l'introduzione di test automatizzati, sono pienamente d'accordo con il post di Martin Blore: martinblore.wordpress.com/2010/06/02/… - senza buoni principi e fondamenta, lo sforzo di TDD sarà molto sprecato. Ho cercato di concentrarmi su quella base nel mio post perché sono anche curioso.
DXM,

il problema che ho è che i test verificano solo che la funzionalità funzioni. Non affrontano gli altri 7 articoli che ho elencato.
hvgotcodes,

1
hai provato ad accoppiare la programmazione con questi ragazzi? vedrebbero il tuo punto e vedresti il ​​loro se ti siedi su una singola macchina e sviluppi una singola funzionalità. Fallo per un mese, 3 giorni a settimana, 3 ore al giorno. Potrebbe essere d'aiuto. Stabilire anche CI e pubblicare la copertura del codice e le metriche della percentuale di superamento dei casi di test. Lascia che la build fallisca se qualcuno di questi viene violato.

Risposte:


7

Sto avendo qualcosa del genere nella mia squadra. Ho cercato di convincere la gente a fare la cosa giusta e non ha funzionato come previsto, quindi sono passato a una soluzione diversa.

Innanzitutto, sono andato dal mio manager e abbiamo concluso un accordo, nessun codice entra nel controllo del codice sorgente a meno che non sia coperto da test unitari. Se il codice entra senza test unitari, ho il potere di veto di annullare immediatamente il commit e fare il ping a chiunque fosse responsabile di poter lavorare sui test e quindi spingere il codice.

Con questa regola in atto, eseguo regolarmente strumenti di copertura del codice (in questo caso, jacoco nella nostra build sbt ) per assicurarmi che i pezzi siano correttamente coperti e sto anche eseguendo refactoring e revisioni del codice costantemente in qualsiasi codice inviato da loro. Dato che si tratta di un progetto Java e Scala , ho molti strumenti per aiutarmi a catturare cose che non dovrebbero essere lì o che non funzionano come pensiamo che dovrebbe, non sono sicuro di come si possa fare lo stesso con JavaScript, ma forse c'è una soluzione.

La cosa principale che credo mi sta aiutando a tenere il passo con questo è che ho una visione chiara di ciò che mi aspetto dal progetto e dalla sua architettura principale, quindi ogni volta che vedo qualcosa che non riflette questa visione, posso andare lì e aggiustalo. Dovresti fare lo stesso, definire la tua visione, i modelli che dovrebbero essere usati, il modo in cui il codice dovrebbe essere scritto e tenerti al corrente di questo, facendo sempre sapere a loro (e alla tua direzione) cosa sta succedendo e cosa impedisce al progetto di andare avanti Più veloce.

Ci sarà sicuramente un momento in cui si arrenderanno e faranno la cosa giusta o la direzione riceverà il messaggio e li rimuoverà dal progetto.


5
il problema qui (e non sono sicuro che questa domanda sia troppo localizzata perché la causa sottostante penso sia molto comune) è come ispirare gli sviluppatori a imparare e crescere invece di fare affidamento sulle loro pratiche di copia "vere e provate" / incollare e tenere gli spaghetti in alto. Se l'OP passa al ruolo di sorvegliante / revisore / approvatore, taglierà significativamente il suo tempo. Allo stesso tempo, le persone che scrivono codice errato, scrivono test unitari ancora peggiori. Andranno ancora più lenti, scriveranno test non realizzabili, e poi faranno notare che i test unitari non funzionano e ti biasimeranno per averlo suggerito
DXM,

dxm, sì, questo è un problema. Il punto della mia domanda è come portare questo problema al management, anche se ammetto che probabilmente non era molto chiaro.
hvgotcodes,

2
Penso che la migliore opzione per portare questo al management sia mostrare quanta rilavorazione richiede il loro codice e quanta mamma viene sprecata per questo.
Maurício Linhares,

7

Sono sicuro che ormai hai visto i miei commenti e i miei altri post, quindi non farò finta di conoscere effettivamente la risposta. Il meglio che posso offrire è un riassunto di ciò che ho sentito / letto da altri e aggiungere un po 'della mia esperienza nel mix.

In primo luogo, voglio dire che poco fa mi sono imbattuto in un blog che appartiene a uno dei nostri membri programmatori SE, Martin Blore e IMO, questo post specifico sull'autorealizzazione di TDD è molto accurato. TDD è l'ultimo, il più alto livello che lega tutto, ma senza i livelli precedenti, in particolare il più grande, i principi e le pratiche di produzione di codice chiaro e leggibile, sarà molto difficile se non impossibile far funzionare TDD.

Nella mia azienda, sia l'Agile che il TDD ci sono stati imposti dal management, e all'inizio li abbiamo semplicemente fatti perché ci hanno detto (che è il contrario di Agile). Abbiamo provato TDD due volte e mentre sono un grande sostenitore dell'utilizzo di test automatizzati, ho personalmente eliminato tutti quelli che il team ha dato uno schiaffo nell'ultima versione. Erano fragili, giganteschi, copiati / incollati nel wazoo e pieni di dichiarazioni sul sonno che li facevano correre molto lentamente e imprevedibilmente. Il mio consiglio per la tua squadra: NON FARE TDD ... ancora.

Non so quale sia la tua situazione perché hai detto che sei stato con l'azienda per soli 6 mesi e che sei un appaltatore. I tuoi obiettivi a lungo termine sono di rimanere con questa azienda o il contratto sta per scadere? Sto chiedendo perché anche se fai qualcosa, potrebbe volerci un po 'di tempo per vedere effettivamente i risultati.

Inoltre, quando ti unisci a un team, di solito ci vuole tempo prima che tu abbia abbastanza credibilità e rispetto per il tuo team in cui loro (sviluppatori e management) prenderebbero in considerazione qualsiasi cosa tu proponga. Nella mia esperienza, aiuta se spegni pochi fuochi e dimostri di avere abilità e conoscenze su cui gli altri possono fare affidamento. Non sono sicuro che siano sufficienti 6 mesi. Abbastanza spesso una persona nuova e ambiziosa si unirebbe al team, quindi fare un post qui chiedendo come possono cambiare il mondo. La triste realtà è che semplicemente non possono.

Quindi supponendo che tu abbia il rispetto e l'attenzione della tua squadra. E adesso?

Innanzitutto, sia il management che gli sviluppatori devono essere consapevoli che esiste un problema. I risultati delle misure di gestione in termini di lavoro svolto. Se sono soddisfatti dell'attuale quantità e qualità delle funzionalità, la triste realtà è che non ascolteranno. Come altri hanno sottolineato, senza il supporto della direzione, sarà estremamente difficile introdurre qualsiasi tipo di cambiamento.

Una volta ottenuto il supporto di gestione, il passo successivo è quello di scavare in profondità e identificare le cause alla radice del perché il team opera in questo modo. Il prossimo argomento è qualcosa che è stata una mia ricerca personale per un po 'di tempo ormai. Finora questo è stato il mio viaggio:

  1. Una volta che hai il supporto della direzione. Puoi iniziare a introdurre molte pratiche / processi dettati centralmente che MainMa ha suggerito in risposta alla mia domanda . Ne abbiamo fatti molti (ad eccezione della programmazione abbinata) e sicuramente ne vedrai i benefici. Le revisioni del codice hanno contribuito in particolare a standardizzare lo stile, la documentazione e ci hanno anche permesso di condividere conoscenze / tecniche tra il team. Anche se le revisioni del codice sono state dettate, al team piacciono davvero e esaminiamo ogni funzionalità che viene archiviata. Tuttavia ...
  2. Si nota che il codice generalmente scritto è ancora troppo accoppiato, il design è errato o manca del tutto. Le recensioni del codice ne prendono parte, ma c'è solo così tanto che puoi riscrivere. Perché il design è cattivo in primo luogo? - Molti sviluppatori non sono mai stati introdotti alle buone pratiche e non sono mai stati istruiti formalmente su OOD in primo luogo. Molte persone "hanno semplicemente codificato" qualunque compito loro sia stato assegnato.
  3. Con il supporto della direzione è possibile introdurre più processi, ad esempio discutere della progettazione prima che avvenga qualsiasi codifica. Ma sei solo una persona e sembra che non prestando attenzione, il team ritorna a ciò che ha sempre fatto. Perché?
  4. È possibile introdurre e insegnare pratiche o abitudini migliori in modo da non doverle monitorare costantemente? - Sembra che questa parte non sia così semplice.
  5. Perché gli altri membri del team sono riluttanti ad apprendere e raccogliere nuove pratiche e perché sono così resistenti a SOLID o DRY quando è stato scritto così tanto nella moderna letteratura sulla metodologia del software? Con tutti i cambiamenti positivi che abbiamo avuto nella mia squadra, 2 settimane fa ho avuto una discussione erano ho refactoring 2 funzioni che hanno avuto identiche 15 righe di codice e il recensore ha chiamato eroica, uno sforzo inutile perché non c'è niente di sbagliato con copia / incolla di solo 15 righe. Non sono assolutamente d'accordo con tali opinioni, ma per ora abbiamo deciso di accettare di non essere d'accordo. -- E ora? Ora abbiamo raggiunto l'argomento del mio altro post .
  6. Come maple_shaft e nikie hanno sottolineato nelle loro risposte (scusate, MainMa , hai ottenuto il maggior numero di voti, ma sei così 5 passi indietro :)), hai raggiunto un punto in cui il "processo" non può più aiutare te e nessuno in questo forum posso dirti qual è la "correzione". Il prossimo passo è avvicinarsi agli individui, forse uno contro uno, forse come una squadra, probabilmente sia una volta che l'altra e parlare con loro. Chiedi loro, cosa funziona e cosa no. L'unico modo per identificare la causa principale di ciò che li spinge ora è parlare con loro individualmente e scoprirlo. Come parte di questo passaggio, di recente ho riscontrato un problema di squadra completamente diverso, ma penso che la risposta di Joel qui, che è molto dettagliato e approfondito, si applicherebbe anche a questo caso. In sintesi, mentre usare la gestione come "guinzaglio corto" è un possibile approccio a qualsiasi cosa, dobbiamo ricordare che abbiamo a che fare con gli esseri umani in modo da comprendere veramente le motivazioni che dobbiamo attraversare più nella psicoanalisi che nella gestione pura o nella leadership tecnica.
  7. Quindi adesso stai parlando con i tuoi compagni di squadra? Cosa chiedi loro? Non sono sicuro di questa prossima parte perché non sono mai stato qui. Ecco uno scenario possibile: D: Come mai nessun SOLID? A: Non ne ho bisogno. D: Potrebbe essere d'aiuto. A: Faccio bene così com'è. - in qualche modo devi generare una serie di suoni che lascerebbero la tua bocca e indurre l'ascoltatore a riconoscere che le cose potrebbero andare meglio se danno a qualsiasi cosa tu stia offrendo. Se fallisci qui, non saranno mai convinti che qualunque "processo" li faccia fare effettivamente ha alcun valore. D'altra parte, se superi questo punto, probabilmente scoprirai che non hai nemmeno più bisogno del "processo".
  8. Alla radice dell'IMO, i tuoi compagni di squadra non impareranno se non vedono nulla di sbagliato nelle loro attuali abitudini / pratiche. Quindi forse il prossimo passo in tutto questo è trovare un modo per illustrare, evidenziare i problemi e renderli ovvi. Dopotutto, non stiamo scrivendo codice leggibile, usando i principi SOLID / DRY o mantenendo la documentazione solo perché ci dà una sensazione calda e confusa. Lo facciamo perché produce un codice di qualità migliore e francamente ci rende il codice più veloce. Può essere misurato? Forse è qui che entrano in gioco le metriche del software?
  9. Ecco un'idea folle e non ho idea se funzionerebbe davvero (potrebbe essere una pratica standard del settore, o forse completamente non valida. L'ho appena inventato nelle ultime 24 ore), ma sono molto tentato di portarlo al tavolo non appena inizia il prossimo anno:
    • Contro le opinioni di molti altri , introdurre l'idea di autore / proprietario per tutti i file di origine. Come suggerisce il programmatore pragmatico, questo darà un senso di proprietà e responsabilità a una singola persona che sarà responsabile di un pezzo di codice sorgente. Ciò non significa che altre persone non possano modificare il codice, stiamo tutti lavorando come una squadra, ma alla fine della giornata, la persona che possiede il codice è responsabile della revisione delle modifiche.
    • Crea un trigger di repository di origine che monitora tutti i check-in e cerca specificamente quelli che sono correzioni di bug. Trasformalo in un processo in modo che ogni correzione di bug abbia un identificatore di riferimento nella descrizione del check-in. Ora scrivi uno script che analizzerebbe un elenco di file che sono stati modificati e rimuovendo "Autore" dal blocco di commenti dell'intestazione del file. Creare un database SQL che traccia il numero di difetti registrati per file / per progetto / per autore.
    • Una volta che hai abbastanza statistiche, si spera che noterai che il tuo codice ha meno difetti / modifiche rispetto ad alcuni degli altri codici. Questi sono dati concreti che puoi usare. Se un singolo progetto ha un tasso di difetti significativamente superiore alla media, presentalo come candidato per il prossimo sforzo di pulizia / refactoring per ripagare alcuni debiti tecnici.
    • Se un progetto o un file ha una percentuale di difetti significativamente superiore alla media e ha un proprietario, parla uno contro uno con quella persona. Chiedi loro, in modo molto educato, non conflittuale cosa possono fare per affrontare questo problema. Dal momento che sono il proprietario, dovrebbero guidare il cambiamento, ma offrire qualsiasi aiuto dalla tua parte. Si spera che il proprietario rintraccierà molte delle cause nel proprio codice spaghetti e non appena chiederà aiuto, sarà allora che entrerai in azione e metti del SOLIDO.

1
questo è eccellente, grazie. Ho provato prima di alcune di queste tecniche (Jen *, perché non cambi il tuo formattatore di codice per fare x, y, z, ci vogliono 2 minuti) prima, e ottengo sempre un servizio labiale e non succede nulla. Inoltre, uno dei miei colleghi è chiaramente più forte dell'altro; sulla linea in cui potrebbe essere molto brava, ma non riesce a eseguire. La sento parlare della qualità del codice in ogni momento, ma anche una sorta di ritorna in una shell quando è il momento di agire: "abbiamo solo 5 settimane da rilasciare, non voglio refactificare nulla ora". E io facepalm. * nome modificato
hvgotcodes,

cosa succede se non ti concentri sul formatter del codice (o su qualsiasi altra cosa specifica). Invece basta parlare con Jen e portare alcune delle questioni come questioni di squadra (ad esempio "Ho notato che alcune delle nostre codice non è molto leggibile, penso che sta causando noi a commettere errori che potrebbero essere evitati"). Non suggerire nulla, ma lascia che Jen pensi solo alle possibili soluzioni. Inoltre ho scoperto che aiuta quando si esegue il backup dei suggerimenti con le fonti. Invece di dire "Penso che dobbiamo lavorare su una migliore denominazione delle variabili", se dicessi "Ho letto Clean Code e penso che l'autore abbia avuto un ottimo punto, proviamo ..." Per discutere ...
DXM,

... con ciò Jen dovrebbe trovare un libro che suggerisce che nominare non è importante. E so cosa intendi quando le persone tornano indietro, è naturale e la ragione è che quando sei sotto pressione, torni nella tua zona di comfort per liberare lo sforzo per cose "importanti". Anche se coinvolgi il tuo team con il miglioramento della qualità e dell'apprendimento, ci vorranno diverse versioni prima che inizino a tornare a buone abitudini. Devi solo essere paziente, scegliere le tue battaglie e lasciare che alcune cose scivolino
DXM,

2

Ti suggerisco di parlare con il tuo manager del problema, ma quasi sicuramente non vorrà rivedere ogni singolo check-in.

Invece suggerisco di suggerire una suite di test di unità / regressione, da agganciare a SVN ed eseguire per ogni check-in. Questo ti aiuterà almeno ad evitare build rotte. Puoi gradualmente suggerire altre buone pratiche.

Se si rivela completamente non ricettivo, forse dovresti andare oltre la sua testa. Se decidi di farlo, dovrai portare il tuo gioco migliore. Fondamentalmente ti lancerai alla direzione per essere assunto a un livello superiore se lo fai.


1
non ho detto che questo è un lavoro lato client. test funzionali automatizzati sono la pipeline, ma non sono test unitari, quindi il feedback sarebbe giornaliero, non immediato.
hvgotcodes,

2
@hvgotcodes: non vedo perché ciò ti impedisce di creare unit test da eseguire su ogni check-in.
Marcin,
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.