Le pressioni di tempo / scadenza sono una delle ragioni.

Se hai una scadenza serrata e hai il tuo capo che ti respira il collo (possibilmente letteralmente!), fare questo e pensare "Tornerò e sistemarlo più tardi" è molto allettante e potrebbe essere il unica cosa che puoi fare.

Ovviamente il numero di volte in cui si torna indietro e si corregge in modo corretto sono molto pochi e distanti tra loro perché si ha un nuovo problema che deve essere risolto ieri.

Tanto quanto noi, come i programmatori, non amiamo ammetterlo, il software splendidamente codificato non tradurrà sempre più valore per l'azienda o per i clienti. Questo è doppiamente vero in una situazione di disastro, ad esempio il software sta caricando le carte di credito delle persone. A volte, come una benda, devi solo interrompere l'emorragia con qualsiasi mezzo necessario e promettere di tornare dopo che il paziente è stato stabilizzato e in realtà risolvere il problema principale.

Il trucco è che, una volta esaurita l'urgenza, è davvero difficile convincere qualcuno a dare la priorità alla sostituzione della fascia con una vera correzione. Soprattutto considerando che c'è sempre un altro problema urgente in coda dietro il primo. Devi solo stare attento a stare con il problema oltre la soluzione rapida.

Ora

È la ragione numero 1 secondo me. Anche se il problema riguarda il codebase, potrei impiegare più tempo per studiarlo. Spesso le mie correzioni di "bendaggio" coinvolgono trucchi CSS o UI. Ho scritto alcuni CSS e JavaScript inline piuttosto sgradevoli per affrontarli rapidamente. Tornare indietro e aggiustarlo è sempre un'opzione se ne hai il tempo.

Li facciamo eccezionalmente.

Per le correzioni durante lo sviluppo, ci stiamo assicurando che nessuna correzione venga eseguita senza conoscere la causa principale. Tuttavia:

• Eccezionalmente, la ricerca della causa principale inizierà a richiedere troppo tempo o si fermerà E c'è una scadenza difficile,
• Eccezionalmente le modifiche al codice per correggere la causa principale sono tatticamente non fattibili (il cambiamento richiederà troppo tempo e la scadenza si avvicina)

In questi casi optiamo per le correzioni di "bendaggio". Quindi apriamo i difetti interni per risolvere la causa principale. Sì, il più delle volte questi difetti interni sono trattati con priorità molto bassa.

Per le correzioni nel flusso di manutenzione, ci stiamo assicurando che nessuna correzione venga eseguita senza conoscere la causa principale. Tuttavia:

• Molto eccezionalmente la ricerca della causa principale si interromperà,
• Eccezionalmente può accadere che la correzione della causa principale sia tatticamente non fattibile (il cambiamento non è banale e il cliente ha avuto bisogno della correzione ieri).

In questi casi, prima optiamo per la correzione temporanea "bendaggio" e, una volta che il cliente è soddisfatto, lavoriamo alla correzione corretta e solo allora il problema viene risolto.

Disambiguation.

• Dato un bug particolare, c'è una notevole difficoltà nel definire oggettivamente se una determinata correzione è una "benda" perché: la "soluzione corretta" di una persona può essere la "benda" di un'altra persona.
• Quindi, uso la seguente definizione: correggere un difetto in un modo meno elegante e meno studiato di quanto avrei voluto fare professionalmente.

Innanzitutto, per quanto riguarda le correzioni frequenza di "bendaggio":

• Nuovo codice: quasi nessuno.
• Vecchio codice:
  • Ne troverai alcuni, anche se di solito sono scritti con eleganza (vedi "mitigazione basata sui dati" di seguito) che non sembrano bende e sopravviveranno a tutte le revisioni del codice.
  • Prestare attenzione anche al "bendaggio invisibile": semplicemente non chiamare quella funzione. Con la mancanza di codice, non c'è nemmeno una traccia di suggerimento che esista un bug.
• Vecchio codice con molte dipendenze esterne:
  • Quasi pieno di esso.
  • È stato quasi sempre scritto per una versione obsoleta della dipendenza, e nessuno ha veramente letto le "note di rilascio" della dipendenza prima di aggiornare la dipendenza a una nuova versione.

Secondo, il mio consiglio:

Se l'errore si verifica nel codice sorgente di un team di sviluppo:

• Risolvilo in modo professionale. (Se lo aggiusti, lo possiedi.)
• Quando sei sotto pressione, fai le cose migliori che puoi - il che richiede di:
  • Esamina il potenziale impatto sull'utente finale: del bug stesso e della correzione proposta, al fine di decidere se accettare la correzione.
  • Frammenti di codice relativi allo studio (utilizzando le informazioni sulla cronologia dal tuo strumento di gestione del codice sorgente) e discuti con i tuoi colleghi (ma non occupati troppo del loro tempo), finché non hai compreso bene il problema e la soluzione. / li>
• Traccia sempre il bug con un sistema di tracciamento dei difetti .

Se l'errore si verifica nel codice sorgente di un'altra squadra:

• Spingi il team per correggere il bug.
• Inserisci sempre il bug con il sistema di tracciamento dei difetti dell'altro team

Se l'errore si verifica nel prodotto di un'altra azienda (o di nessuna società):

• In questo caso, le correzioni al nastro duttile (o soluzioni alternative basate sui dati ) potrebbero essere l'unico modo per correggere il bug.
• Se è open source, inserisci il bug con qualche (forse pubblico) sistema di tracciamento dei difetti in ogni caso, in modo che qualcuno possa esaminarlo.

Credo che dipenda molto dall'età del codice base. Sul vecchio codice penso che sia molto comune, riscrivere quella routine COBOL di 20 anni non è divertente. Anche su un codice moderatamente nuovo che è in produzione è ancora piuttosto comune.

Direi che è molto comune.

Guarda il post del blog di Joel Spolsky: Il programmatore di Duct Tape

Posso facilmente dire che quasi tutti i progetti che ho mai fatto ho dovuto applicare qualche tipo di nastro adesivo o duttile per rispettare le scadenze e completare un'attività. Non è bello, non è pulito, ma svolge il lavoro in modo che un'azienda possa continuare a funzionare e il progetto può andare avanti in qualche modo.

Esiste una differenza tra il mondo accademico e il mondo reale in cui il software deve effettivamente essere spedito in tempo e con i vincoli commerciali.

In un certo senso lo sta mettendo sotto il tappeto, per rimandare una correzione, fino a quando si spera, dopo. Tristemente, troppo spesso, la correzione posticipata non avviene mai e questo codice trova la sua strada nella produzione.

È difficile dire senza più contesto - nel tuo esempio, perché aggiungere l'istruzione if se non la correzione corretta? È perché c'è presumibilmente qualche altro blocco di codice lì da qualche parte che dovrebbe occuparsi di quell'input?

Quante volte vengono utilizzate correzioni di bende dipende da un numero di cose come la complessità del codice, se la persona più familiare con il codice è disponibile (la persona responsabile per la routine COBOL di Craig di 20 anni potrebbe aver lasciato il società anni fa) e le tempistiche coinvolte.

Con una scadenza che ti fissa in faccia, a volte ti addolci per la soluzione più sicura, anche se si tratta semplicemente di dare uno stucco piuttosto che fissare la causa principale. Va bene finché non peggiori le cose, ma è importante tenere traccia del fatto che non è ancora corretto e deve ancora essere corretto correttamente.

Ci sono casi in cui quel tipo di correzione è davvero OK e probabilmente l'ideale (per quanto riguarda il tempo necessario per il debug).

Immagina uno scenario in cui hai 20 DLL che dovrebbero funzionare come una sorta di moduli per il tuo eseguibile principale, ma richiedono anche alcune informazioni dell'eseguibile principale da eseguire.

Se si desidera utilizzare quelle DLL al di fuori dell'eseguibile principale, sarà necessario fondere alcuni valori di ritorno dell'eseguibile principale perché. A.) Non esiste in questo contesto e B.) Non vuoi che esista in questo contesto.

Detto questo, è meglio inserire alcune direttive del compilatore nel codice per essere certo di eseguire codice completamente diverso quando si ottengono risultati più soddisfacenti rispetto a quando si ottengono i risultati reali.

Invece di mettere un if nella funzione di qualcun altro, metterei un {$ifdef} attorno alla funzione - in questo modo nessuno lo confonde con qualcosa che dovrebbe essere lì.