Immagina il seguente scenario:

Hai rilevato che il tuo programma (o quello di qualcun altro) presenta un bug: una funzione produce un risultato errato quando viene fornito un input particolare. Esamini il codice e non trovi nulla di sbagliato: sembra semplicemente impantanarsi quando viene dato questo input.

Ora puoi fare una delle due cose: o esaminare ulteriormente il codice fino a quando non si trova la causa effettiva; oppure schiaffi su una benda aggiungendo ifun'istruzione che verifica se l'input è questo input particolare - se lo è, restituisce il valore atteso.

Per me, applicare la benda sarebbe del tutto inaccettabile. Se il codice si sta comportando in modo inaspettato su questo input, a quale altro input che hai perso reagirà in modo strano? Semplicemente non sembra affatto una soluzione: stai solo spalando il problema sotto il tappeto.

Dato che non prenderei nemmeno in considerazione la possibilità di farlo, sono sorpreso di quanto spesso i professori e i libri continuino a ricordarci come applicare le correzioni alla "benda" non sia una buona idea. Quindi questo mi fa chiedere: quanto sono comuni questi tipi di "correzioni"?

Le pressioni di tempo / scadenza sono una delle ragioni.

Se ti trovi ad affrontare una scadenza serrata e hai il capo che ti respira giù dal collo (forse letteralmente!), Quindi farlo e pensare "Tornerò e aggiusterò più tardi" è molto allettante e potrebbe essere l'unica cosa che può fare.

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

Per quanto a noi programmatori non piaccia ammetterlo, un software meravigliosamente codificato non tradurrà sempre più valore per l'azienda o per i clienti. Ciò è doppiamente vero in una situazione di disastro, ad esempio il software sta caricando due volte le carte di credito delle persone. A volte, come una benda, devi solo fermare l'emorragia con qualsiasi mezzo necessario e promettere di tornare dopo che il paziente si è stabilizzato e in realtà risolve il problema principale.

Il trucco è che, una volta persa l'urgenza, è davvero difficile convincere chiunque a dare la priorità alla sostituzione della benda con una vera correzione. Soprattutto se si considera che c'è sempre un altro problema urgente in attesa dietro il primo. Devi solo essere vigile riguardo al fatto di risolvere il problema oltre la soluzione rapida.

Tempo

È il primo motivo secondo me. Anche se il problema riguarda la base di codice, potrei impiegare più tempo a indagarlo. Spesso le mie correzioni "bendaggio" comportano modifiche CSS o UI. Ho scritto alcuni CSS e JavaScript piuttosto cattivi in ​​linea per gestirli rapidamente. Tornare indietro e risolverlo è sempre un'opzione se hai 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 rigida,
• Eccezionalmente le modifiche al codice per correggere la causa principale non sono tatticamente fattibili (il cambiamento richiederà troppo tempo e la scadenza si avvicina)

In quei casi optiamo per le correzioni "bendaggio". Apriamo quindi difetti interni per affrontare 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 risolvere la causa principale non sia tatticamente fattibile (il cambiamento non è banale e il cliente aveva bisogno della correzione ieri).

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

Disambiguazione.

• Dato un particolare bug, esiste 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: per correggere un difetto in un modo che è meno elegante e meno ben studiato di quanto avrei voluto fare professionalmente.

In primo luogo, per quanto riguarda la frequenza delle correzioni "bendaggio":

• Nuovo codice: quasi nessuno.
• Vecchio codice:
  • Ne troverai alcuni, anche se di solito sono scritti in modo abbastanza elegante (vedi "mitigazione basata sui dati" di seguito) da non sembrare bende e sopravviveranno a tutte le revisioni del codice.
  • Fai anche attenzione alla "benda invisibile": semplicemente non chiamare quella funzione. Con la mancanza di codice, non c'è nemmeno traccia di indizio dell'esistenza di 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 letto le "note sulla versione" della dipendenza prima di aggiornare la dipendenza a una nuova versione.

Secondo, il mio consiglio:

Se il bug si verifica nel codice sorgente di un team di sviluppo:

• Risolvilo in modo professionale. (Se lo aggiusti, lo possiedi.)
• Quando sei sotto pressione, fai il meglio che puoi - il che richiede di:
  • Guarda il potenziale impatto sull'utente finale: del bug stesso e della correzione proposta, al fine di decidere se accettare la correzione.
  • Studia gli snippet di codice correlati (utilizzando le informazioni sulla cronologia del tuo strumento di gestione del codice sorgente) e discuti con i tuoi colleghi (ma non occupare troppo tempo), fino a quando non avrai ben compreso il problema e la soluzione.
• Traccia sempre il bug con un sistema di tracciamento dei difetti .

Se il bug si verifica nel codice sorgente di un'altra squadra:

• Spingi quella squadra per correggere il loro bug.
• Presentare sempre quel bug con il sistema di localizzazione dei difetti dell'altra squadra .

Se il bug si verifica nel prodotto di un'altra azienda (o nessuna azienda):

• In questo caso, le correzioni del nastro adesivo (o soluzioni alternative basate sui dati ) potrebbero essere l'unico modo per correggere l'errore.
• Se è open source, archivia comunque quel bug con qualche sistema di tracciamento dei difetti (possibilmente pubblico) , in modo che qualcuno possa esaminarlo.

Dipende molto dall'età della base di codice che penso. Sul vecchio codice penso che sia molto comune, riscrivere che la routine COBOL di 20 anni non è divertente. Anche su un codice moderatamente nuovo in produzione è ancora abbastanza comune.

Direi che è molto comune.

Dai un'occhiata al post sul blog di Joel Spolsky: The Duct Tape Programmer

Posso facilmente dire che quasi ogni progetto in cui sia mai stato, ho dovuto applicare una sorta di bendaggio o nastro adesivo per rispettare le scadenze e completare un'attività. Non è carino, non è pulito, ma fa il lavoro in modo che un'azienda possa continuare a funzionare e il progetto può andare avanti in qualche modo.

C'è una differenza tra il mondo accademico e il mondo reale in cui il software deve effettivamente essere spedito in tempo e contro i limiti commerciali.

In un certo senso lo sta mettendo sotto il tappeto, per rimandare una correzione, fino a quando, si spera, più tardi. Purtroppo, troppo spesso, la correzione differita non si verifica mai e questo codice si fa strada nella produzione.

È difficile dirlo senza più contesto: nel tuo esempio, perché aggiungere l'istruzione if non è la correzione corretta? È perché presumibilmente c'è qualche altro blocco di codice lì dentro da qualche parte che dovrebbe avere a che fare con quell'input?

La frequenza con cui vengono utilizzate le correzioni della benda dipende da una serie di cose come la complessità del codice, se la persona che ha più familiarità con il codice è disponibile (la persona responsabile della routine COBOL ventenne di Craig potrebbe aver lasciato l'azienda anni fa ) e i tempi previsti.

Con una scadenza che ti fissa in faccia, a volte cercherai la soluzione più sicura, anche se si tratta solo di schiaffeggiare un cerotto piuttosto che fissare la causa principale. Va bene purché non peggiori le cose, ma è importante tenere traccia del fatto che non è ancora corretto e deve ancora essere corretto.

Ci sono casi in cui questo 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 fungere da una sorta di moduli per il tuo eseguibile principale, ma richiedono anche alcune informazioni dall'eseguibile principale per essere eseguite.

Se mai si desidera utilizzare quelle DLL al di fuori dell'eseguibile principale, è necessario fondere alcuni valori di ritorno dall'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 assicurarsi di eseguire un codice completamente diverso quando si confondono i risultati rispetto a quando si ottengono risultati reali.

Invece di mettere ifdentro la funzione di qualcun altro, ne metterei una {$ifdef}intorno alla funzione - in questo modo nessuno la confonde con qualcosa che dovrebbe essere lì.