Lo rifatteresti e, in tal caso, addebiteresti al tuo cliente?

Tu "possiedi" ciò che cambi in relazione alla responsabilità di correggere difetti e comportamenti indesiderati .... forse puoi uscirne a volte, ma il cliente dirà "Hai cambiato, è rotto, lo aggiusti. Troppi di questi e non sarà un cliente felice.

Se rifattori e lo rompi, è tuo.

Se hai un refactoring, ed è stato rotto prima, ed è in seguito, è tuo.

Se rifattori e correggi un "difetto", ma cambia il comportamento, quando viene utilizzato il comportamento "rotto", è tuo.

A meno che tu non abbia grandi test unitari, il refactoring cambierà il comportamento - e ora hai la responsabilità di ripararlo se è rotto.

Fino a te se sei pronto a correre questo rischio gratuitamente. Io non. Quindi devi discuterne con il tuo cliente e chiedere loro quanto sono disposti a pagarlo. Assicurati di comprendere il rischio di rompere qualcosa e di avere un accordo su come è pagato.

Di proposito non ho affrontato la questione dei tempi / costi diretti per il refactoring, come già commentato, la maggior parte dei clienti dirà "Che valore ottengo per pagarti tanti soldi", questa è la parte facile della discussione.

Potrei fare un po 'di pulizia per mantenere il mio equilibrio mentale, ma non includerei la mia pulizia nel changeset finale che sottopongo a test e invio al client. Le altre risposte sono giuste su questo punto. Non vuoi rischiare di rompere qualcosa perché hai fatto qualcosa che non è stato richiesto.

Se ritieni che il codice nella sua forma attuale sia difficile da modificare e mantenere, informa il cliente il prima possibile. Se porto la mia macchina da un meccanico per far cambiare l'olio, non mi aspetto che faccia finta di non vedere che le mie linee dei freni sono danneggiate solo perché non è quello che l'ho assunto per riparare. Mi aspetto che suggerisca riparazioni e manutenzione ragionevoli.

Potrebbe essere molto utile per il tuo cliente sapere che il codice è cattivo. Possono decidere che non vogliono più lavorare con l'autore. Potrebbero decidere che non vale la pena ripararli. Oppure potrebbero averlo aggiustato. Ti stanno pagando per la tua esperienza. Forniscilo!

Il codice trucchi per la refactoring è sempre pericoloso. Il rischio di mancare qualche supposizione presente nell'originale è semplicemente troppo alto, e potresti finire per fare più male che bene, per quanto ben intenzionato potresti essere all'inizio.

Se non hai bisogno di farlo come parte di questo lavoro, allora non toccarlo con un palo da 10 piedi. Per quanto possa sembrare terribile, una volta che hai consegnato il requisito puoi andartene quando hai finito e il problema non è più tuo.

D'altra parte, se hai bisogno di farlo, allora forse è il momento di rinegoziare i termini con il cliente. Dopo tutto, sei stato scaricato con un sacco di merda che non era nel contratto originale, quindi non è realistico aspettarsi che tu rispetti i termini originariamente concordati date le circostanze (che non ci si poteva ragionevolmente aspettare fossero consapevole di quando hai preso il lavoro). Il cliente potrebbe anche essere in grado di ottenere lo sviluppatore originale e almeno chiarire le cose un po 'meglio di quanto tu possa capire da solo, quindi è nel tuo stesso interesse.

Se è qualcosa di facile (nella mia definizione impiega meno di un'ora), allora lo farei per preservare la mia sanità mentale.

Tuttavia, qualsiasi cosa più grande di quella ha bisogno di un po 'di pensiero.

Quanto tempo ci vorrà per completare il tuo lavoro (quello per cui sei stato pagato) senza refactoring? Chiamiamo questo A.

Quanto tempo ci vorrà per finire il tuo lavoro dopo refactoring, più la quantità di tempo del test refactoring e assicurati di non rompere nulla). Chiamiamo questo B.

Lo farei solo se B è significativamente inferiore a A. Altrimenti chiederei un risarcimento al cliente.