Come posso fare del refactoring una priorità per la mia squadra?

"È meglio chiedere perdono che il permesso" è vero.

Perché preoccuparsene? Basta refactoring le parti più orribili.

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

Se non lo fai, allora il passaggio 1 deve definire in modo positivo e non ambiguo il più problematico, complesso, errore-insito, codice di errore infetto da bug.

Identifica il numero di trouble ticket, ore di debug e altri costi molto specifici e molto misurabili .

Quindi aggiusta qualcosa sull'elenco dei costi elevati dei problemi.

Quando devi chiedere perdono, puoi indicare riduzioni dei costi.

Nel caso non lo sapessi, il refactoring richiede unit test per dimostrare che i comportamenti precedenti e successivi coincidono. Idealmente, questo dovrebbe essere un test automatico codificato, ad esempio, un test unitario.

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

Itera.

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 si è inventato per aver apportato dei piccoli miglioramenti al codice "mentre erano lì dentro."

Prenderò un punto di vista forse eccessivamente cinico.

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

Direi che se tali pratiche di ingegneria sono diventate la cultura della tua azienda, potresti dover combattere a un livello più alto. Non stai davvero combattendo per il refactoring, stai combattendo per l'eccellenza ingegneristica, e questo è il tipo di cambiamento che emerge solo sulla gestione quando li schiaffeggia in faccia. In questo scenario, probabilmente cercheranno uno zar delle migliori pratiche e tutte le tue grandi idee saranno comunque incluse.

Considera l'opportunità di unirti a un'altra società in cui prendono più sul serio le pratiche ingegneristiche.

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

Andrei oltre: a mio parere una base di codice scadente non è quasi mai direttamente colpa del management. La direzione non ha scritto quel codice, gli sviluppatori lo hanno fatto (ci sono alcune eccezioni nella mia azienda in cui alcuni dei nostri attuali dirigenti hanno effettivamente scritto il codice iniziale). Quindi il problema della cultura risiede negli 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 tempo di refactoring?", Mi compiaccio e rispondo "dovresti essere sempre in refactoring!". L'unico modo in cui credo tu possa mantenere sano un code base è triplice:

1. aggiungi sempre un codice sano.
2. Correggi sempre il codice non salutare non appena lo vedi.
3. Se per ragioni di scadenza non puoi fare 1 o 2, avere sempre un elenco di problemi "correggi subito dopo la scadenza" e non accettare alcuna scusa per non aver funzionato in quella lista dopo la scadenza.

Invariabilmente la prossima osservazione da parte degli sviluppatori è "ma come possiamo ottenere il tempo per farlo - non abbiamo il tempo ora?". L'unica risposta corretta (di nuovo IMHO) è "non hai il tempo di NON farlo". Se non si mantiene sano il codice base, i tempi di consegna si allungano e si allungano, le pianificazioni diventano più imprevedibili, i bug diventano più cattivi e il valore si abbassa.

Il più grande cambiamento di atteggiamento che devi apportare al team di sviluppo è che la "qualità" non è qualcosa che fai in un momento specifico nel tempo ("quando abbiamo tempo di refactoring") - è qualcosa che devi fare TUTTI il tempo.

Infine, una storia di avvertimento. Se premuto, negherò che sia mai successo. In una società per cui lavoravo c'era un'applicazione di lunga data con un codice numerico ampio e legacy che aveva origine più di 10 anni fa. Molti sviluppatori, incluso me, credevano che questa base di codice legacy fosse scadente o per lo meno obsoleta, non all'avanguardia. Così abbiamo fatto un grande successo per un grande progetto di refactoring, e abbiamo iniziato il progetto di riscrittura dopo il quale credevamo che tutto sarebbe stato migliore.
Abbiamo lavorato a lungo e duramente implementando quasi tutto in un modo nuovo e moderno, utilizzando 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 il nuovo e migliorato codice base.
Come previsto, la nuova versione ha avuto alcuni problemi iniziali, a causa delle nuove librerie che non avevamo ancora familiarità e alcune interazioni nel nostro codice che non avevamo previsto. Tuttavia, siamo finalmente riusciti a ottenere il rilascio dello stesso standard delle versioni precedenti e fuori dalla porta. Abbiamo tirato un sospiro di sollievo al nostro "successo". Poi un sottogruppo di sviluppatori è tornato alla gestione, chiedendo un nuovo progetto di refactoring perché il nostro nuovo codice non era esattamente il proiettile d'argento che si aspettavano che fosse, e hanno visto alcune opportunità di riscrivere completamente alcune cose ...

Morale della trama: spesso le cose non sono così spezzate come sembrano, e "ricominciare" di solito significa che scambierai una serie conosciuta di problemi con una serie di problemi sconosciuti almeno altrettanto pelosi. Refactor una parte alla volta!

Qualcuno una volta mi ha detto che quando vado a un colloquio, non devo dimenticare che sto anche intervistando la compagnia. È un posto in cui voglio lavorare? Fanno recensioni di codice? Hanno test di integrazione automatizzati? Test unitari? Cosa pensano della programmazione della coppia? Personalmente troverei un altro lavoro, e non dimenticarti di fare qualche domanda anche questa volta.

Trova un'altra società, onestamente. Tali miglioramenti al processo di sviluppo richiedono enormi salti culturali che impiegheranno molto tempo prima che tutti si mettano sulla stessa pagina e da allora non ti preoccuperai tanto.

Se hai la sensazione che tu abbia ancora un po 'di lotta in te e non sei ancora finito, allora fai una spinta finale. Cerca di ottenere il massimo sostegno da membri del team che la pensano allo stesso modo, svela la tua stanchezza ai superiori che si preoccupano del tuo benessere, bypass totale e allontana chiunque possa opporsi alle tue convinzioni e cerca di spingere in alcune ore obbligatorie di refactoring nella pianificazione di nuovi progetti / caratteristiche.

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

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

• generalmente accettato intuitivamente dagli sviluppatori come fattore per un codice migliore, meno bug, ecc.
• collaborativo e democratico
• non richiede troppo tempo se li inserisci correttamente
• un buon posto dove fare refactoring se non hai tempo per farlo durante lo sviluppo "normale"
• un cavallo di Troia piuttosto efficace per introdurre gradualmente tutti i tipi di best practice in termini di progettazione del codice, test unitario ...

Non è necessario eseguire revisioni sistematiche del codice, solo quando si impiegano inizialmente porzioni di codice grandi / complesse.

Ovviamente, se ritieni di aver bisogno di approvazione ufficiale prima di introdurre le recensioni del codice, potresti dover convincere il tuo capo prima che il codice base possa crollare se le cose vengono lasciate così come sono.

Ecco cosa faccio in queste situazioni (nei 15 anni della mia carriera come sviluppatore ho trovato questo codice quasi ogni giorno)

1. Diamo il buon esempio - Mi assicuro di ridimensionare il codice che tocco. Elimina spietatamente il vecchio codice commentato e i grandi paragrafi di commenti.
2. Chiedi di ri-factoring ogni volta che mi viene chiesto di rivedere un cambio di codice, senza il quale non approvo la revisione del codice.
3. Lentamente la gente vede il cambiamento, quando il codice diventa più snello, più leggibile e quindi meno buggato. Ci vuole tempo, ma lentamente tutto il team apprezza e adotta la pratica.

La gestione non mette mai da parte il tempo per il codice di ri-factoring (non hanno mai abbastanza risorse!), quindi farlo lentamente e costantemente è un approccio corretto.

Avere la direzione fare qualche ricerca sul "debito tecnico". Riferiscili anche alla "Broken Window Theory", entrambi questi effetti hanno un impatto diretto su efficienza, qualità e morale.

"Un sito di lavoro pulito è un cantiere sicuro e produttivo", e ogni contributo a un pasticcio complica il caos in modo esponenziale, non lineare.

Se la situazione non viene affrontata, alla fine si attraverserà un punto di non ritorno, dove diventa economicamente irrealizzabile, affrontandolo in modo incrementale prima che ciò accada, i benefici si ripresero, dandovi più carburante per affrontare il problema come vai.

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 software e il team assegnano il tempo del team

Dalla mia esperienza, penso che potresti incontrare un problema che chiamo, "tutti sono gestori di software". I product manager, i project manager e talvolta gli ingegneri di sistema e i tester possono essere noti per aver tentato di gestire micro-sviluppatori che probabilmente hanno già un software manager esperto. Potresti anche avere alcuni membri della tua squadra che credono che il loro ruolo sia da gestire.

Se sei il gestore software, effettua incarichi per il refactoring che desideri, o, meglio ancora, chiedi al tuo team di presentarti il refactoring per la tua approvazione. Per non eseguire il microgestione, potresti avere delle linee guida sull'età / autore / dimensione / contesto del codice da sottoporre a refactoring che possono essere liberamente rifatte- rite o richiedere l'approvazione. Se un membro della tua squadra vuole refactoring massiccia di quattro grandi classi di vecchio codice complesso che non ha scritto che non fanno parte del suo film, la sua deviazione di due settimane è il tuo problema, quindi hai bisogno di una possibilità per dire no.

Puoi aggirarti furtivamente, ma penso che sia meglio semplicemente costruire le tue stime attentamente con il tempo per analisi, progettazione, codifica, più forme di test (almeno unità e integrazione), refactoring e rischio come giudicato storicamente e la mancanza di esperienza o chiarezza associata al compito. Se sei stato troppo aperto sul funzionamento della tua squadra (o se hai membri della tua squadra che lo sono), potrebbe essere saggio limitare i canali di comunicazione in modo che vi passino attraverso e discutano di risorse e risultati, non di metodi.

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

La manutenzione del software è difficile. È doppiamente difficile se gli altri membri dell'organizzazione fanno delle scelte a proprie spese. Questo è sbagliato, ma non è nuovo. È stato indirizzato da Barry Boehm, uno dei nostri grandi scrittori di software che propone un modello di gestione che descrive come Theory W.

link

Spesso gli sviluppatori di software sono martellati per produrre secondo l'approccio di gestione Theory-X che dice che i lavoratori sono fondamentalmente pigri e non si esibiranno se non saranno sottoposti alla sottomissione. 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), Theory W caratterizza il ruolo primario di un manager come negoziatore tra i suoi vari collegi elettorali, e un packager di soluzioni di progetto con condizioni di vittoria per tutte le parti. Oltre a questo, il manager è anche un obiettivo, un monitor dei progressi verso gli obiettivi, e un attivista nella ricerca di conflitti di vittoria giorno-per-perdere o perdere-perdere, confrontandoli e trasformandoli in situazioni vantaggiose per tutti. "

Veloce e sporco è spesso solo sporca

Boehm continua a sottolineare la ragione per cui le cose sono così misere per gli sviluppatori del team di manutenzione.

"Costruire un prodotto veloce e sciatto può essere una" vittoria "a basso costo, a breve termine, per lo sviluppatore e il cliente del software, ma sarà una" perdita "per l'utente e il manutentore." Si noti che nel modello di Boehm, il cliente è più un amministratore di contratto che un utente finale. Nella maggior parte delle aziende, pensa al product manager come a un surrogato del cliente o 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) finché il codice non verrà refactato per soddisfare almeno gli standard di codifica.

Per i clienti, penso che sia ragionevole considerare il product manager come un surrogato del cliente, e il gruppo di persone premiato per offrire qualcosa di veloce e sporco può certamente essere espanso, quindi c'è una grande comunità di persone che fa le cose nel modo sbagliato .

Il refactoring non è negoziabile

Per favore non tornare indietro dal tuo ruolo di gestore di software. Dovresti avere autorità e discrezione per utilizzare il tempo del tuo team nei processi e nei 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. Negozia con la gestione ingegneristica. Mostra che hai una visione. Costruire un team di software professionale è un'estensione del loro ruolo, ed è molto più probabile che venga visto come una soluzione vincente.

Potresti sempre aspettarlo. Alla fine, il team mancherà di un numero sufficiente di scadenze e produrrà software abbastanza buggy, che la direzione alzerà le mani e dirà che Dio qualcosa ha 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 la gestione sulle scadenze, ma questa è un'altra storia), ed è molto del motivo per cui ora abbiamo decine di migliaia di test automatici, proprietà condivisa del codice, la libertà di refactoring, la volontà di eliminare il codice morto e le versioni di altissima qualità che abbiamo mai avuto.

Forse la cosa più sorprendente è che nessuno ha perso il lavoro nel processo - qualcosa che io attribuisco al nostro capo che si batte per noi, e un consulente che ha sostenuto il caso per il refactoring e l'integrazione continua per nostro conto. Sembra sempre più convincente quando qualcuno lo dice da fuori.

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

Se funziona, non è necessario un refactoring speciale e puoi farlo quando tocchi quella parte di codice. Quindi non hai bisogno di tempo speciale per questo.

Se rallenta lo sviluppo del team, devi parlare con il team leader e creare un'attività speciale per il refactoring e avere tempo.

Lo stesso vale per la velocità di esecuzione e altri casi, se il refattore può migliorare qualcosa e non solo "un buon codice" o la tua opinione su come dovrebbe essere il codice e fornire un vantaggio reale, creare attività o parlare con qualcuno responsabile che.

Ho riso un po 'nel 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 il refactoring dell'intero codebase. In questo modo i fastidiosi spot dell'applicazione principale possono essere riscritti come moduli separati e quindi essere integrati nell'app principale (ma essere essenzialmente indipendenti). Questo può essere un approccio che vuoi far apparire dal momento che non richiede il refactoring dell'intero (presumibilmente grande?) Codice base con cui stai lavorando.

Naturalmente, potrei essere un po 'diverso da quello che stai dicendo, perché forse la tua base di codice non è così male come quella con cui lavoro, in tal caso direi perché non esegui piccole ottimizzazioni mentre vai avanti? Gli sviluppatori del mio team non hanno problemi a rimuovere commenti stupidi o obsoleti e cose di questa natura e non penso che questo debba richiedere un input da parte della direzione, poiché in genere agli sviluppatori viene dato il potere di ottimizzare le cose secondo necessità.

Se la base di codice è veramente fragile, devi stare attento e questo può essere il motivo per cui non vogliono intraprendere importanti refactoring in quanto potrebbero finire per trasformarsi in un progetto lungo mesi e probabilmente richiedere la ramificazione di un progetto e mettere Dev è su quel progetto e prende il via da altre attività di sviluppo, come correzioni di bug immediate che potrebbero farli perdere clienti, ecc.

Tutto considerato, per quanto gli altri dicono che dovresti smettere, penso che dipenda da come la direzione vede le cose, se capiscono la situazione e capiscono perché alcune cose potrebbero richiedere più tempo di quanto dovrebbero, quindi potrebbero va 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 valida e meritevole di correzioni di bug, anche se solo per il breve termine .

Il tuo problema principale è che i codici non ricevono abbastanza visibilità.

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 esegue il commit di una modifica, Jenkins eseguirà i test delle unità, eseguirà lo strumento di analisi del codice statico e genererà un report Web che tutti potranno vedere, con lo stato dei colori simile a una semaforo.

Quando la qualità del codice è visibile a tutti (specialmente al team lider e al boss) e il controllo della versione e le unit test sono lì per avere la schiena ... le persone si sentono incoraggiate a refactoring.

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

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

Avere una riunione e determinare gli standard di codifica coerenti.

Introduci regole di base da utilizzare man mano che 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 risolto un bug, è necessario scrivere test automatici per dimostrare 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ù utilizzato sarà aggiornato e sarà coperto da test automatici. Il codice precedente verrà aggiornato quando viene modificato, se non viene mai modificato, non dovrai mai preoccuparti di questo.

L'importante è costruire questi habbits nelle attività di codifica standard in modo che nessuno di loro impieghi molto tempo lontano dal lavoro "reale", ma tutti forniscono reali vantaggi. Non tentare di realizzare un progetto senza il refactoring del vecchio codice, è un dolore orribile, noioso e poco impegnativo che sembrerà un sacco di tempo sprecato alle non tecniche!

Il modo per ottenere le risorse (tempo) necessarie è concentrarsi sull'allineamento di capacità e desiderio. Il tuo capo è guidato da obiettivi (tipicamente profitti o tempi di consegna per nuove funzionalità), e vede il refactoring come ingegneri che perdono tempo e mangiano quegli obiettivi. Hai bisogno di trovare un modo per convincerlo che gli obiettivi saranno raggiunti e superati se passerai del tempo a fare refactoring.

Quindi il primo passo è scoprire che dolore provi il tuo capo. Identifica quali sono i suoi maggiori problemi. Quindi cerca di capire in che modo ciò che vuoi allineare con la risoluzione dei suoi problemi e presenta un caso aziendale valido per farlo. Utilizzare il monitoraggio dei difetti e i sistemi di pianificazione dei progetti (eccedenze temporali) per fornire evidenza di dove si trovano i problemi. Hai bisogno di fatti, non di sentimenti. Senza metrica (conteggio errori / modulo, costo per risolverli), il refactoring è solo un programmatore che ha un gioco a spese di qualcuno. Il tuo capo ti fornirà le risorse necessarie solo se puoi dimostrare un valido business case per farlo.

Il codice Crap è spesso troppo costoso da risolvere. Senza test di regressione automatizzati, il costo del test del codice refactored è estremamente alto.

La maggior parte delle volte in cui ho visto codice errato in reale necessità di refactoring, c'era un gran numero di caratteristiche non documentate e complessità nei requisiti che non possono essere capiti dall'inizio. Non è un'impresa minore e la mia esperienza è un ordine di grandezza più difficile da stimare il costo di un lavoro di refactoring che aggiungere una nuova funzionalità.

Mi asterrò dall'andare avanti e farlo dietro a te i boss indietro (Se non fosse rotto, e tu lo hai rotto, come va?) - correggi il codice che deve comunque cambiare, ma se non è rotto , non aggiustarlo

Stranamente nessuno lo menziona:

Per rendere le cose una priorità, renderle semplici: ottieni uno strumento di refactoring valido.

Ci sono strumenti di refactoring eccellenti là fuori (almeno per .NET afaik). Oh, e non dimenticare di scrivere preventivamente i test unitari (come già indicato da altri).

Buona fortuna!