Come posso assumermi la responsabilità del mio codice quando un collega apporta miglioramenti inutili senza preavviso?

Uno dei miei compagni di squadra è un tuttofare nel nostro negozio IT e rispetto la sua intuizione.

Tuttavia, a volte rivede il mio codice (è il secondo al comando del nostro team leader, quindi è previsto) senza un avviso. Quindi a volte esamina le mie modifiche prima che completino l'obiettivo finale e apporta subito le modifiche ... e ha persino rotto il mio lavoro una volta.

Altre volte ha apportato inutili miglioramenti ad alcuni dei miei codici di 3+ ​​mesi.

Questo mi dà fastidio per alcuni motivi:

1. Non sempre mi viene data la possibilità di correggere i miei errori
2. Non si è preso il tempo di chiedermi cosa stavo cercando di realizzare quando è confuso, il che potrebbe influire sui suoi test o modifiche
3. Non penso sempre che il suo codice sia leggibile
4. Le scadenze non sono un problema e il suo carico di lavoro attuale non richiede alcun lavoro nei miei progetti se non quello di rivedere le mie modifiche al codice.

Ad ogni modo, gli ho detto in passato di tenermi informato se vede qualcosa nel mio lavoro che vuole cambiare in modo che io possa prendere la proprietà del mio codice (forse avrei dovuto dire "carenze") e non è stato reattivo .

Temo di potermi comportare in modo aggressivo quando gli chiedo di spiegarmi le sue modifiche.

È solo una persona tranquilla che si tiene per sé, ma le sue azioni continuano. Non voglio impedirgli di apportare modifiche al codice (non come avrei potuto), perché siamo una squadra - ma voglio fare la mia parte per aiutare la nostra squadra.

Chiarimenti aggiunti:

• Condividiamo 1 ramo di sviluppo. Non aspetto fino a quando tutte le mie modifiche non completano una singola attività perché rischio di perdere del lavoro significativo, quindi mi assicuro che le mie modifiche vengano sviluppate e non si interrompa nulla.
• La mia preoccupazione è che il mio compagno di squadra non spieghi il motivo o lo scopo dei suoi cambiamenti. Non penso che dovrebbe aver bisogno della mia benedizione, ma se non siamo d'accordo su un approccio ho pensato che sarebbe meglio discutere i pro e i contro e prendere una decisione una volta che entrambi capiremo cosa sta succedendo.
• Non ne ho ancora discusso con il nostro team, in quanto preferirei risolvere i disaccordi personali senza coinvolgere la direzione a meno che non sia necessario. Dato che la mia preoccupazione sembrava più un problema personale che una minaccia per il nostro lavoro, ho scelto di non disturbare il comando del team. Sto lavorando alle idee del processo di revisione del codice - per aiutare a promuovere i vantaggi di revisioni del codice più organizzate senza fare tutto ciò che riguarda i miei animali domestici.

Penso che la maggior parte degli sviluppatori si trovi in ​​questa posizione ad un certo punto e spero che ogni sviluppatore che si è sentito vittima si renda conto di quanto sarà frustrante quando diventerà senior e si sentirà in dovere di ripulire il codice scritto dai junior.

Per me, evitare conflitti in questa situazione si riduce a due cose:

1. Cortesia . Parlare con qualcuno del suo codice consente a un dev di sapere che sei interessato e puoi discuterne come professionisti cresciuti.

2. Dimentica la "proprietà del codice": il team possiede il codice . Altre persone che vogliono apportare le modifiche sono una buona cosa. Se uno sviluppatore senior apporta modifiche che sono "illeggibili" o peggio, esegui il backup. Non devi essere aggressivo, fai solo sapere a un editore che le sue modifiche non hanno funzionato e sei più che felice di discutere della tua inversione.

Ricorda, la proprietà del codice del team è ottima e taglia in entrambi i modi. Se vedi qualcosa che non ha senso nel codice di qualcun altro, correggilo. Essere eccessivamente possessivi e inadeguatamente comunicativi è un modo infallibile per creare un ambiente di sviluppo velenoso.

Tu e la maggior parte dei rispondenti affrontiamo questo problema come un problema di comunicazione tra due colleghi, ma non credo proprio che lo sia. Quello che descrivi suona più come un processo di revisione del codice orribilmente rotto di ogni altra cosa.

Innanzitutto, dici che il tuo collega è al secondo posto e si prevede che rivedrà il tuo codice. È solo sbagliato. Per definizione, le revisioni dei codici peer non sono gerarchiche e certamente non riguardano solo la ricerca di difetti. Possono anche fornire esperienze di apprendimento (per tutti i soggetti coinvolti), un'opportunità per l'interazione sociale e dimostrare uno strumento prezioso per costruire la proprietà del codice collettivo. Dovresti anche rivedere il suo codice di volta in volta, imparare da lui e correggerlo quando ha torto (nessuno lo capisce sempre).

Inoltre, dici che il tuo collega apporta subito delle modifiche. Anche questo è sbagliato, ma ovviamente lo sai già; non avresti fatto questa domanda se il suo approccio gung ho non fosse un problema. Tuttavia, penso che tu stia cercando una soluzione nel posto sbagliato. Ad essere sincero, il tuo collega mi ricorda un po 'di ... me, e ciò che ha funzionato per me in situazioni simili è stato un processo di revisione ben definito e solido e una serie di strumenti fantastici. Non vuoi davvero impedire al tuo collega di rivedere il tuo codice e chiedergli di fermarsi e parlare con te prima che ogni piccola modifica non funzionerà davvero. Potrebbe, per un po ', ma presto raggiungerà un punto in cui diventerà troppo fastidioso e tornerai da dove hai iniziato, o peggio: smetterà di rivedere il tuo codice.

Una chiave per una risoluzione qui potrebbe essere uno strumento di revisione del codice peer. Di solito evito i consigli sui prodotti, ma per le revisioni del codice Atlassian's Crucibleè davvero un salvavita. Quello che fa può sembrare molto semplice, e lo è, ma ciò non significa che non sia incredibilmente fantastico. Si collega al tuo repository e ti dà l'opportunità di rivedere singoli changeset, file o gruppi di file. Non puoi cambiare alcun codice, ma commenti tutto ciò che non ti sembra giusto. E se devi assolutamente cambiare il codice di qualcun altro, puoi semplicemente lasciare un commento con il changeset che spiega le tue modifiche. Il video introduttivo alla pagina del prodotto di Crucible vale la pena guardare se vuoi maggiori dettagli. Il prezzo di Crucible non è per tutti, ma ci sono numerosi strumenti di peer review disponibili gratuitamente. Uno con cui ho lavorato e apprezzato è Review Board e sono sicuro che troverai molti altri con una semplice ricerca su Google.

Qualunque strumento tu scelga, cambierà completamente il tuo processo. Non c'è bisogno di fermarsi, scendere dalla sedia, interrompere l'altra persona e discutere i cambiamenti; tutto quello che devi fare è impostare un po 'di tempo libero ogni settimana ed esaminare i commenti (una volta alla settimana è solo un suggerimento. Conosci il tuo programma e la routine quotidiana meglio di me). Ancora più importante, le recensioni principali sono archiviate in un database da qualche parte e puoi recuperarle in qualsiasi momento. Non sono discussioni effimere intorno al dispositivo di raffreddamento dell'acqua. Il mio caso d'uso preferito per le vecchie recensioni è quando introduco un nuovo membro del team nella nostra base di codice. È sempre bello quando posso guidare qualcuno di nuovo attraverso la base di codice sottolineando dove eravamo esattamente bloccati, dove avevamo opinioni diverse, ecc.

Andando avanti, dici che non trovi sempre leggibile il codice di questo collega. Questo mi fa sapere che non hai un insieme comune di standard di codifica, e questa è una cosa negativa. Ancora una volta potresti affrontarlo come un problema di persone o puoi affrontarlo come un problema di processo, e di nuovo suggerirei fortemente quest'ultimo. Riunisci il tuo team e adotta al più presto uno stile di codifica e un insieme di standard comuni. Non importa se hai scelto una serie di standard comuni nel tuo ecosistema di sviluppo o se ne hai inventato uno tuo. Ciò che conta davvero è che i tuoi standard siano coerenti e che ti attieni a loro. Moltissimi strumenti là fuori possono aiutarti, ma questa è una discussione completamente diversa. Solo per iniziare, una cosa molto semplice da fare è fare in modo che un hook pre-commit esegua una sorta di formattatore di stile sul tuo codice. Puoi continuare a scrivere il tuo codice come preferisci e lasciare che lo strumento lo "aggiusti" automagicamente prima che gli altri lo vedano.

Infine, in un commento menzionate che la direzione non crede che i singoli rami di sviluppo siano necessari. Bene, c'è un motivo per cui li chiamiamo "rami di sviluppo" e non "rami di gestione". Mi fermerò qui perché non c'è motivo per cui il rant che si sta formando nella mia testa per uscire.

Detto questo, sappi che non dubito che il tuo collega sia (un po ') in colpa qui. Non è questo il mio punto, il mio punto è che anche l'intero processo di sviluppo è in errore, ed è qualcosa che è più facile da risolvere. Armati con gli strumenti adeguati, esplora i numerosi processi formali e informali e scegli quelli che si adattano al tuo team. Presto raggiungerai un punto in cui ti renderai conto che la maggior parte dei tuoi "problemi di persone" non esistono più. E per favore non ascoltare nessuno (incluso te stesso) che fa nascere la scusa "siamo una piccola squadra, non abbiamo bisogno di tutto questo". Un team di sviluppatori competenti può impostare gli strumenti necessari in meno di una settimana, automatizzare tutto ciò che può essere automatizzato e non tornare mai più indietro.

PS. "Proprietà del codice" è un termine nebuloso, costantemente dibattuto, e significa cose diverse per persone diverse. Puoi trovare una brillante raccolta della maggior parte delle opinioni diverse (e talvolta antitetiche) su C2 .

Cosa c'è nel processo che ti fa desiderare di assumerti la responsabilità del "tuo codice"? Hai la sola responsabilità di far funzionare determinate funzionalità? Il capo ha detto "Michael, voglio che tu ti assuma la responsabilità di ..."? O la tua responsabilità è implicita, in quanto il capo e il resto della squadra ti guardano ogni volta che certe funzionalità sono rotte?

Ad ogni modo, se hai la responsabilità, allora hai bisogno dell'autorità sul codice. La prossima volta che l'altro collega apporta modifiche unilaterali e il lead torna a te per risolverli, dovresti sederti con il lead e chiedere di allineare la tua autorità e responsabilità.

Non che questo risolva l'intera situazione, ma potresti provare ad aggiungere altri commenti al tuo codice sorgente.

1. Se il codice non è completo, potrebbe essere contrassegnato come tale.
2. Se lo scopo di un blocco di codice non è auto-documentante, è necessario documentarlo.

Tutto sommato, cerca di fare la limonata invece di perdere tempo a succhiare i limoni. Come ha detto Michael, in generale, i compagni di squadra non sono disposti a farti sembrare cattivo. Cerca di imparare dai tuoi errori e applicali alle revisioni future.

Se ritieni che i suoi cambiamenti abbiano un impatto negativo, ti preghiamo di darne voce (diplomaticamente). Se fossi in me, vorrei semplicemente chiedere perché sono state apportate modifiche specifiche e vedere se è possibile difendere le modifiche originali. Anche i tuoi colleghi senior sono umani. È del tutto possibile che abbia perso qualcosa e / o non sia a conoscenza di alcun impatto negativo che sta fornendo.

Ognuno implicitamente "possiede il proprio codice", indipendentemente dalla politica, dalla legalistica o dall'economia - è la "natura delle cose" - si sente naturalmente una connessione personale con il proprio lavoro.

Se il tuo collega si sta impegnando nel comportamento che hai descritto e non risponde quando chiedi un testa a testa , quel collega è sconsigliato, per non dire altro, e potrebbe cercare di indebolirti (per dire il peggio ... .) - NON suona come un giocatore di squadra.

Un buon collaboratore sarebbe un contatto con voi e segnalare il problema con il codice a voi - e lasciare che si fissa / modificarlo, o rispondere in modo appropriato. Sono molto grato che anche quando ero un newbee, miei mentori sempre mi ha fatto notare quello che stavo facendo male, ha spiegato il motivo per cui e lasciare (o ha fatto ) di risolvere il problema. Questo mi ha reso un programmatore migliore e tutti ne hanno beneficiato. Ed è quello che ho sempre fatto quando ho rivisto il lavoro svolto da altri. Quindi tu (o chiunque) in realtà impari qualcosa dal tuo "tuttofare", e il codice e il team migliorano, incluso il tuo insegnante: Insegnare aiuta a capire.

Se è possibile, vorrei discutere la questione in privato con il Team Leader. Sulla base della descrizione della situazione, un buon team leader si schiererà dalla tua parte - uno cattivo non lo farà .... Ovviamente questo richiede cautela - dovrai giudicarlo da solo.

Se scrivi il codice, dovrei esaminarlo.

Se cambio il codice durante la revisione, il codice non è più il codice che ho esaminato, ma il codice che ho modificato. Pertanto deve essere rivisto. Probabilmente da te.

Se commetto il tuo nuovo codice con le mie modifiche senza che qualcuno le riveda, allora ho commesso (1) una modifica non rivista e (2) il peggior peccato possibile se le revisioni del codice sono prese sul serio.

Penso che tu lo stia gestendo nel modo giusto per ora - ma ci sarà presto un punto di non ritorno in cui ti distrae nella misura in cui potresti non essere affatto felice di programmare in questo modo.

Se fossi in te, richiederei un rapido one-to-one con questa persona e spiegherei il mio PoV con calma ma con fermezza. La proprietà della squadra di codice ecc. Va bene, ma a meno che tu non dia a tutti gli sviluppatori abbastanza spazio per mettere a punto il suo lavoro, commettere errori e migliorare non costruirai mai un buon codice. Questa può essere un'area di attrito prima piuttosto che dopo.

(C'è una risposta totalmente diversa se questo fosse su workplace.stackexchange. Capire il modo corretto di fare le revisioni del codice è una cosa semplice. Convincere il tuo collega a rispettare questo è molto più difficile).