Come può il mio team evitare errori frequenti dopo il refactoring?

Per darti un piccolo esempio: lavoro per un'azienda con circa dodici sviluppatori di Ruby on Rails (+/- stagisti). Il lavoro a distanza è comune. Il nostro prodotto è composto da due parti: un nucleo piuttosto grasso e sottile fino ai grandi progetti dei clienti costruiti su di esso. I progetti dei clienti di solito espandono il nucleo. La sovrascrittura delle funzionalità principali non avviene. Potrei aggiungere che il nucleo ha alcune parti piuttosto brutte che hanno urgente bisogno di rifatturazioni. Ci sono specifiche, ma principalmente per i progetti dei clienti. La parte peggiore del core non è testata (non come dovrebbe essere ...).

Gli sviluppatori sono divisi in due team, lavorando con uno o due PO per ogni sprint. Di solito, un progetto cliente è strettamente associato a uno dei team e degli OP.

Ora il nostro problema: piuttosto frequentemente, ci spezziamo a vicenda. Qualcuno del team A espande o trasforma la funzione principale Y, causando errori imprevisti per uno dei progetti dei clienti del team B. Per lo più, i cambiamenti non sono annunciati sulle squadre, quindi i bug colpiscono quasi sempre inaspettati. La squadra B, incluso l'OP, ha ritenuto che la funzione Y fosse stabile e non l'ha testata prima di rilasciarla, ignara delle modifiche.

Come sbarazzarsi di quei problemi? Che tipo di "tecnica di annuncio" mi puoi consigliare?

Consiglierei di leggere Lavorando in modo efficace con il codice legacy di Michael C. Feathers . Spiega che hai davvero bisogno di test automatizzati, come puoi facilmente aggiungerli, se non li hai già, e quale "odore di codice" refactoring in che modo.

Oltre a ciò, un altro problema fondamentale nella tua situazione sembra una mancanza di comunicazione tra le due squadre. Quanto sono grandi queste squadre? Stanno lavorando su diversi arretrati?

È quasi sempre una cattiva pratica dividere i team in base alla propria architettura. Ad esempio un team principale e un team non core. Invece, creerei team su domini funzionali, ma tra componenti.

La parte peggiore del core non è testata (come dovrebbe essere ...).

Questo è il problema. Il refactoring efficiente dipende fortemente dalla suite di test automatizzati. Se non li hai, iniziano a comparire i problemi che stai descrivendo. Ciò è particolarmente importante se si utilizza un linguaggio dinamico come Ruby, in cui non esiste un compilatore per rilevare errori di base relativi al passaggio di parametri ai metodi.

Le precedenti risposte che indicano migliori test unitari sono buone, ma ritengo che potrebbero esserci problemi più fondamentali da affrontare. Sono necessarie interfacce chiare per accedere al codice principale dal codice per i progetti del cliente. In questo modo, se si esegue il refactoring del codice principale senza alterare il comportamento osservato attraverso le interfacce , il codice dell'altro team non si interromperà. Ciò renderà molto più facile sapere cosa può essere refactored "in modo sicuro" e che cosa ha bisogno di una, eventualmente rottura dell'interfaccia, riprogettazione.

Altre risposte hanno messo in evidenza punti importanti (più unit test, feature team, interfacce pulite per i componenti principali), ma c'è un punto che trovo mancante, ovvero il versioning.

Se congeli il comportamento del tuo core eseguendo una release ¹ e inserisci quella release in un sistema di gestione di artefatti privato ² , qualsiasi progetto del cliente può dichiarare la sua dipendenza dalla versione core X e non verrà interrotto dalla prossima versione X + 1 .

La "politica di annuncio" si limita quindi a disporre di un file CHANGES insieme a ciascuna versione o a una riunione del team per annunciare tutte le funzionalità di ogni nuova versione principale.

Inoltre, penso che sia necessario definire meglio ciò che è "core" e quale sottoinsieme è "chiave". Sembri (correttamente) evitare di apportare molte modifiche ai "componenti chiave", ma permetti frequenti modifiche a "core". Per fare affidamento su qualcosa, devi mantenerlo stabile; se qualcosa non è stabile, non chiamarlo core. Forse potrei suggerire di chiamarlo componenti "helper"?

EDIT : se segui le convenzioni nel sistema di versione semantica , qualsiasi modifica incompatibile nell'API del core deve essere contrassegnata da una modifica della versione principale . Cioè, quando si modifica il comportamento del nucleo esistente in precedenza o si rimuove qualcosa, non si aggiunge semplicemente qualcosa di nuovo. Con tale convenzione, gli sviluppatori sanno che l'aggiornamento dalla versione '1.1' a '1.2' è sicuro, ma passare da '1.X' a '2.0' è rischioso e deve essere attentamente esaminato.

^{1: Penso che questo sia chiamato un gioiello, nel mondo di Ruby
2: l'equivalente di Nexus in Java o PyPI in Python}

Come altre persone hanno detto, una buona suite di unit test non risolverà il problema: avrai problemi durante l'unione delle modifiche, anche se ogni suite di test del team supera.

Lo stesso vale per TDD. Non vedo come possa risolverlo.

La tua soluzione non è tecnica. Devi definire chiaramente i confini "fondamentali" e assegnare un ruolo di "cane da guardia" a qualcuno, che sia lo sviluppatore principale o l'architetto. Qualsiasi modifica al core deve passare attraverso questo watchdog. È responsabile di assicurarsi che ogni risultato di tutte le squadre si fonderà senza troppi danni collaterali.

Come soluzione più a lungo termine, è necessaria anche una comunicazione migliore e più tempestiva tra i team. Ognuno dei team che utilizzerà mai, ad esempio, la funzione principale Y, deve essere coinvolto nella costruzione delle prove previste per la funzione. Questa pianificazione, di per sé, metterà in evidenza i diversi casi d'uso inerenti alla caratteristica Y tra i due team. Una volta che il modo in cui la funzionalità dovrebbe funzionare è inchiodato e le prove sono implementate e concordate, è necessario un ulteriore cambiamento nel tuo schema di implementazione. Il team che rilascia la funzione è necessario per eseguire il testcase, non il team che sta per usarlo. L'eventuale compito che dovrebbe causare collisioni è l'aggiunta di un nuovo testcase da parte di entrambi i team. Quando un membro del team pensa a un nuovo aspetto della funzione che non è stato testato, dovrebbero essere liberi di aggiungere un testcase che hanno verificato passando nella propria sandbox. In questo modo, le uniche collisioni che si verificheranno saranno a livello di intento e dovrebbero essere inchiodate prima che la funzione refactored venga rilasciata in natura.

Sebbene ogni sistema necessiti di suite di test efficaci (il che significa, tra le altre cose, automazione), e mentre questi test, se usati in modo efficace, rileveranno questi conflitti prima di quanto non siano ora, questo non affronta i problemi sottostanti.

La domanda rivela almeno due problemi sottostanti: la pratica di modificare il "core" al fine di soddisfare i requisiti per i singoli clienti e l'incapacità dei team di comunicare e coordinare il loro intento di apportare modifiche. Nessuna di queste sono cause alla radice e dovrai capire perché questo è stato fatto prima di poterlo risolvere.

Una delle prime cose da determinare è se sia gli sviluppatori che i gestori si rendono conto che qui c'è un problema. Se almeno alcuni lo fanno, allora devi scoprire perché o pensano di non poter fare nulla al riguardo o scelgono di non farlo. Per coloro che non lo fanno, potresti provare ad aumentare la loro capacità di anticipare in che modo le loro azioni attuali possono creare problemi futuri o sostituirli con persone che possono. Fino a quando non avrai una forza lavoro consapevole di come stanno andando le cose, è improbabile che tu sia in grado di risolvere il problema (e forse nemmeno allora, almeno a breve termine).

Potrebbe essere difficile analizzare il problema in termini astratti, almeno inizialmente, quindi concentrati su un incidente specifico che ha provocato un problema e prova a determinare come è successo. Poiché è probabile che le persone coinvolte siano difensive, sarà necessario essere vigili per giustificazioni egoistiche e post-hoc al fine di scoprire cosa sta realmente accadendo.

C'è una possibilità che esito a menzionare perché è così improbabile: i requisiti dei clienti sono così disparati che non c'è comunanza sufficiente per giustificare il codice core condiviso. Se è così, allora in realtà hai più prodotti separati e dovresti gestirli come tali e non creare un accoppiamento artificiale tra di loro.

Sappiamo tutti che i test unitari sono la strada da percorrere. Ma sappiamo anche che è realisticamente retrodiffondere questi elementi al nucleo è difficile.

Una tecnica specifica che potrebbe essere utile durante l'estensione della funzionalità consiste nel provare temporaneamente e localmente a verificare che la funzionalità esistente non sia stata modificata. Questo può essere fatto in questo modo:

Pseudo codice originale:

def someFunction
   do original stuff
   return result
end

Codice di prova sul posto temporaneo:

def someFunctionNew
   new do stuff
   return result
end

def someFunctionOld
   do original stuff
   return result
end

def someFunction
   oldResult = someFunctionOld
   newResult = someFunctionNew
   check oldResult = newResult
   return newResult
end

Esegui questa versione attraverso qualsiasi test a livello di sistema esistente. Se tutto va bene, sai che non hai rotto le cose e puoi quindi procedere con la rimozione del vecchio codice. Si noti che quando si controlla la corrispondenza dei risultati vecchi e nuovi, è possibile anche aggiungere codice per analizzare le differenze per acquisire casi che si sa che dovrebbero essere diversi a causa di una modifica prevista come una correzione di bug.

"Principalmente, i cambiamenti non sono annunciati sui team, quindi i bug colpiscono quasi sempre inaspettatamente"

Problemi di comunicazione a nessuno? Che dire di (oltre a quello che tutti gli altri hanno già sottolineato, che dovresti eseguire test rigorosi) per assicurarti che ci sia una comunicazione adeguata? Che le persone siano consapevoli che l'interfaccia su cui stanno scrivendo cambierà nella prossima versione e quali saranno tali cambiamenti?
E dare loro l'accesso a almeno un'interfaccia fittizia (con implementazione vuota) il più presto possibile durante lo sviluppo in modo che possano iniziare a scrivere il proprio codice.

Senza tutto ciò, i test unitari non faranno molto se non sottolineare durante le fasi finali che c'è qualcosa che va fuori di testa tra le parti del sistema. Lo vuoi sapere, ma lo vuoi sapere presto, molto presto e avere le squadre che parlano tra loro, coordinare gli sforzi e avere effettivamente accesso frequente al lavoro svolto dall'altra squadra (quindi si impegna regolarmente, non uno massiccio commettere dopo alcune settimane o mesi, 1-2 giorni prima della consegna).
Il tuo bug NON è nel codice, certamente non nel codice dell'altra squadra che non sapeva che stavi scherzando con l'interfaccia contro cui stanno scrivendo. Il tuo bug è nel tuo processo di sviluppo, la mancanza di comunicazione e collaborazione tra le persone. Solo perché sei seduto in stanze diverse non significa che dovresti isolarti dagli altri ragazzi.

In primo luogo, hai un problema di comunicazione (probabilmente anche collegato a un problema di team building ), quindi penso che una soluzione al tuo caso dovrebbe essere focalizzata su ... beh, sulla comunicazione, piuttosto che sulle tecniche di sviluppo.

Dò per scontato che non è possibile congelare o fork il modulo principale quando si avvia un progetto del cliente (altrimenti è necessario semplicemente integrare nei programmi della propria società alcuni progetti non relativi al cliente che mirano ad aggiornare il modulo principale).

Quindi ci resta il problema di provare a migliorare la comunicazione tra i team. Questo può essere affrontato in due modi:

• con gli esseri umani. Ciò significa che la tua azienda designa qualcuno come l' architetto del modulo principale (o qualunque linguaggio che sia adatto al top management) che sarà responsabile della qualità e della disponibilità del codice. Questa persona incarnerà il nucleo. Pertanto, sarà condivisa da tutte le squadre e assicurerà una corretta sincronizzazione tra di loro. Inoltre, dovrebbe anche agire come revisore del codice impegnato nel modulo principale per mantenere la sua coerenza;
• con strumenti e flussi di lavoro. Imponendo l' integrazione continua sul core, renderai il codice core stesso il mezzo di comunicazione. Ciò richiederà prima qualche sforzo (con l'aggiunta di suite di test automatizzate su di esso), ma poi i rapporti CI notturni saranno un aggiornamento di stato grossolano del modulo principale.

Puoi trovare ulteriori informazioni su CI come processo di comunicazione qui .

Infine, avrai ancora un problema con la mancanza di lavoro di squadra a livello aziendale. Non sono un grande fan degli eventi di team building, ma questo sembra un caso in cui sarebbero utili. Hai incontri a livello di sviluppatore su base regolare? Puoi invitare persone di altri team alle retrospettive del tuo progetto? O forse hai qualche birra del venerdì sera a volte?