Trattare con i colleghi durante lo sviluppo, necessita di consigli [chiuso]

Ho sviluppato la nostra attuale architettura di progetto e ho iniziato a svilupparla da sola (raggiungendo qualcosa di simile revision 40) .

Stiamo sviluppando un semplice framework di instradamento della metropolitana e la mia progettazione sembrava essere stata eseguita molto bene: diversi modelli principali, viste corrispondenti, principali logiche e strutture di dati sono stati modellati "come dovrebbero essere" e completamente separati dal rendering, inoltre è stata implementata la parte algoritmica a parte i modelli principali e aveva un numero minore di punti di intersezione.

Lo definirei scalabile, personalizzabile, facile da implementare, interagendo principalmente sulla base dell'interazione "scatola nera" e, beh, molto carino.

Ora, cosa è stato fatto:

• Ho avviato alcune implementazioni delle interfacce corrispondenti, portato alcune librerie convenienti e scritto stub di implementazione per alcune parti dell'applicazione.
• Ho avuto il documento che descriveva lo stile di codifica ed esempi di tale uso di codice (il mio codice scritto).
• Ho forzato l'uso di C++tecniche di sviluppo più o meno moderne , incluso il no-deletecodice (racchiuso da puntatori intelligenti) e così via.
• Ho documentato lo scopo di implementazioni di interfaccia concrete e come dovrebbero essere utilizzate.
• Test unitari (principalmente test di integrazione, perché non c'era molto codice "reale") e una serie di derisioni per tutte le astrazioni principali.

Sono stato assente per 12 giorni .

Cosa abbiamo ora (il progetto è stato sviluppato da altri 4 membri del team):

• 3 diversi stili di codifica in tutto il progetto (immagino, due di loro hanno accettato di usare lo stesso stile :) , lo stesso vale per la denominazione delle nostre astrazioni (ad esempio CommonPathData.h, SubwaySchemeStructures.h) , che sono fondamentalmente intestazioni che dichiarano alcune strutture di dati.
• Assoluta mancanza di documentazione per le parti implementate di recente.
• Quello che potrei chiamare recentemente un single-purpose-abstractionora gestisce almeno 2 diversi tipi di eventi, ha un accoppiamento stretto con altre parti e così via.
• La metà delle interfacce utilizzate ora contiene variabili membro (sic!).
• Utilizzo puntatore non elaborato quasi ovunque.
• Test unitari disabilitati, perché " (Rev.57) They are unnecessary for this project".
• ... (probabilmente non è tutto) .

La storia di Commit mostra che il mio design è stato interpretato come eccessivo e le persone hanno iniziato a combinarlo con biciclette personali e ruote reimplementate e quindi hanno avuto problemi con l' integrazione di blocchi di codice.

Ora - il progetto fa ancora solo una piccola parte di ciò che deve fare, abbiamo gravi problemi di integrazione, presumo alcune perdite di memoria.

C'è qualcosa da fare in questo caso?

Mi rendo conto che tutti i miei sforzi non hanno avuto alcun vantaggio, ma la scadenza è abbastanza presto e dobbiamo fare qualcosa. Qualcuno ha avuto una situazione simile?

Fondamentalmente ho pensato che un buon (beh, ho fatto tutto il possibile) per iniziare il progetto avrebbe probabilmente portato a qualcosa di carino, tuttavia, capisco che mi sbaglio.

Rifattore senza pietà per uscire dal caos!

Prendi lo stile di codifica che rappresenta la maggior parte dello stile utilizzabile e usalo per questo progetto.

La cosa peggiore è che devi tornare alla revisione 40 e i tuoi programmatori hanno avuto una sessione di formazione di 12 giorni, che ha permesso loro di comprendere meglio l'argomento.

Se i tuoi programmatori hanno così tanto da imparare sulla codifica pulita, i dodici giorni sono il minimo dei ritardi che avrai.

Parafrasando la tua domanda - "Sono andato via per un paio di settimane e non sono d'accordo con quello che la mia squadra ha fatto quando ero via, come faccio a farli fare quello che voglio quando non sono qui?"

Ti ho detto che questo non è un problema tecnico, è un problema di gestione. La mia opinione (per favore, perdonami se sbaglio) è che hai dettato la soluzione tecnica a un esercito di servitori, che per qualche ragione non possono o non sono d'accordo o non comprendono la tua soluzione.

Se bastano 12 giorni per danneggiare così tanto il tuo progetto, ci deve essere un motivo. Il design è fragile? è troppo ingegnerizzato? o il team lo ha fatto per dispetto? Quali sono le scadenze e le consegne? Stretto? stavano solo cercando di incontrarne uno?

Un caso in cui ho visto questo vantaggio tecnico era così avanti rispetto al gioco che lo sviluppatore medio (io) non riuscivo a tenere il passo. Il responsabile tecnico non è riuscito a progettare il codice commercialmente praticabile, poiché era l'unico in grado di mantenerlo. Se uno sviluppatore laureato non può mantenerlo, è troppo complesso per il mondo commerciale. Tutti gli altri casi, era semplicemente la mancanza di capacità di gestione delle persone dal lato della gestione.

Le dinamiche della squadra sono interrotte. Puoi (come suggerito da altri) passare il tempo a rifattorizzare il pasticcio e rifare tutto la prossima volta che prendi le ferie. Potresti aver bisogno di migliorare le competenze dei membri del tuo team, ma credo che devi prima correggere le dinamiche del team, poiché sembrano avere abbastanza abilità per svolgere il lavoro, non importa quanto credi sia.

Paio.

Quello che stai descrivendo è molto farlo nel modo giusto, tecnicamente, da solo . Sì, hai provato a documentare, hai cercato di imporre standard, ma apparentemente non sei riuscito a comunicare.

Bene, il tuo team ti ha appena comunicato, in modo piuttosto clamoroso. Dissero: "Ehi, Yippie - non stai comunicando!" La più potente forma di comunicazione che conosco è l'associazione. Paio. Fino a quando non lo ottengono o fino a quando non ti convincono a farlo diversamente.

Come ci ha detto Brooks negli ultimi 30 anni, l'integrità concettuale è la parte più importante di qualsiasi progetto. Per ogni sottosistema non banale e completo dovrebbe esserci esattamente una persona, responsabile della sua progettazione e dotata dell'autorità di dirigere la sua attuazione. Qualcosa non ha funzionato in questa parte del tuo progetto. Qualunque cosa fosse, l'unica soluzione è ripristinare il codice nel repository che esisteva prima che ciò accadesse. Una perdita di 12 giorni non è nulla in confronto alle spese di mantenimento del design non funzionante. Penserei anche ai modi per rimuovere le persone coinvolte in questo insulto da ulteriori lavori sul progetto, dal momento che si sono dimostrati incompetenti.

Una cosa che farei per cominciare è ottenere un buon strumento di revisione del codice, usandolo per contrassegnare il codice cattivo e documentare perché è cattivo e (concettualmente) come dovrebbe essere fatto. Ora, per quello che ho capito, ci sono un sacco di cose cattive fatte e quindi sarebbe un sacco di lavoro da rivedere; supponendo che tu sia l'unico che vede qualcosa di sbagliato nel codice, potrebbe non essere possibile rivedere tutto da solo. Ma potresti contrassegnare i reati peggiori e trasformarli in voci nel tuo sistema di tracciamento dei problemi, assegnate alla persona che ha scritto il codice corrispondente.

Il miglior incentivo per scrivere un codice di qualità è sapere che se non lo fai, ti perseguiterà in futuro. I tuoi colleghi non sembrano preoccuparsene, quindi la migliore medicina è quella di far loro refactoring le parti sbagliate e imparare.

Dato il tempo, è possibile rivisitare altre parti del codice che sono problematiche e riassegnare di nuovo all'autore originale (non valido). Dopo un po 'capiranno i vantaggi di fare un buon lavoro la prima volta.

Suppongo che tu non consideri un rollback alla tua versione originale un'opzione - in altre parole, nonostante il codice errato scritto dai tuoi colleghi, hanno aggiunto alcune funzionalità e il valore netto della versione corrente è superiore a quello originale. Suppongo anche che, anche se non fosse così, non hai capitale politico per fare quel rollback e farli riscrivere il codice (dato che pochissime persone nel pianeta hanno tale capitale). Queste e molte altre sono le complessità di giudicare una situazione che non sto vivendo, ma spero che i miei due centesimi mi abbiano aiutato.

Una cosa che non ho visto menzionato, ma che è emersa recentemente dove lavoro sono i problemi di "silos degli sviluppatori" e "buy in".

All'inizio del mio attuale progetto, ho finito per progettare una libreria di base praticamente da solo. (Proprio come hai fatto fino alla rev.40). Poi, quando l'ho fatto, mi sono presentato al resto della squadra e ho detto a tutti che potevano iniziare a usarlo. Ciò che è accaduto nei mesi successivi è stato che le persone continuavano a implementare le stesse cose che erano già presenti in questa biblioteca in altri luoghi. Il CTO (che attivamente codifica) sottolinea che non c'è mai stato un riscontro da parte del resto del team sulle interfacce architettura / design / pubbliche della biblioteca.

Bene, abbiamo appena passato una grande riscrittura di quella libreria che ha probabilmente migliorato il design complessivo per adattarsi meglio a quello che stiamo facendo attualmente, ma ancora una volta uno sviluppatore ha preso la libreria come unico progetto, ci ha lavorato per diverse settimane e quindi appena presentato. "Voila! Eccola! Non è carino?"

Ora che devo usare la nuova versione e lo stesso problema c'è: odio il modo in cui l'ha fatto. E ha lasciato fuori ciò che era necessario perché non riusciva a collaborare con nessun altro mentre ci stava lavorando. Quindi di nuovo, sto iniziando a implementare le stesse cose in altri luoghi e modi di lavorare per quello che devo fare.

Per farla breve: se vuoi che la qualità del codice aumenti e sia coerente, ti suggerirei di riunire l'intero team per stabilire standard, stili, ecc. Inoltre, ogni volta che qualcuno costruirà un pezzo fondamentale o fondamentale del tuo applicazione, suggerirei che la persona responsabile guidasse l'intero team nella progettazione delle classi, ecc. in modo che alla fine della giornata, l'intero team debba acquistare nell'architettura generale dell'applicazione. Inoltre, se sanno come funziona il codice di un altro membro del team, avranno meno probabilità di implementarlo di nuovo in un modo che funzioni per loro.

Sei lo sviluppatore senior (o uno degli sviluppatori senior) in questo team? In tal caso sembra che tu debba tenere alcuni seminari di formazione sulle migliori pratiche. Probabilmente dovresti ripristinare gran parte del lavoro svolto, tenere un incontro con il tuo team e spiegare il modo giusto di implementare la funzionalità richiesta in modo da mantenere il design esistente.

Dato che stai rispettando una scadenza, potrebbe essere necessario spedire il codice così com'è e refactoring (riscrivere?) Dopo il rilascio.

Sembra anche che sia necessario definire e applicare alcune pratiche di codice comuni. Hai un processo di revisione del codice in atto sul posto di lavoro? In caso contrario, sembra che ora sia il momento di implementarne uno. Le revisioni del codice sono comunque un ottimo modo per insegnare alle nuove pratiche degli sviluppatori più recenti.

MODIFICARE:

Mi sono imbattuto in una situazione simile di recente. Il management della mia azienda ha insistito sul fatto che utilizziamo gli sviluppatori di contratti per scrivere gran parte della nostra applicazione. Il codice che hanno prodotto era orribile (per dirla gentilmente), ma siamo stati costretti a usarlo. Ad oggi, ho riscritto l'80% del codice che gli appaltatori hanno scritto per noi. Era pieno di bug e impossibile da estendere con nuove funzionalità. Nel giro di un paio di mesi il mio team avrà riscritto tutto, trasformando efficacemente i soldi investiti nello sviluppo del contratto.

Il cattivo codice costa davvero denaro, è qualcosa di cui potresti voler parlare con i tuoi manager, dal momento che probabilmente avrai bisogno del loro aiuto per implementare e applicare gli standard di codifica.

Hai fatto uno sforzo, ma il fatto è che nessuno è responsabile . "Ma preferisco il mio stile di programmazione", niente merda. Mi piacerebbe lavorare sui miei progetti personali tutto il giorno e comunque essere pagato.

Spero che tu possa presentare questo ai poteri che sono e mostrare loro cosa avrebbe potuto essere fatto al contrario del Wild West Show che è andato avanti per due settimane. Sembra che dovrai ottenere qualcosa fuori dalla porta, ma continua a dare seguito al problema della mancanza di controlli e coerenza.

Concentrati sui pochi che hanno accompagnato il tuo piano e fai tutto il possibile per aiutarli a risolvere questo pasticcio e coinvolgerli nel tuo team in progetti futuri. Potrebbe essere necessario rifiutare il resto se non riescono a metterlo insieme.