Come posso approcciarmi ad apportare miglioramenti al suo codice senza dover discutere (educatamente) per giorni per ottenerlo?

In base al testo di questa domanda, sembra come una persona molto ragionevole e ha fatto le cose necessarie per cercare di essere inclusivo e premuroso dell'altro sviluppatore quando introduce nuove tecniche.

A questo punto, penso che dovresti portare questo all'attenzione di il tuo manager . Non dovresti dover discutere ogni singolo impegno, soprattutto quando l'approccio è chiaramente migliore.

Hai già provato a lavorare direttamente con l'individuo e si è dimostrato estenuante. Lascia che il tuo manager se ne occupi in futuro.

Come posso approcciarmi ad apportare miglioramenti al suo codice senza dover litigare (educatamente) per giorni prima che venga unito?

Non avvicinatelo più quando apporto il codice. L'hai già tentato in più occasioni e i risultati non sono stati desiderabili.

A questo punto, poiché hai dichiarato che la sua autorizzazione non è necessaria, vai semplicemente avanti e lavora con i tuoi colleghi per migliorare il codice quando necessario. Non tentare di riscrivere l'intero programma, modifica e migliora solo il codice necessario per il tuo compito specifico.

Non menzionerei nulla al collega fino a quando le modifiche non saranno state completate e accuratamente testate e puoi dimostrare che il nuovo codice è un effettivo miglioramento. Questo è molto importante, il codice che tu e gli altri tuoi colleghi scrivete deve essere migliore dell'originale, altrimenti non solo turbi il collega, ma perdi credibilità.

Dovresti considerare separatamente i problemi di (a) preferenza e (b) prestazioni. I due problemi che descrivi (utilizzando regex per l'analisi o dando priorità al disaccoppiamento) potrebbero essere più nel campo di preferenze di composizione e non limitatori di prestazioni importanti.

In entrambi i casi, tuttavia, dovresti concentrarti sul valore in gioco (quante ore o grattacapi o dollari sarebbero risparmiati da un cambiare) ed evitare di criticare le implementazioni esistenti , indipendentemente da quanto possano essere dannose.

Renditi conto anche che il debito tecnologico è indesiderabile, ma accade in ogni squadra e risolverlo può essere un costo considerevole. A volte è davvero meglio lasciare le cose come stanno anche quando devi creare costantemente soluzioni alternative.

(a) Per problemi di preferenze diverse , è utile descrivere le alternative a cui pensi, ma probabilmente il tuo collega avrà l'ultima parola su come è composto il pacchetto. Dovresti anche chiarire che i tuoi suggerimenti sono la tua preferenza e non un modo oggettivamente migliore per comporre codice. Anche dove sono stati creati standard di composizione altamente opinioni (ad esempio PEP-8 & Black), questi rimangono opinioni e potrebbero non essere adatti ai problemi su cui lavora la tua organizzazione. Discutere le preferenze come pari sarà un approccio molto più amichevole che criticare la preferenza del tuo collega.

(b) Per questioni di software e / o prestazioni del team , è anche utile suggerire alternative, ma adottare alcune misure ragionevoli per assicurarti che i tuoi suggerimenti siano produttivi:

1. Qual è l'impatto quantificato sul rendimento? Se un L'alternativa all'analisi con regex viene eseguita 100 volte più velocemente, quante ore di calcolo verrebbero risparmiate nel corso di un anno?
2. Che tipo di sforzo richiederà la rielaborazione? Moltiplica la stima per 3. E ora che sai che stai per moltiplicare per 3, potresti essere sbilanciato verso il basso, quindi moltiplica di nuovo per 3.
3. Qual è la rilevanza delle prestazioni della sezione di codice per le esigenze dei tuoi clienti? I tuoi clienti si preoccupano delle prestazioni (sia in termini di latenza di elaborazione che di costo)?
4. Com'è la tua idea di miglioramento delle prestazioni rispetto ad altre idee di miglioramento? Probabilmente ci sono molte idee nel "parcheggio" per il tuo team: questo miglioramento delle prestazioni è abbastanza sostanziale da diventare la priorità?

Dopo aver risposto a queste domande, potresti proporre l'idea al tuo team.

Supponendo che abbiate entrambi la stessa anzianità: se un ragazzo mi dicesse che sto cambiando il suo codice nel modo sbagliato (e so per certo di non esserlo), gli direi di aggiustarlo a modo suo . Poi, quando afferma di non avere il tempo, glielo dico gentilmente di stfu. Stai estendendo il problema trattandolo come un fiore delicato. Oppure opzione due: smettila di aiutarlo al 100%. Chiedi ai tuoi colleghi di fare lo stesso. Quindi il suo problema di non essere in grado di correggere il suo codice in modo tempestivo salirà sicuramente alla direzione. Quando la direzione chiede perché non siete giocatori di squadra, tutti puntate il dito contro di lui. Onestamente questo ragazzo avrebbe dovuto essere licenziato anni fa. Il tuo manager sta dormendo di sicuro. Anche il manager più senza mani dovrebbe essere consapevole di quanto tempo ci vuole per sistemare questo codice di ragazzi.

Se ti classifica fuori quella è un'altra storia. Forse è ora di cercare un altro lavoro.

Prima di tutto

• È tua opinione che il suo design e il suo codice siano difettosi.
• È la sua opinione che non lo sia.

Le opinioni fanno guerre di trincea e colleghi infelici. Devi renderlo misurabile. Esistono strumenti in grado di analizzare il codice ed estrarre elementi come la profondità della gerarchia, la copertura dei test, ecc. Trova uno strumento in grado di misurare ciò che ritieni importante e fare in modo che il team concordi su ciò che dovrebbe essere fatto e usa lo strumento per vederti arrivare.

Forse puoi analizzare perché la correzione dei bug attualmente richiede così tanto tempo, così puoi aiutarlo a migliorare dove vuole migliorare. Potresti sbagliarti nelle tue supposizioni.

Per interpretare l'avvocato del diavolo, qualcuno che non è d'accordo con il tuo collega ha tentato di capire il loro punto di vista?

Hanno lavorato da soli a questo progetto per anni (qualcuno ha espresso interesse prima d'ora?) e ora , nonostante abbiano un prodotto affidabile e ampiamente testato con un codice sorgente di facile lettura, le persone vogliono annullare il loro codice perché pensano che il loro codice sia migliore.

Se il tuo collega non è in grado di visualizzare il risultato, quindi non riesci a comunicare l'idea nel contesto del prodotto. Ricorda, questo è qualcosa a cui hanno pensato per diversi anni, lo sanno dentro e fuori.

La soluzione a questo problema è un semplice metodo in 4 fasi:

1. Suggerisci (dai il tuo suggerimento);
2. Ascolta e riconosci (ascolta la loro risposta);
3. Negozia (trova un compromesso);
4. Azione (enact il compromesso).

Ad essere perfettamente onesto, però, se sto leggendo la situazione direttamente dalla domanda, probabilmente non dovrai preoccuparti del collega per molto più tempo come loro probabilmente sta già pensando di cambiare datore di lavoro poiché l'ambiente si sentirebbe molto "contro di loro".

Aggiungi il lavoro che ritieni debba essere fatto alla tua lista di cose da fare, foglio di lavoro, tfs, problemi, jira, qualunque cosa. Chiedi al tuo manager di firmare la conclusione. Allora fallo.

Non consiglierei un incontro (formale o meno) per discutere cosa dovrebbe essere fatto e non aggiungerei tutto il lavoro in una volta. Scegli qualcosa che pensi possa essere migliorato e inseriscilo nella lista. Allora fallo. Risciacquare, insaponare, ripetere.