Come posso rendere il refactoring una priorità per il mio team?

La base di codice con cui lavoro quotidianamente non ha test automatizzati, denominazione incoerente e tonnellate di commenti come "Perché è qui?", "Non sono sicuro se questo è necessario" o "Questo metodo non è chiamato giusto" e il codice è disseminato di "Log delle modifiche" nonostante il fatto che utilizziamo il controllo del codice sorgente. Basti dire che la nostra base di codice potrebbe usare il refactoring.

Abbiamo sempre il compito di correggere i bug o aggiungere nuove funzionalità, quindi non c'è tempo da dedicare al refactoring per essere migliore e più modulare, e non sembra avere la massima priorità.

Come posso dimostrare il valore del refactoring in modo che venga aggiunto ai nostri elenchi di attività? Ne vale la pena di refactoring mentre vado, chiedendo perdono piuttosto che permesso?

"È meglio chiedere perdono che permesso" è vero.

Perché preoccuparsene? Rifattorizza solo le parti più orribili.

Sai già quali sono gli errori più costosi , giusto?

In caso contrario, il passaggio 1 consiste nel definire in modo positivo e inequivocabile il codice problema più costoso, complesso, pieno di errori e infestato da bug.

Identificare il numero di ticket di difficoltà, ore di debug e altri costi molto specifici e molto misurabili .

Quindi correggere qualcosa in quell'elenco di problemi ad alto costo .

Quando devi chiedere perdono, puoi indicare una riduzione dei costi.

Nel caso in cui non si sia a conoscenza, il refactoring richiede test unitari per dimostrare che i comportamenti prima e dopo corrispondono. Idealmente, questo dovrebbe essere un test automatico codificato, ad esempio un test unitario.

Questo significa scegliere una cosa. Scrivi un test unitario. Risolvi quell'unica cosa. Hai apportato due miglioramenti. (1) ha scritto un test e (2) ha corretto il codice.

Iterate.

Segui la regola del boy scout: lascia il campeggio (codice) un po 'meglio di come l'hai trovato. Non ho mai sentito parlare di qualcuno che veniva scritto per aver apportato piccoli miglioramenti al codice "mentre erano lì dentro".

Prenderò un punto di vista forse eccessivamente cinico.

Il refactoring è una pillola così dura da ingoiare. Ottieni la responsabilità e la colpa, e i frutti del tuo lavoro vanno spesso a qualcun altro che si basa sulla tua base di codice pulita.

Direi che se tali pratiche ingegneristiche sono diventate la cultura della tua azienda, potresti dover combattere a un livello superiore. Non stai davvero combattendo per il refactoring, stai combattendo per l'eccellenza ingegneristica, e questo è il tipo di cambiamento che nasce solo nella gestione quando li colpisce in faccia. In quello scenario, probabilmente cercheranno uno zar delle migliori pratiche e tutte le tue grandi idee verranno comunque riassunte.

Prendi in considerazione l'idea di entrare in una società diversa dove prendono più seriamente le pratiche di ingegneria.

Ho notato che molti dei poster qui sembrano essere convinti del problema nella gestione, mentre la domanda non lo menziona.

Andrei oltre: a mio avviso una pessima base di codice non è quasi mai direttamente colpa della direzione. La direzione non ha scritto quel codice, gli sviluppatori hanno fatto (ci sono alcune eccezioni nella mia azienda in cui alcuni dei nostri attuali dirigenti hanno effettivamente scritto la base di codice iniziale). Pertanto, il problema della cultura risiede con gli sviluppatori: se vogliono che la cultura cambi, essi stessi dovranno cambiare.

Cerco di portare questa realizzazione e questo cambiamento di atteggiamento anche ai "miei" sviluppatori. Ogni volta che mi chiedono "quando avremo il tempo di fare il refactoring?", Mi sorprendo e rispondo "dovresti già fare il refactoring tutto il tempo!". L'unico modo in cui credo che tu possa mantenere in salute una base di codice è triplice:

1. Aggiungi sempre e solo codice integro.
2. Correggi sempre il codice non salutare non appena lo vedi.
3. Se per motivi di scadenza non è possibile eseguire 1 o 2, disporre sempre di un elenco di problemi "risolvi immediatamente dopo la scadenza" e non accettare alcuna scusa per non aver superato tale elenco dopo la scadenza.

Invariabilmente la prossima osservazione degli sviluppatori è "ma come possiamo ottenere il tempo per farlo - non abbiamo il tempo adesso?". L'unica risposta corretta (di nuovo IMHO) è "non hai il tempo di NON farlo". Se non mantieni in salute la base di codice, troverai tempi di consegna sempre più lunghi, pianificazioni sempre più imprevedibili, bug che diventano più cattivi e valore in diminuzione.

Il più grande cambiamento di atteggiamento che devi attuare nel team di sviluppo è che la "qualità" non è qualcosa che fai in un determinato momento ("quando abbiamo il tempo di rifattorizzare") - è qualcosa che devi fare TUTTO il tempo.

Finalmente una storia di avvertimento. Se premuto, negherò che sia mai successo. In un'azienda per cui ho lavorato c'era un'applicazione di lunga data con una base di codice legacy di grandi dimensioni che risale a oltre 10 anni fa. Molti sviluppatori tra cui me hanno creduto che questa base di codice legacy fosse cattiva o almeno obsoleta, non all'avanguardia. Quindi abbiamo fatto pressioni per un grande progetto di refactoring con successo, e abbiamo iniziato il progetto di riscrittura dopo il quale abbiamo creduto che tutto sarebbe andato meglio.
Abbiamo lavorato a lungo e duramente per implementare quasi tutto in un modo nuovo e moderno, usando nuove librerie, nuove funzionalità linguistiche. Verso la fine, abbiamo fatto uno sforzo enorme per riunire tutto per consentire una nuova versione dell'applicazione di lunga data con la nuova base di codice migliorata.
Come previsto, la nuova versione ha avuto alcuni problemi iniziali, a causa delle nuove librerie con cui non eravamo ancora così familiari, e di alcune interazioni nel nostro codice che non avevamo previsto. Tuttavia, siamo finalmente riusciti a ottenere il rilascio allo stesso standard delle nostre versioni precedenti e fuori dalla porta. Abbiamo emesso un sospiro di sollievo per il nostro "successo". Quindi un sottogruppo di sviluppatori è tornato alla direzione, chiedendo un nuovo progetto di refactoring perché il nostro nuovo codice non era proprio il proiettile d'argento che si aspettavano che fosse, e hanno visto alcune opportunità per riscrivere completamente alcune cose ...

Morale della storia: spesso le cose non sono così rotte come sembrano, e 'ricominciare' di solito significa che dovrai scambiare una serie di problemi noti con una serie di problemi almeno altrettanto pelosi. Rifattore una parte alla volta!

Qualcuno una volta mi ha detto che quando vado a un'intervista, non dovrei dimenticare che sto anche intervistando la società. È un posto dove voglio lavorare? Fanno recensioni di codice? Hanno test di integrazione automatizzati? Test unitari? Cosa pensano della programmazione in coppia? Personalmente troverei un altro lavoro, e questa volta non dimenticherò di fare alcune domande.

Trova un'altra compagnia, onestamente. Tali miglioramenti al processo di sviluppo richiedono enormi balzi culturali che ci vorrà molto tempo prima che tutti arrivino sulla stessa pagina e per allora non ti preoccuperai tanto.

Se ti senti come se avessi ancora un po 'di lotta in te e non ti fossi ancora messo sotto, allora fai una spinta finale. Cerca di ottenere il massimo supporto dai membri della squadra che la pensano allo stesso modo, svela la tua stanchezza ai superiori che si prendono cura del tuo benessere, evita completamente e allontana chiunque possa opporsi alle tue convinzioni e cerca di spingere alcune ore obbligatorie di refactoring nella pianificazione di nuovi progetti / funzioni.

Se sei appassionato di ciò che fai e ti preoccupi della tua azienda, sarebbe uno sforzo lodevole dalla tua parte. Se non è apprezzato, rispetta te stesso e salvalo prima di trasformarti in un programmatore vuoto.

Se dovessi introdurre una pratica per migliorare le cose in questo tipo di contesto, si tratterebbe di revisioni del codice. Le revisioni del codice sono

• generalmente accettato intuitivamente dagli sviluppatori come fattore per un codice migliore, meno bug, ecc.
• collaborativo e democratico
• non troppo dispendioso in termini di tempo se li si impone correttamente nel timebox
• un buon posto per fare refactoring se non si ha il tempo di farlo durante lo sviluppo "normale"
• un cavallo di Troia abbastanza efficace per introdurre gradualmente tutti i tipi di migliori pratiche in termini di progettazione del codice, test di unità ...

Non è necessario eseguire revisioni del codice in modo sistematico, solo quando si esegue inizialmente il commit di porzioni di codice complesse / di grandi dimensioni.

Naturalmente, se ritieni di aver bisogno dell'approvazione ufficiale prima di introdurre le revisioni del codice, potresti dover prima convincere il tuo capo che è probabile che la base di codice collassi se le cose vengono lasciate così come sono.

Ecco cosa faccio in tali situazioni (nei 15 anni della mia carriera come sviluppatore mi sono imbattuto in tale codice quasi ogni giorno)

1. Dare l'esempio: mi assicuro di ricodificare il codice che tocco. Elimina spietatamente il vecchio codice commentato e grandi paragrafi di commenti.
2. Chiedi di ripetere il factoring ogni volta che mi viene chiesto di rivedere una modifica del codice, senza la quale non approvo la revisione del codice.
3. Lentamente le persone vedono il cambiamento, quando il codice diventa più snello, più leggibile e quindi meno buggy. Ci vuole tempo ma lentamente l'intera squadra apprezza e adotta la pratica.

La direzione non dedica mai tempo al re-factoring del codice (non hanno mai abbastanza risorse!), Quindi farlo lentamente e costantemente è un approccio giusto.

Chiedi al management di fare delle ricerche sul "debito tecnico". Riferiscili anche alla "teoria delle finestre rotte", entrambi questi effetti hanno un impatto diretto su efficienza, qualità e morale.

"Un cantiere pulito è un cantiere sicuro e produttivo", e ogni contributo a un pasticcio aggrava il pasticcio in modo esponenziale, non lineare.

Se la situazione non viene affrontata, alla fine attraverserai un punto di non ritorno, in cui diventa economicamente impossibile, trattandolo in modo incrementale prima che ciò accada, i benefici rimbalzeranno, dandoti più carburante per affrontare il problema mentre procedi.

Sembra che i tuoi problemi siano più generali.
Il problema del refactoring è sia un sintomo che un potenziale sollievo da parte del problema.

Il responsabile del software e il team dedicano il tempo del team

Dalla mia esperienza, penso che potresti riscontrare un problema che io chiamo "tutti sono un software manager". I responsabili di prodotto, i project manager e talvolta gli ingegneri di sistema e i tester possono essere famosi per aver cercato di gestire micro sviluppatori che probabilmente hanno già un software manager esperto. Potresti anche avere alcuni membri nella tua squadra che credono che il loro ruolo sia quello di gestirli.

Se sei il gestore del software, prendi incarichi per il refactoring che desideri o, meglio ancora, chiedi al tuo team di proporre il refactoring per la tua approvazione. Per non micromanage, potresti avere delle linee guida su età / autore / dimensione / contesto del codice da refactoring che possono essere liberamente refactored rispetto alla necessità di approvazione. Se un membro del tuo team desidera riformattare in modo massiccio quattro grandi classi di codice vecchio complesso che non ha scritto che non fanno parte della sua caratteristica, la sua diversione di due settimane è il tuo problema, quindi devi avere la possibilità di dire di no.

Puoi sgattaiolare in giro, ma penso che sia meglio costruire attentamente le tue stime con il tempo per analisi, progettazione, codifica, più forme di test (almeno unità e integrazione), refactoring e rischio come giudicato storicamente e dalla mancanza di esperienza o chiarezza associate all'attività. Se sei stato troppo aperto sul funzionamento del tuo team (o hai membri del tuo team che lo sono), potrebbe essere saggio restringere i canali di comunicazione in modo che passino attraverso di te e discutano risorse e risultati, non metodi.

Le prime scelte di progetto creano un circolo vizioso per il refactoring

La manutenzione del software è difficile. È doppiamente difficile se altri nell'organizzazione stanno facendo delle scelte a tue spese. Questo è sbagliato, ma non è nuovo. È stato affrontato da Barry Boehm, uno dei nostri grandi scrittori di software che propone un modello di gestione che descrive come Teoria W.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

Spesso gli sviluppatori di software sono costretti a produrre secondo l'approccio di gestione di Theory-X che afferma che i lavoratori sono fondamentalmente pigri e non si esibiranno a meno che non vengano messi alla prova. Boehm riassume e contrappone il suo modello proposto come segue:

"Piuttosto che caratterizzare un manager come un autocrate (Teoria X), un allenatore (Teoria Y) o un facilitatore (Teoria Z), la Teoria W caratterizza il ruolo principale di un manager come negoziatore tra i suoi vari collegi elettorali e un pacchetto di soluzioni di progetto con condizioni di vittoria per tutte le parti. Oltre a ciò, il manager è anche un goal-setter, un monitor dei progressi verso gli obiettivi e un attivista nel cercare quotidianamente i conflitti di progetto di vittoria o sconfitta, affrontandoli, e trasformandoli in situazioni vantaggiose per tutti ".

Rapido e sporco è spesso solo sporco

Boehm continua sottolineando il motivo per cui le cose sono così infelici per gli sviluppatori del team di manutenzione.

"La creazione di un prodotto rapido e sciatto può essere una" vittoria "a basso costo e di breve durata per lo sviluppatore e il cliente del software, ma sarà una" perdita "per l'utente e il manutentore." Nel modello di Boehm, il cliente è più un amministratore del contratto che un utente finale. Nella maggior parte delle aziende, pensa al product manager come a un surrogato del cliente, o forse alla persona che acquista il prodotto per il suo elenco di funzionalità.

La mia soluzione sarebbe quella di non rilasciare il team di sviluppo originale (o almeno il lead originale) fino a quando il codice non verrà modificato per soddisfare almeno gli standard di codifica.

Per il cliente, penso che sia ragionevole contare il product manager come surrogato del cliente, e il gruppo di persone premiate per la consegna di qualcosa di veloce e sporco può certamente essere ampliato, quindi c'è un grande collegio elettorale per fare le cose nel modo sbagliato.

Il refactoring non è negoziabile

Per favore, non tirarti indietro dal tuo ruolo di software manager. Dovresti avere l'autorità e la discrezione per utilizzare il tempo del tuo team nel processo e miglioramenti del prodotto. In quel ruolo, potresti dover negoziare le tue scelte per rendere la tua squadra più professionale. Tuttavia, per quanto riguarda il processo, non negoziare con il marketing, perché nella mia esperienza, questo è un gioco perdente. Negoziare con la direzione tecnica. Ti mostra che hai visione. La creazione di un team di software professionale è un'estensione del loro ruolo ed è molto più probabile che venga vista come una vittoria.

Potresti sempre aspettare. Alla fine, il team mancherà abbastanza scadenze e produrrà software abbastanza buggy, che la direzione alzerà le mani e dirà che per Dio qualcosa sarebbe cambiato meglio!

Ok, questa è una proposta rischiosa. Ma in realtà è quello che è successo nel nostro negozio diversi anni fa (parte della difficoltà era nel comunicare con il management sulle scadenze, ma questa è un'altra storia), ed è gran parte del motivo per cui ora abbiamo decine di migliaia di test automatici, proprietà del codice condiviso, la libertà di refactoring, la volontà di eliminare il codice morto e le versioni di alta qualità che abbiamo mai avuto.

Forse più sorprendentemente, nessuno ha perso il lavoro nel processo - qualcosa che merito al nostro capo che viene a fare pipistrelli per noi, e un consulente che ha sostenuto il caso del refactoring e della continua integrazione per nostro conto. Sembra sempre più convincente quando lo dice qualcuno dall'esterno.

Penso che la risposta a come trovare il tempo dipenda dal motivo per cui si desidera refactificare il codice.

Se funziona, non è necessario un refactor speciale e puoi farlo quando tocchi quella parte di codice. Pertanto non hai bisogno di tempo speciale per quello.

Se rallenta lo sviluppo del tuo team, devi parlarne con il leader del team e creare un compito speciale per il refactoring e che avrai tempo.

Lo stesso vale per la velocità di esecuzione e altri casi, se refactor può migliorare qualcosa e non solo "guardare bene il codice" o la tua opinione su come dovrebbe apparire il codice e fornire vantaggi reali, creare attività o parlare con qualcuno che ne è responsabile.

Ho riso un po 'del modo in cui hai descritto le cose in quanto sembra abbastanza simile alla base di codice su cui lavoro, quindi penso che le nostre situazioni siano abbastanza simili. Fortunatamente, nella mia situazione ho un manager lungimirante che ha deciso che il modo migliore per migliorare la base di codice è attraverso la modularizzazione usando un moderno framework di sviluppo web piuttosto che semplicemente rifattorizzare l'intera base di codice. In questo modo i punti problematici dell'applicazione principale possono essere riscritti come moduli separati e quindi essere integrati nell'app principale (ma essere sostanzialmente indipendenti). Questo potrebbe essere un approccio che vuoi mettere in evidenza poiché non richiederebbe il refactoring dell'intera base di codice (presumibilmente grande?) Con cui stai lavorando.

Certo, potrei essere un po 'fuori da quello che stai dicendo perché forse la tua base di codice non è così male come quella con cui lavoro, in quel caso direi perché non fare piccole ottimizzazioni mentre vai avanti? Gli sviluppatori del mio team non hanno problemi a rimuovere commenti stupidi o obsoleti e cose del genere e non penso che sia qualcosa che dovrebbe richiedere input da parte della dirigenza poiché di solito agli sviluppatori viene dato un po 'di potere per ottimizzare le cose secondo necessità.

Se la base di codice è davvero fragile, allora devi stare attento e questo potrebbe essere il motivo per cui potrebbero non voler perseguire un grande refactoring in quanto ciò potrebbe finire per trasformarsi in un progetto lungo mesi e probabilmente richiederebbe la ramificazione di un progetto e mettere gli sviluppatori su quello progettare e sottrarsi ad altre attività di sviluppo, come correzioni immediate di bug che potrebbero far perdere loro clienti, ecc

Tutto considerato, per quanto le altre persone dicano che dovresti smettere, ecc., Penso che dipenda da come la direzione vede le cose, se comprendono la situazione e comprendono perché alcune cose potrebbero richiedere più tempo di quanto dovrebbero in modo ottimale, allora le cose potrebbero andare bene per quanto riguarda l'ambiente di lavoro, ma se sono costantemente coinvolti in un arretrato di lavoro, questo potrebbe diventare dannoso nel tempo. Sono fortunato ad avere un management che fondamentalmente si rende conto che l'applicazione è un pezzo di merda, ma ha molti clienti e porta soldi, quindi è ancora prezioso e vale la pena fare correzioni di bug, anche se solo per un breve periodo .

Il tuo problema principale è che i codici non ottengono visibilità sufficiente.

Suggerisco di utilizzare uno strumento di integrazione continua come Jenkins e uno strumento di analisi del codice statico integrato ad esso che misura la complessità ciclomatica, gli standard di denominazione, la lunghezza del codice, ecc.

Quando un programmatore commette una modifica, Jenkins eseguirà i test delle unità, eseguirà lo strumento di analisi del codice statico su di esso e genererà un report Web che tutti possono vedere, con lo stato del colore simile a un semaforo.

Quando la qualità del codice è visibile a tutti (in particolare il team lider e il boss) e il controllo della versione e i test unitari sono lì per avere le spalle ... le persone si sentono incoraggiate a refactoring.

Il codice è arrivato così lentamente su molte piccole modifiche. Dovrà essere risolto anche in questo modo.

Puoi farlo mentre procedi, prima di tutto: aumentare tutte le stime del 10% per consentire il miglioramento del codice e la manutenzione a lungo termine. Se qualcuno si lamenta, chiedigli se è meglio controllare l'olio nel motore di un'auto ogni settimana o aspettare fino a quando il motore si blocca completamente.

Avere una riunione e determinare standard di codifica coerenti.

Introduci regole di base da usare mentre procedi:

Ogni volta che un nuovo codice viene introdotto in una classe, i test automatici devono essere scritti per dimostrare che la classe funziona (non solo il nuovo codice).

Ogni volta che viene corretto un bug, è necessario scrivere test automatici per provare che la classe funziona (non solo il codice fisso).

Ogni volta che un programmatore modifica un file, deve correggere tutti gli avvisi del compilatore in quel file e aggiornare il codice in modo che soddisfi i nuovi standard di codifica.

Dopo un po 'il codice più usato sarà aggiornato e sarà coperto da test automatizzati. Il codice precedente verrà aggiornato quando viene modificato, se non viene mai modificato, non è necessario preoccuparsene.

L'importante è integrare questi habbit nelle attività di codifica standard in modo che nessuno di loro si prenda molto tempo lontano dal lavoro "reale", ma tutti offrono vantaggi reali. Non tentare di realizzare un progetto con il refactoring del vecchio codice, è un dolore orribile, noioso, fiddly che sembrerà molto tempo sprecato per le non tecniche!

Il modo per ottenere le risorse (tempo) necessarie è concentrarsi sull'allineamento di capacità e desiderio. Il tuo capo è guidato da obiettivi (in genere profitti o tempi di consegna per le nuove funzionalità) e vede il refactoring come ingegneri che sprecano tempo e consumano tali obiettivi. Devi trovare un modo per convincerlo che gli obiettivi saranno raggiunti e superati se passi il refactoring.

Quindi il primo passo è scoprire quale dolore prova il tuo capo. Identifica quali sono i suoi maggiori problemi. Quindi scopri come ciò che vuoi fare si allinea con la risoluzione dei suoi problemi e presenta un valido business case per farlo. Usa i tuoi sistemi di tracciamento dei difetti e di pianificazione del progetto (superamento dei tempi) per fornire prove di dove si trovano i problemi. Hai bisogno di fatti, non di sentimenti. Senza metriche (conta dei bug / modulo, costo per risolverli), il refactoring è solo un programmatore che gioca a spese di qualcuno. Il tuo capo ti fornirà le risorse necessarie solo se puoi mostrare un valido caso commerciale per farlo.

Il codice di merda è il più delle volte troppo costoso da risolvere. Senza test di regressione automatizzati, il costo del test del codice refactored è estremamente elevato.

La maggior parte delle volte ho visto codici errati che necessitavano davvero di refactoring, c'era un gran numero di caratteristiche non documentate e complessità nei requisiti che non possono essere comprese dall'inizio. Non è un'impresa minore e la mia esperienza è un ordine di grandezza più difficile per stimare il costo di un lavoro di refactoring piuttosto che aggiungere una nuova funzionalità.

Mi asterrei dal proseguire e farlo dietro i tuoi capi (se non è stato rotto e tu lo hai rotto, come sembra) - correggi il codice che deve comunque cambiare, ma se non è rotto, non lo aggiusto.

Stranamente nessuno menziona questo:

Per rendere le cose una priorità, rendile semplici: ottieni un buon strumento di refactoring.

Esistono eccellenti strumenti di refactoring (almeno per .NET afaik). Oh, e non dimenticare di scrivere in anticipo i test unitari (come altri hanno già sottolineato).

In bocca al lupo!