Tutte le correzioni sporche sono state create uguali? [chiuso]

Una correzione "sporca" è una forma di Debito tecnico e se puoi permetterti è in fin dei conti un costo / analisi dei benefici.

Con le scuse a Olve Maudel che (in un fulmine (p3) al ACCU conference ) potrebbe aver detto qualcosa di non completamente diverso dal seguente, confrontare:

• Il costo immediato di correggere correttamente un bug + il costo immediato di non averlo risolto in tempo

vs.

• Il costo immediato di una fix sporca + il costo a lungo termine della fix dirty

Se risolvendolo correttamente, significa che ti manca una scadenza che ti avrebbe dato un pagamento progressivo, o significa che un concorrente arriva sul mercato prima di te, allora quel costo potrebbe essere piuttosto alto e potrebbe valere la pena di incorrere in debito invece. Ma ricorda che più a lungo lasci questo debito non retribuito, maggiore sarà l'interesse che otterrai in termini di costo del supporto del codice e aggiunta di nuove funzionalità.

Attenzione però, se si usa pragmatico come scusa per la pigrizia e si continua ad accumulare il debito tecnico, ma non si ripaga mai il debito precedente attraverso il ri-factoring, si può scoprire che il debito aumenta così alto che fallimento è l'unica opzione pragmatica rimasta. * 8' )

È vero che una "correzione" sporca "non è una correzione (a). Se un prodotto ha un problema, una soluzione pulita ha lo scopo di risolvere questo problema per poter:

• Riutilizzare la parte interessata del prodotto e assicurarsi che non ci siano problemi noti con esso,
• Non è necessario tornare a modificare il codice più tardi per risolvere i bug.

Con una correzione sporca, lo sviluppatore:

• Impossibile riutilizzare la parte interessata, perché non può essere sicura che funzionerà come previsto,
• Deve tornare più tardi per riscrivere correttamente il codice.

Quindi, invece di dedicare più tempo a sistemare qualcosa, una soluzione sporca viene utilizzata per trascorrere meno tempo immediatamente, ma più tempo ultimamente costringendo a tornare e fare una correzione e vietando di riutilizzare il codice nel frattempo.

Ovviamente, questo potrebbe non essere applicabile a tutte le correzioni sporche e dipende anche da ciò che chiamiamo una correzione sporca o meno. Esempio:

Un utente invia un rapporto dicendo che un programma fornisce un risultato errato quando l'input è uguale a 39.5. Una soluzione candidata al DailyWTF stupidamente sporca dovrebbe essere:

if (input == 39.5)
{
    // 14.7 is a correct result, calculated by hand.
    output = 14.7;
}
else
{
    // Keep the old and broken algorithm.
    // ...
}

È probabile che in pochi giorni o settimane, un altro rapporto di un altro cliente ci dirà che l'output non è corretto per altri valori di input.

Una soluzione meno sporca sarebbe quella di controllare l'algoritmo, vedere dove si è rotto e correggerlo, senza correggere i test di unità . Le possibilità di vederlo rompere di nuovo sono minori, ma può succedere, e c'è bisogno di tornare più tardi per aggiungere test unitari, magari aggiungere commenti, applicare linee guida di stile, scrivere documentazione, ecc.

Quindi sì, alcune correzioni più sporche di altre (b, c). Se alcuni sono più accettabili di altri dipende dalle linee guida della tua azienda.

Correzioni sporche mostrano un uso pragmatico del tempo (d, e). In un momento preciso Perché spendendo qualche minuto in meno, perdi ore del tuo tempo (o i tuoi colleghi passeranno più tardi a pulire la tua correzione). Ecco perché le correzioni sporche dovrebbero essere scoraggiate soprattutto in una squadra. Se uno sviluppatore fa molte correzioni sporche, lascia la compagnia, le altre persone del team avranno difficoltà a pulire le correzioni.

Come possiamo smettere di atteggiamenti come "correzioni sporche mostrano un uso pragmatico del tempo e non dovrebbero essere scoraggiati" dal diventare una pratica standard?

Con rafforzamento delle best practice , ma anche assicurando che gli sviluppatori di un team / in una comunichi bene su ciò che stanno facendo. Troppa pressione e stress dalla gestione può anche costringere gli sviluppatori a utilizzare più correzioni sporche solo per finire rapidamente. Questo è particolarmente vero quando il team manager è abbastanza inesperto e / o non si preoccupa della qualità del codice .

Dipende dal contesto.

Ho certamente apportato alcune correzioni orribili ai miei tempi, ma il codice su cui stavo lavorando era oltre la redenzione - un disastro completo di PHP che era copia / incolla di dipendenze ovunque (con variazioni) e il database più casuale "design" che abbia mai visto. Naturalmente non mostrerò mai quel codice a supporto di un'applicazione di lavoro!

Normalmente vado con a) Per lo meno ciò che faccio dovrebbe essere comprensibile e mantenibile. Se riesco a migliorare / refactoring un po 'allo stesso tempo, tanto meglio.

d) ed e) sono semplicemente pigri ... potresti risparmiare 30 minuti ora, ma quando sarà necessario il prossimo aggiornamento / correzione tra sei mesi? È una falsa economia.

In generale, è necessario evitare e rifiutare gli hack / le correzioni sporche. Ci sono tuttavia delle eccezioni.

1. Se il framework / linguaggio è troppo limitato per farlo correttamente senza una massiccia ristrutturazione del progetto.
2. Se il framework / lingua ha un bug che deve essere risolto intorno
3. Se non esiste un modo prevedibile per correggere in modo pulito il problema principale (correlato alla # 1)

Per # 3: Ad esempio, ho fatto alcune cose molto strane lavorando attorno al ciclo di vita della pagina storta di ASP.Net. Ho capito esattamente come veniva chiamato ogni evento e perché il mio codice non funzionava. Così ho finito per chiamare manualmente _Click metodi controllando la matrice Form in precedenza nel ciclo di vita della pagina di quanto normalmente si chiamino gli eventi.

Per n. 1: Avevo una query SQL in fase di creazione manuale, quindi ho finito per essere come

query="select * from table where";
if(Option1){
  query+=" option1='"+Option1String+"' ";
}
if(Option2){
  query+=" option2='"+Option2String+"' ";
}
if(Option3){
  query+=" option3='"+Option3String+"' ";
}

Quindi è risultato che se nessuna delle opzioni fosse selezionata, avrei ricevuto un errore di sintassi. La mia altra opzione era quella di creare costantemente un if(Option1 | Option2 | Option3) che pensavo fosse un incubo di manutenzione per quando sono state aggiunte opzioni. Quindi l'ho risolto con una singola modifica:

query="select * from table where 1=1";

Considererei questo dirty / a hack perché non è immediatamente evidente il motivo per cui 1=1 è stato messo lì. Naturalmente ho commentato a malapena spiegandolo. Ma è ancora un hack. L'alternativa "corretta" era più difficile da mantenere comunque.

Una correzione "sporca" è una correzione; altrimenti, non sarebbe una pausa?

Penso che la domanda se una correzione "sporca" debba essere inaccettabile o scoraggiata presuppone che esista una chiara distinzione tra una correzione "sporca" e una correzione "pulita", e non credo che esista. Ho applicato correzioni che pensavo fossero "pulite" che alla fine si sono rivelate "sporche" rispetto alla prossima correzione. (Meno spesso, ho applicato correzioni che pensavo fossero "sporche" che alla fine si sono rivelate abbastanza "pulite"). Penso che sarebbe più utile distinguere tra una correzione "sporca" e una correzione "sporca", con la prima che è preferibile, la somma di tutti gli altri è uguale.

Sia la correzione "sporca" che quella "sporca" dovrebbero risolvere il problema immediato, ma rispetto alla correzione "sporca", la correzione "sporca" dovrebbe ridurre la probabilità di errore futuro e, in caso di errore, ridurre lo sforzo richiesto per risolvere questo errore. Ciò potrebbe richiedere anche il refactoring del codice, o potrebbe richiedere un minimo di documentazione del codice e di registrazione della sua esecuzione, in modo che il prossimo sviluppatore possa essere più in grado di diagnosticare e correggere l'errore.

Per quanto riguarda il modo in cui scoraggiare gli sviluppatori dalla scelta della correzione "più sporca", direi, smettere di incoraggiare gli sviluppatori a scegliere la correzione "più sporca" preferendo esplicitamente la correzione più veloce e quindi implicitamente preferendo la "più sporco".

In generale, un "fix" o un "hack" è una brutta cosa. E a scuola impariamo come non fare le riparazioni. Ma nella vita reale, quando il tempo è essenziale, le correzioni avvengono come codici di identificazione costanti, non rendendo il codice abbastanza generale e t c. Finché tutti i partecipanti al progetto sono d'accordo su cosa si sta facendo, penso che sia OK. Il rischio è che il codice non venga modificato in seguito per essere corretto. Il rischio è che si stia costruendo un labirinto di codice che sarà sempre più difficile correggere più a lungo rimarranno le correzioni. Inoltre, il tempo di modificare le correzioni aumenta il logaritmico più a lungo è permesso loro di rimanere nella soluzione.

Quindi sono d'accordo su c) e d) se possibile - nel senso che se hai bisogno di fare una correzione, commentala bene e rendi il codice abbastanza semplice per il prossimo programmatore, che potrebbe essere quello per correggere la correzione. Quindi hai sfruttato al massimo la situazione attuale.

Mi chino verso f) con una buona dose di d) ec).

Se la prossima versione del codice viene sviluppata attivamente, una correzione (rapida) sporca potrebbe essere un'azione appropriata sul ramo di produzione. La correzione dovrebbe essere il più pulita possibile e certamente non dovrebbe essere considerata un candidato DailyWTF. Potrebbe consentire di correggere il ramo di produzione nei casi in cui la correzione rapida richiederà più lavoro di quanto sia pratico.

Se si utilizza una correzione sporca, non dovrebbe essere unita al ramo di sviluppo. Con poche eccezioni (funzionalità abbandonate), tutte le correzioni di produzione dovrebbero essere applicate al flusso di sviluppo. Se è possibile applicare una correzione pulita, è opportuno unirla al flusso di sviluppo. In caso contrario, la correzione dovrebbe essere ripristinata in modo pulito sul flusso di sviluppo.

La domanda è in gran parte accademica. Molto spesso, in un ambiente di produzione, non c'è tempo per fare cose "pulite" quando un problema appare su un sistema di produzione. Quindi prendi il percorso più veloce per risolvere il problema, limitando il più possibile i tempi di fermo. Potrebbe essere una "soluzione sporca" in quanto non è il miglior aspetto del codice, ma svolge il lavoro che è molto più importante in quanto i tempi di inattività significano una perdita di entrate, codice che non sembra bello significa solo punti perduti per i programmatori ego.

Se si tratta di un vero e proprio hack, probabilmente lo taggerai per il refactoring alla prima opportunità (cioè quando quella parte del codice verrà successivamente programmata per il cambiamento, NON nella prossima versione solo perché vuoi sbarazzarti di it), ma andrà ora perché non c'è semplicemente il tempo di fare le cose bene.

Questo è il mondo delle scadenze, che si adattano alle esigenze del mondo reale piuttosto che ai compiti a casa.

La mia opinione è che ci sia mai una buona ragione per una correzione sporca, solo scuse che suggeriscono un problema più ampio. A volte quel problema è qualcosa che non puoi correggere (ad esempio nessun management buy-in, problema con il framework / linguaggio che stai usando) ma è sempre comunque una scusa per coprire qualcos'altro.

Non sorprendentemente cerco di evitare di fare le cose nel modo "sporco" ogni volta che sia possibile, poiché la mia esperienza è che non sarai mai in grado di aggiustarlo correttamente e "ripagare" il debito tecnico.