Esiste un ruolo di "refactoring / maintainability group" nelle società di software?

Non ho mai sentito parlare di una cosa simile in nessuna azienda per la quale ho lavorato o intervistato. Le aziende normalmente vogliono pagare solo per nuove funzionalità o modifiche che hanno miglioramenti misurabili per gli utenti finali (come i miglioramenti delle prestazioni). Il codice di refactoring non lo fa in modo direttamente misurabile.

Quello che ho visto in aziende che capiscono e si preoccupano della qualità del codice è che gli sviluppatori sono incoraggiati a rifattorizzare il codice mentre lavorano. Se hai intenzione di modificare un file in ogni caso, puoi tranquillamente ripulirlo mentre sei lì dentro. Aggiungi test unitari, refactoring, esegui uno strumento di analisi statico, ecc.

Questo ha due scopi. Innanzitutto, il codice viene attivamente migliorato nel tempo senza delegare tale compito esclusivamente a sviluppatori. In secondo luogo, il tempo è trascorso solo migliorando il codice che doveva essere modificato comunque. Se si dispone di moduli di codice che non verranno mai più toccati, non ha molto senso passare il tempo a mantenerli. Non ne avranno bisogno. È meglio dedicare meno tempo al solo refactoring di quei moduli che con maggiore probabilità cambieranno in futuro.

Se un programmatore sa che qualcun altro rifasterà il proprio codice, non si prenderà MAI a fare il refactoring del proprio lavoro. Impostare un team separato per il refactoring è come giustificare un codice di scarsa qualità esistente in primo luogo. È come riconoscere che ci saranno problemi e quindi modificare la struttura organizzativa della vostra azienda per farvi fronte. Ammiro la tua passione per il codice di qualità, ma forse in questo caso è meglio dire "non è il mio lavoro". Il refactoring dovrebbe essere uno dal programmatore che scrive il codice, non da una terza parte che non l'ha scritto.

Signore no, non farlo. pensa di trovarti nell'altra posizione: scrivi codice, lo impegni, fai qualche altro lavoro, poi ti viene chiesto di fare alcune correzioni di bug sul tuo codice, quindi ti accorgi che è stato aggiornato, guardalo e vedi che lo fa nessuna somiglianza con ciò che hai scritto in origine.

Anche nel SCM perdi molta tracciabilità - tutti quei metodi spostati e rinominati significano che il codice che hai finito non ha alcuna traccia diretta all'originale, spesso appare troppo cambiato per usare le differenze.

quindi tutto ciò che stai facendo è far incazzare le persone che cerchi e fare clic su alcuni strumenti refactor nel tuo IDE, quindi comunica agli altri programmatori che hai migliorato per loro. Un po 'come Slashdot, dove ogni tanto qualcuno risponde alle risposte sarcastiche al tuo post con "lì, aggiustato quello per te". Potrebbe andar bene se il suo umorismo su /., Non lo sarebbe se lo hai fatto al mio codice - ti direi che era tuo da allora in poi e puoi eseguire la manutenzione su di esso.

Ora, se stai facendo un vero lavoro sul codice, questo è diverso, ma il refactoring è fine a se stesso, anche sotto la guida di "manutenzione" è solo intenzione di infastidire tutti gli altri, e questo è doppio per il "voglio il mio gruppo / dipartimento per essere riconosciuto dalla direzione e da altri gruppi con questo ruolo ufficialmente "- puoi dire" manovre politiche "? Potete immaginare cosa diranno gli altri reparti quando il loro codice si arresta in modo anomalo sul sito del cliente? "E 'stato bello quando l'abbiamo toccato l'ultima volta, deve essere stato il reparto refactoring che l'ha rotto, l'hanno toccato per ultimo."

Quello che potresti provare è convincere il management che varie parti del software richiedono più attenzione, portare le parti povere e vedere se dedicheranno del tempo a migliorarle. Mentre ciò accade, è possibile suggerire di includere alcuni dei gruppi principali su altri carichi di lavoro per aggiungere funzionalità al prodotto principale. Dubito che dovrai tentare di implementare di nuovo le funzionalità di base per loro, ma aumenterai la capacità dei reparti di aggiungere funzionalità che possono essere reinserite nel gruppo principale, quindi avrai maggiori responsabilità per i responsabili.

Dipende da cosa intendi per refactoring e manutenibilità, sia in teoria che in pratica.

Avevamo un gruppo dedicato alla pulizia del codice e alle correzioni di bug. Non ha funzionato così bene, perché, non sorprendentemente, i buoni sviluppatori non vogliono passare tutto il loro tempo a fare pulizia del codice e correzioni di bug.

Alcune organizzazioni scelgono di avere un team dedicato di "ingegneria del software" che tenderà a dedicare molto tempo alla revisione del codice ea guidare gli sviluppatori meno esperti sulle buone pratiche. Tuttavia, questo non è un vero gruppo ingegneristico a meno che non sia strongmente coinvolto nei piani del progetto, nell'architettura, nei piani di test, nel processo di rilascio, ecc. È fondamentale avere questo approccio olistico e preferibilmente una certa quantità di formazione nel software o altra ingegneria, altrimenti, tende a devolvere nella "pulizia" sopra.

In conclusione, gli sviluppatori non fanno buoni bidelli nel lungo periodo. E anche se hai un vero gruppo ingegneristico, questo approccio tende a funzionare meglio con i team interfunzionali, altrimenti altri team potrebbero iniziare a ignorare o addirittura risentirsi dello sforzo, osservandolo come una torre d'avorio.

Non avere una stanza piena di sviluppatori che non fanno altro che refactoring e rearchitecting. Non finirà bene.

Di solito quando le persone eseguono il refactoring, lo fanno tutti utilizzando il refactoring opportunistico . Quindi non penso che troverai un nome comune per una pratica così rara.

Ma nella tua situazione insolita, anche se avere un refactator di tutti sarebbe probabilmente l'ideale, sembra che abbia senso provare.

Tuttavia, gli stessi problemi politici che attualmente impediscono alle persone di refactoring il proprio codice molto probabilmente ti portano giù (il che probabilmente fa parte del perché non c'è un nome per quello che stai pensando). Gli altri team saranno O.K. con te "migliorare" il loro codice? Che cosa succede la prima volta che si introduce un bug nel corso di qualcosa che la gestione non percepisce come prezioso in primo luogo? Cosa succede quando a un altro team non piace il tuo nuovo design?

Non puoi garantire che non ti costerà mai un altro team un po 'di tempo. E quasi qualsiasi argomento per cui si avrà un effetto positivo netto potrebbe essere applicato anche per permettere loro di rifattorici.

È possibile che ciò che stai proponendo sia accettabile, ma lasciare che tutti gli altri refactoring non lo siano, ma l'unico modo in cui posso immaginarlo è se tutti sono d'accordo sul fatto che il refactoring è una buona cosa che fa risparmiare tempo a lungo termine ma a breve termine richiede tempo e la tua squadra è l'unica con sufficiente tempo libero a breve termine. E se altri team si fidano di te a fare i refactoring e sono disposti ad affrontare eventuali problemi li causa.

Avere un gruppo che si concentra esclusivamente sul refactoring e sulla manutenibilità e implementarlo a spese di altri gruppi di sviluppo è pericoloso per la tua organizzazione. Deve esserci un impegno da parte del management superiore, dei tester e di tutti i gruppi di sviluppo per migliorare la qualità del codice tramite il refactoring per migliorare la manutenibilità e ridurre al minimo i bug. Dovrebbe essere responsabilità di tutti migliorare il codice. Quando è necessario eseguire il refactoring, deve essere inserito nel programma di rilascio insieme alle nuove funzionalità. I manager devono essere educati e capire che prendere tempo per migliorare il codice si ripaga a lungo termine, perché il debito tecnico è ciò che porterà un prodotto a uno stridore se non viene pagato come parte del processo di sviluppo in corso. Se tutto quello che stai facendo è costantemente combattere gli incendi da un costante bug fixing, la casa brucerà, perché ovviamente la casa è un pericolo di incendio e ha bisogno di una migliore costruzione e ristrutturazione.

Il gruppo suona più come dovrebbe essere un gruppo di architetti / software dedicato allo sviluppo dell'architettura di prossima generazione che sarà più manutenibile. Il tuo gruppo dovrebbe probabilmente concentrarsi su come dimostrare che il refactoring ripaga sui tipi di "punta-capelli", incoraggiare gli sviluppatori con nuovi metodi e processi ed educare le parti interessate nella gestione per adottare una migliore qualità del codice e portarli a "buy-in" al processo. Preparare un piano per migrare i prodotti verso un'architettura migliore se non altro fissando prima una base semplice. Segui le dolorose lezioni imparate da tutti per supportare i tuoi prodotti e trovare un piano per mitigare quel dolore in futuro.

È abbastanza comune. Ho lavorato in un'azienda di software dove questa era la norma. Hai avuto team dedicati all'implementazione di nuove funzionalità. Poi c'era un team di manutenzione che risolveva i bug che causavano problemi ai client. Il team di manutenzione è caduto sotto il ramo di consulenza / supporto dell'organizzazione.

In quel caso c'erano degli svantaggi per gli sviluppatori, ovvero che lavoravano più a stretto contatto con i clienti, anche trascorrendo del tempo in loco. I team di prodotto che fanno nuovi sviluppi non interagiscono affatto con i clienti (una situazione odiosa).

Sembra più comune nelle società di software e fornitori di outsourcing che per la fornitura interna. Sono in finanza e posso solo pensare a una banca che ha usato questa struttura in passato. Detto questo, è normale che le squadre tattiche possano raccogliere questo tipo di problemi come parte del loro mandato. Non è esattamente la stessa cosa, ma simile.

Se la tua squadra è sottoutilizzata devi stare un po 'attenta. Sottoutilizzato può essere tradotto in "costo inutile" abbastanza facilmente, quindi il tuo team di X può diventare abbastanza rapidamente un team di X-1.

Un approccio preferibile potrebbe essere dedicare un po 'più di tempo alle correzioni e incorporare alcuni tempi di refactoring non scritti nel tempo di risoluzione dei bug.

Dipende da come funziona la tua azienda. La cosa interessante è che non lo sai, quindi se hai un team leader, varrebbe la pena discuterne con loro. Se non lo sanno, invitali a parlare con la prossima persona sulla catena (sii coinvolto in quello, non consegnarlo). Se non sanno se ciò si adatta alle aspettative del management, potresti rientrare più nella categoria di costo piuttosto che nella categoria di attività.