Attualmente sto lavorando su un codice meglio descritto come codice C che vive nel corpo C ++. Tuttavia non sono stato in grado di convincere il potere che è quello di ri-fattore sulla base della facilità di manutenzione.
Quale secondo te è l'argomento migliore per il refactoring del codice.
L'unico modo per convincere un'azienda a un refactoring è di mostrare loro che farà risparmiare denaro. Non intendo solo dirglielo, devi essere in grado di dire che salveremo x giorni sul tipo di bug e ci risparmierà z libbre. O in termini di risparmio quando si tratta di aggiungere funzionalità.
È tutto per i soldi.
Modifica: sto assumendo che questo codice sia ora in fase di sviluppo dal vivo o in fase avanzata. Refactoring durante dev è una domanda completamente diversa.
Fallo e basta. Nella mia esperienza, pochissimi progetti garantiscono un ri-factoring del codice come un progetto separato. Se ci sono parti del codice che non avresti mai avuto perché non hanno bisogno di modifiche, allora il valore di refactoring è probabilmente dubbio.
Non dirai al tassista come guidare la sua macchina.
Non devi dire al parrucchiere come tagliarti i capelli.
Non dici a un programmatore come utilizzare il suo codice.
Se ritieni che il tuo codice necessiti di refactoring. Refactor it.
Posso pensare a tre argomenti per il refactoring che ho usato che hanno effettivamente convinto i registi scettici.
Usando argomenti come "il codice è scritto male" e "è davvero difficile capire il codice" in genere non funzionano.
La maggior parte delle ragioni si riferiscono a probabilità che le rendono difficili da contare, soprattutto se la disponibilità a correre rischi è alta. Migliore manutenzione? Se nulla va storto, non dovrai toccarlo. Migliore portabilità? Se non cambiamo mai il sistema in esecuzione, non ne avremo bisogno. Futuro garantito? Chissà se avremo bisogno della funzionalità di questo codice tra qualche anno? Il codice è un vicolo cieco? Chissà se mai costruiremo il codice su quella merda. Problemi di sicurezza? Non crediamo negli hacker malvagi. I programmatori si divertono a fare qualcosa di luminoso e brillante? Non li paghiamo per divertirci. Più facile da gestire? Quindi avremmo bisogno di programmatori meno qualificati, pagandoli meno? Ah, ora hai un punto ...!
L'ultimo argomento era uno scherzo, ma penso che dovrai affrontare la tua richiesta con reali benefici e, a seconda di ciò che è in cima all'agenda dei tuoi capi, avrai bisogno di argomenti diversi. La mia lista qui sopra è forse utile come punto di partenza ...
Scrivere codice è come coltivare un giardino - deve essere potato e affinato mentre cresce spesso o si trasformerà in un brutto pasticcio che nessuno vorrà o anche toccare con paura un ramoscello si romperà e si schianterà contro l'intero cespuglio .
Come per tutti gli esempi sono il modo migliore. Alcuni esempi che puoi dare:
Per dirla semplicemente se è possibile tracciare una linea di causa ed effetto e illustrare con record di bug tracker, e-mail e altre forme di prova che indicano che c'è un problema che dovrebbe motivare il refactoring abbastanza facilmente. "Non ci sarebbero voluti 2 settimane per implementare la funzione X!"
Ci sono strumenti là fuori che possono aiutarti a motivare anche il tuo refactoring. Possono disegnare grafici di dipendenza o mostrare la complessità del codice, la duplicazione, ecc. Se uno strumento riporta migliaia di avvertimenti e la gestione la ignora, allora non c'è speranza per la gestione.
Si concentrano sulle modifiche alla struttura del codice. I piccoli refactoring come le convenzioni sui nomi e le lezioni di base sono cose che considero parte del mio lavoro e non chiedo il permesso di farlo. Se ha un impatto significativo sulla produttività o sulla data di consegna, allora vale la pena chiedere il permesso.
Leggi altre domande sui tag refactoring