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

Refactor senza pietà per uscire dal caos!

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

La cosa peggiore è che devi tornare alla revisione 40 ei tuoi programmatori hanno avuto una sessione di allenamento di 12 giorni, che ha dato loro una migliore comprensione dell'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 ha fatto la mia squadra quando me ne sono andato, come faccio a fargli 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 tu dici la soluzione tecnica a un esercito di minion, che per qualche motivo non può o non è d'accordo o capisce la tua soluzione.

Se 12 giorni sono sufficienti per fare tanti danni al tuo design, ci deve essere un motivo. Il design è fragile? è finita? o la squadra l'ha appena fatto per dispetto? Come sono le tue scadenze e consegne? Stretto? stavano solo cercando di incontrarne uno?

In un caso che ho visto, il vantaggio tecnico è stato così avanti rispetto al gioco che lo sviluppatore medio (io) non poteva tenere sotto controllo. Il capo tecnico non è riuscito a progettare codice commercialmente fattibile, poiché era l'unico che poteva mantenerlo. Se uno sviluppatore non può mantenerlo, è troppo complesso per il mondo commerciale. Tutti gli altri casi, è stata semplicemente la mancanza di capacità di gestione delle persone sul lato della gestione.

Le dinamiche del team sono rotte. Puoi (come suggerito da altri) trascorrere del tempo a rifare il pasticcio e devi farlo di nuovo la prossima volta che ti congederai. Potresti aver bisogno di migliorare i tuoi membri del team, ma credo che tu debba prima sistemare le dinamiche del team, poiché sembrano avere abbastanza abilità per portare a termine il lavoro, non importa quanto tu credi che sia brutto.

Pair.

Ciò che stai descrivendo è molto corretto, tecnicamente, solo . Sì, hai provato a documentare, hai cercato di imporre standard, ma tu (apparentemente) non hai comunicato.

Bene, la tua squadra ti ha appena comunicato, piuttosto clamorosamente. Dissero: "Ehi, Yippie, non stai comunicando!" La forma più potente di comunicazione che conosco è l'accoppiamento. Paio. Fino a quando non lo ottengono, o finché non ti convincono a farlo in modo diverso.

Come ci diceva Brooks negli ultimi 30 anni, l'integrità concettuale è la parte più importante di qualsiasi progetto. Per qualsiasi sottosistema non banale e completo, dovrebbe esserci esattamente una persona, responsabile della sua progettazione e dell'autorità che ne dirige l'implementazione. Qualcosa è andato storto in questa parte del tuo progetto. Qualunque cosa fosse, l'unica soluzione è il rollback al codice nel repository che esisteva prima che ciò accadesse. Una perdita di 12 giorni non è nulla in confronto con le spese di manutenzione del design rotto. Vorrei anche pensare ai modi per rimuovere le persone coinvolte in questa estrazione da ulteriori lavori sul progetto, poiché si sono dimostrati incompetenti.

Una cosa che farei per i principianti è ottenere un buon strumento per la revisione del codice, utilizzarlo per contrassegnare il codice errato e documentare perché è cattivo e (concettualmente) come dovrebbe essere fatto. Ora, per quello che ho capito ci sono un sacco di cose brutte e quindi sarebbe molto lavoro da recensire; supponendo che tu sia l'unico a vedere qualcosa di sbagliato nel codice, potrebbe non essere fattibile rivedere tutto da solo. Ma potresti contrassegnare i peggiori reati e trasformarli in voci nel tuo sistema di tracciamento dei problemi, assegnato 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 farli rifattorizzare le parti sbagliate e imparare.

Dato il tempo, puoi rivisitare altre parti del codice che sono problematiche e di nuovo riassegnare all'autore originale (cattivo). Dopo un po 'si renderanno conto dei vantaggi di fare un buon lavoro la prima volta.

Suppongo che tu non consideri un rollback della 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 è più alto dell'originale uno. Suppongo anche che anche se non fosse così, non hai il capitale politico per fare quel rollback e farli riscrivere il codice (dal momento che pochissime persone nel pianeta hanno tale capitale). Questi e molti altri sono la complessità di giudicare una situazione che non sto vivendo, ma spero che i miei due centesimi abbiano aiutato.

Una cosa che non ho visto menzionato ma che è venuta di recente dove lavoro sono i problemi di "silos per sviluppatori" e "buy in".

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

Bene, abbiamo appena superato una grande riscrittura di quella libreria che ha probabilmente migliorato il design generale 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 poi appena presentato. "Voilà! Eccolo! Non è carino?"

Ora che devo usare la nuova versione e lo stesso problema c'è - odio come l'ha fatto. E ha lasciato fuori le cose necessarie perché non ha collaborato con nessun altro mentre ci lavorava. Quindi, di nuovo, sto iniziando a implementare le stesse cose in altri posti e modi di lavorare per ciò che devo fare.

Per farla breve - Se vuoi che la qualità del codice aumenti e sia coerente, ti suggerirei di coinvolgere l'intera squadra per stabilire standard, stili, ecc. Inoltre, ogni volta che qualcuno costruirà una base o un nucleo pezzo della tua domanda, suggerirei che la persona responsabile conduca l'intero team nella progettazione delle classi, ecc. in modo che alla fine della giornata, l'intero team debba acquistare l'architettura complessiva dell'applicazione. Inoltre, se sanno come funziona il codice degli altri membri del team, saranno meno propensi a implementarlo nuovamente in un modo che funzioni per loro.

Sei lo sviluppatore senior (o uno degli sviluppatori senior) in questa squadra? Se è così sembra che tu debba tenere dei seminari di formazione sulle migliori pratiche. Probabilmente dovresti ripristinare gran parte del lavoro svolto, tenere una riunione con il tuo team e spiegare il modo giusto per implementare la funzionalità richiesta in un modo che mantenga il design esistente.

Dato che hai una scadenza molto ravvicinata, potresti dover spedire il codice così com'è e refactoring (riscrittura?) dopo il tuo rilascio.

Sembra anche che tu debba definire e applicare alcune pratiche di codice comuni. Hai un processo di revisione del codice in atto nel tuo lavoro? In caso contrario, sembra che ora sia il momento di implementare uno. Le recensioni di codice sono comunque un ottimo modo per insegnare le best practice degli sviluppatori più recenti.

EDIT:

Recentemente mi sono imbattuto in una situazione simile. Il management della mia azienda ha insistito perché usassimo sviluppatori di contratto per scrivere gran parte della nostra applicazione. Il codice che hanno prodotto è stato terribile (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 estendersi con nuove funzionalità. Tra un paio di mesi il mio team avrà riscritto tutto, rendendo efficacemente il denaro investito nello sviluppo del contratto.

Il codice errato costa davvero, è qualcosa di cui potresti voler parlare con i tuoi manager, poiché 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 codifica", niente merda. Mi piacerebbe lavorare sui miei progetti personali tutto il giorno e ancora essere pagato.

Spero che tu possa presentare questo ai poteri che sono e mostrare loro cosa si sarebbe potuto fare in opposizione al Wild West Show che è andato avanti per due settimane. Sembra che dovrai portare qualcosa fuori dalla porta, ma continuare a seguire il problema della mancanza di controlli e coerenza.

Concentrati sui pochi che sono andati con il tuo piano e fai tutto il possibile per aiutarli a risolvere questo pasticcio e metterli sul tuo team in progetti futuri. Potresti dover rifiutare il resto se non riescono a metterlo insieme.