Come dimostrare vantaggi per il business nel software refactoring? [duplicare]

Anche se non ho avuto la possibilità di metterlo in pratica, il Consorzio per la qualità del software IT ha recentemente pubblicato i suoi Misura di debito tecnico automatizzata standard come mezzo per misurare e calcolare un problema strettamente correlato al refactoring (o piuttosto alla necessità di farlo).

Questa è la migliore occasione per far capire ai manager la necessità di eseguire periodicamente il refactoring del codice legacy. Naturalmente, la maggior parte degli sviluppatori vedrà i vantaggi con metriche molto meno elaborate.

I mean, usually they don't create tasks to refactor or create tests, cause it will be a waste of money, they say: "the software is already working".

Se sta già funzionando, perché impiegano te e i tuoi compagni di squadra per apportare modifiche? Chiaramente potrebbe "funzionare", ma vogliono che funzioni meglio, per consentire loro di guadagnare di più. Altrimenti stanno solo sprecando denaro con l'impiego di te.

Quindi, dato che vogliono apportare modifiche, dovrebbero rendere tali modifiche il più efficienti possibile. I cambiamenti rapidi e sporchi sono inefficienti in quanto accumulano problemi per dopo. Ogni volta che apporti una modifica, rischi tutti l'intera applicazione di crollare intorno a te, oppure ogni modifica richiederà più tempo e più tempo.

Se sono nel business di fare più soldi per vendere l'azienda a breve termine, stai perdendo tempo e denaro cercando di scrivere un buon codice; che va contro gli obiettivi dell'azienda. Se ci sono per il lungo periodo, però, investire tempo nel refactoring pagherà dividendi a lungo termine in quanto non sarà mai più costoso apportare modifiche.

Quindi le tue scelte dipendono dal loro piano aziendale. Chiedete loro se il loro obiettivo è quello di fare un sacco di soldi a breve termine solo prima di vendere. Se è così, vai con esso o cambia lavoro. In caso contrario, spesso la cosa migliore da fare è eseguire correttamente il lavoro senza dirlo direttamente: aumentare le stime per attività per includere il tempo di refactoring. Se vuoi farlo correttamente, cita un prezzo per farlo correttamente.

Sono confuso dall'affermazione che "il costo per il refactoring di un software diventa oneroso" il costo del refactoring è piuttosto lineare. È il costo di aggiungere nuove funzionalità in un caos che cresce in modo esponenziale. Questo è quello su cui ti devi concentrare. Come inizio, puoi mettere insieme le statistiche sulle prestazioni del team di sviluppo nel tempo? La gestione potrebbe essere in grado di darti queste informazioni. Prova a chiederlo.

Spesso la gestione può vedere questo accadere ma non capisce perché. Allo stesso tempo, il team di sviluppo inizia a parlare di cose come test e refactoring. È importante capire che dal punto di vista aziendale, i test e il refactoring non forniscono alcun valore aggiunto al prodotto. Non è una funzione che aggiunge o trattiene introiti. Non possono fare pubblicità: "ora con test delle unità!" Quindi dal loro punto di vista, la produttività è in ritardo e la vostra risposta è di fare cose più improduttive. Non sarà il benvenuto, ma è necessario.

Il punto su cui devi essere chiaro è che queste sono le cose necessarie per tenere sotto controllo i costi. Prova l'analogia: se non cambi mai l'olio in un camion, alla fine fallirà e i costi per ripararlo supereranno di gran lunga i costi di una corretta manutenzione. Agli operatori delle ferrovie non piace pagare per la manutenzione della pista (è puro costo!) Ma se non lo fanno non hanno un business. Il Pony Express aveva un cavallo fresco ogni 16 chilometri per i loro cavalieri. Non è perché a loro piace possedere e prendersi cura di molti cavalli e mantenere così tante stazioni, era così che potevano essere veramente veloci.

Devi far capire loro che quello che stanno facendo è come cercare di eseguire un pony express ma fustigare un singolo cavallo per tutto il percorso. Diventerà più lento e lento e alla fine smetterà completamente di muoversi. Una volta che riesci a capire l'idea, devi spiegare che il cavallo è quasi morto. Se non investono del tempo nella riabilitazione, non saranno mai in grado di tenere il passo con la loro concorrenza. Non stai chiedendo il tempo per riordinare. Stai chiedendo un investimento nel tempo in modo che tu possa fare di nuovo le cose velocemente.

Se hai bisogno di un esempio storico per fornirglielo, non devi cercare oltre Microsoft. Ricordo di aver letto un'intervista con uno dei principali responsabili dello sviluppo su come tutto ciò che contava fosse aggiungere nuove funzionalità e ripulire il vecchio codice non importava. Era vanitoso, erano molto più intelligenti dei loro concorrenti ignorando il cumulo di letame su cui si stavano sviluppando (ho cercato di trovarlo ma è stato tanto tempo fa e non ricordo il nome. era Allchin ma non sono positivo. Qualche aiuto?) IIRC, questo era proprio al momento di Longhorn che sarebbe diventato Vista. Non è difficile capire come queste scelte portino gli Stati membri a perdere il dominio sui suoi concorrenti.

Il refactoring è parte integrante dello sviluppo del software ... beh ... almeno è diventato così per me.

Pertanto, includo sempre il tempo necessario per il refactoring delle parti che necessitano di refactoring per implementare la funzionalità o risolvere il problema in modo pulito. Con cleanly intendo che cerco di lasciare il codice base in una forma migliore rispetto a prima di iniziare.

Ora questo non significa che scriverò di nuovo l'intera cosa, rifatterò solo le parti necessarie per ottenere il lavoro da fare.

Purtroppo per alcuni codici base questo semplicemente non è possibile. La loro struttura complessiva e l'architettura sono state trascurate per così tanto tempo che sono effettivamente "troppo lontane". In genere tali sistemi sono estremamente costosi da mantenere o introdurre nuove funzionalità, in gran parte a causa del debito tecnico che è stato sostenuto durante la sua vita.

Ora capisco i capi qui. Per loro la linea di fondo è dollaro e centesimi. Devi quindi parlare quella stessa lingua se vuoi giustificare alcuni importanti refattori. Come già sapete, la definizione stessa di un refactoring è un'impresa a somma zero per quanto riguarda la funzionalità del software stesso. Dove puoi segnare alcuni punti, tuttavia, è se riesci a convincere (te stesso prima, poi loro) con argomenti oggettivi misurabili che il refattore avrà un impatto su altre metriche come tempo di implementazione, testabilità (quindi stabilità, sebbene questo possa essere più difficile da misurare ) e nel costo complessivo che questo software comporta per la manutenzione.

Se il tuo refactoring ridurrebbe il tempo di intervento dello sviluppatore di (diciamo) a metà mentre allo stesso tempo fornirà migliori garanzie che la stabilità complessiva migliorerà, allora potresti avere un punto con loro. La prossima è affermare quanto tempo impiegherà questo refactoring e misurarlo rispetto ai guadagni ... ottenere un equilibrio positivo ... provaci ... è ancora negativo, beh, o prosegui ancora fino a trovare un saldo positivo o fino a quando non ti rendi conto che il costo di renderlo buono è così grande che non ne vale la pena.