Qual è il modo migliore / etico per stimare la pulizia del codice? [duplicare]

Il problema aziendale del debito tecnico

Il problema che vedo qui è più un problema di business con il debito tecnico piuttosto che un problema tecnico. Risponderò alla tua domanda con un'altra pertinente.

• Perché un cliente dovrebbe pagarti per riscrivere il codice che farà lo stesso lavoro di prima, mentre non ottiene alcun vantaggio diretto o vantaggio finanziario?

Difficoltà nel riconoscere il debito tecnico verso i clienti

Cercare di convincere un cliente a riconoscere il debito tecnico è difficile nella migliore delle ipotesi e il più delle volte finisce per diventare un caso di "perché l'hai scritto in quel modo per cominciare se mi costerà più ora?".

Essere consapevoli del debito tecnico e fissare il debito tecnico man mano che si toccano parti del sistema in modo incrementale, come si è fatto, è più o meno il modo in cui consiglierei di fare una riduzione del debito su larga scala.

Per ogni nuovo lavoro, ti consiglio anche di prendere in considerazione le stime di riempimento tenendo in considerazione la correzione incrementale della build. È naturale presumere che quanto più complesso il software diventa il costo più elevato della manutenzione è coinvolto. Il refactoring e la riduzione del debito tecnico sono parte attiva della manutenzione che dovrebbe essere pagata al più presto possibile, tuttavia suddividere i costi di manutenzione in pezzi più piccoli e più appetibili per il cliente.

Che cosa dice Robert "Uncle Bob" Martin riguardo l'etica e l'artigianato del software

Penso che Robert C Martin dia questa stessa raccomandazione sull'affrontare questo argomento nel suo discorso nella Parte IV. Scusa è un orologio lungo ma ne vale la pena.

• link

Modifica

Le metriche per il calcolo del debito tecnico sono pressoché le stesse che per la stima del tempo di esecuzione del lavoro retribuito. Il trucco sta nell'individuare i pezzi che danno più dolore, e a colpirli gradualmente. Refactoring sempre in modo che funzionino sempre, anche se il rallentamento diventa più piacevole con cui lavorare e più facile da mantenere.

Un esempio del mondo reale

Ho un arretrato di debito tecnico presso l'ufficio di un software che ha un DAL che è circa l'80% di NHibernate2 ma le parti legacy utilizzano stored procedure e proxy manuali con logica di dominio scritta nell'SP ... (incubo ).

Tuttavia, per ogni progetto di manutenzione potremmo dire 10 biglietti di manutenzione per uno sprint di 2 settimane, 1 o 2 di questi biglietti saranno un articolo di debito tecnico. E il cliente è contento di questo dato che si tratta di articoli di manutenzione e gli facciamo firmare come parte degli sprint di manutenzione.

Rompere così efficacemente ciascun elemento del debito tecnico in un ticket che potrebbe essere lavorato da uno sviluppatore per uno sprint di 2 settimane. Questo ti darà una metrica su quanto costerà al cliente, e ti darà anche un'indicazione di velocità mentre passi attraverso un paio di sprint che vedrai avanzare.

L'obiettivo del refactoring è di rendere il codice più pulito, per ridurre i costi di manutenzione e le estensioni a lungo termine. Poiché è molto difficile (anche se non sempre impossibile) ottenere che la direzione o i clienti comprendano il concetto di debito tecnico, è meglio, ed è anche più pratico, farlo in piccoli incrementi, preferibilmente in associazione con alcuni necessari cambiamenti di codice. Quindi, ogni volta che devi toccare un pezzo di codice, lo rendi anche un po 'più pulito, in proporzione alla dimensione del compito concreto. Cioè se è necessario modificare una singola riga di codice per correggere un bug, il pieno refactoring del metodo contenente 100 righe è probabilmente sproporzionato. Ma ad es. rinominare alcune variabili locali per rendere più ovvio il loro scopo o estrarre un paio di metodi più piccoli per rendere più semplice la comprensione del metodo genitore. Quindi, fuori da uno, diciamo, sforzo di 3 ore per individuare la causa principale, scrivere test di unità, correggere il bug ed eseguire tutti i test di regressione, mezz'ora speso per il refactoring va bene, due ore non è: - )

OTOH se c'è un codice che - per quanto brutto o vecchio sembra - non è stato toccato a lungo, funziona bene e non ostacola il mantenimento del resto del programma, probabilmente è meglio solo lascialo com'è, per quanto bello ci sentiamo di averlo lucido e perfetto come il resto del codice (so esattamente come ti senti, ho lavorato su progetti legacy per gran parte della mia carriera :-). Tuttavia, poiché ciò non avrebbe alcun effetto sui costi di manutenzione (poiché non vi è alcuna richiesta relativa alle funzionalità ad esso correlata), la frequenza dei bug (poiché non sono noti bug), non fornirebbe alcun vantaggio per il client.

Tutto sommato, nei progetti del mondo reale, le nostre risorse di refactoring sono limitate (spesso severamente), quindi è meglio focalizzarle su aree in cui noi (e i nostri clienti) otteniamo il miglior ritorno dall'investire nel nostro sforzo e tempo. Questo, a sua volta, è anche il modo migliore per dimostrare il valore del refactoring nei confronti dei clienti / gestione, il che potrebbe, a lungo termine, aiutarti ad avere più tempo per questo ...

Lo vedo come una parte necessaria del mantenimento dell'applicazione. Per un progetto in corso, non penso che sia inaccettabile considerare le quotazioni di miglioramento un tempo per il ri-factoring. Non carichi e carichi, ma man mano che le dimensioni del progetto aumentano, la manutenibilità aumenta. Puoi sempre giustificarlo: in effetti, stai risparmiando i soldi dei clienti a lungo termine, perché stai evitando (o almeno prolungando) la necessità di una riscrittura.

Se vai in garage per avere una parte modificata sulla tua auto, e il meccanico nota un problema con qualcosa di piccolo (un dado rotto o qualcosa del genere) lo aggiusterà. Non farà pagare per questo, è una parte della sua professionalità. Tuttavia, la sua citazione iniziale per voi avrà un po 'di padding per assicurarsi contro la ricerca di queste cose, contro i problemi ecc. È per questo che le citazioni per le auto più vecchie sono più che per le auto più nuove: le persone raramente refactoring le loro macchine per farli andare avanti più a lungo fino a quando non si rompono.