Come superare la programmazione per coincidenza? [chiuso]

Non devi pensare al futuro, devi solo essere molto chiaro su ciò che è stato fatto ed essere molto chiaro su ciò che stai facendo in questo momento.

Le subroutine dovrebbero dire quello che fanno, fare ciò che dicono e non avere dipendenze nascoste. Quindi qualcuno che li chiama può più facilmente ragionare su ciò che faranno.

Evita lo stato globale. (Variabili, singleton, ecc.) Più lo stato che devi avere nella tua testa per capire cosa fanno le cose, più difficile è capire cosa dovrebbe accadere e trovare i casi limite.

Scrivi test unitari. I test unitari sono ottimi per catturare l'effettivo comportamento del codice appena scritto, piuttosto che il comportamento ideale che speri di trovare.

Riduci il ciclo di modifica / compilazione / test. Quando aggiungi una grande porzione di codice e test male, allora le probabilità sono che si comporterà in modo diverso da quello che pensi. Quindi "lo aggiusti" con qualche cambiamento casuale, e hai la risposta giusta per il momento, ma non hai idea di come sia realmente successo. Ora stai programmando per coincidenza. Ma quando aggiungi 5 linee e poi esegui il test, le probabilità che tu abbia la risposta giusta perché funziona come pensi che funzioni è molto meglio. Posso dire per esperienza che 5 blocchi di 10 linee ciascuno, testati individualmente, sono una bestia molto diversa da 50 righe di codice testate tutte insieme.

Refactor spietatamente. Molte volte ho individuato un refactoring che renderà il mio codice un po 'più semplice, ma mi prendo un sacco di lavoro che non volevo fare. Dopo aver iniziato deliberatamente a trattare questi refactoring come una priorità, ho scoperto che di solito si ripaga da solo nel giro di un mese. Ma nota la chiave, i refactoring su cui mi concentro sono quelli che semplificano la vita quotidiana, e non quelli che soddisfano qualche estetica arbitraria di migliore o più generale. Quei refactors che ho imparato a essere molto più cauti con.

Nessuna di queste cose richiede una pianificazione anticipata. Ma semplificano la comprensione del codice esistente e rendono semplice implementare il tuo prossimo blocco in modo deliberato.

Si riduce praticamente a non indovinare . La maggior parte dei nuovi programmatori lo fanno, ma ho visto anche i veterani, perché pensano che risparmi tempo di ricerca. Qualcosa non funziona, quindi aggiungi +1 o -1 , cambia true in false o viceversa, riordina alcune istruzioni, aggiungi o modifica ritardi, cambia priorità thread e altre piccole trasformazioni , fondamentalmente testando permutazioni casuali fino a quando non funziona.

Questo vale soprattutto per la modifica del codice esistente, ma anche per un codice nuovo di zecca, perché nessuno inizia veramente da zero. Stai sempre costruendo su librerie standard, sistemi operativi o almeno architetture di processore.

In altre parole, non hai finito finché non sai perché la tua correzione funziona. Il percorso che prendi per arrivarci non ha importanza. Talvolta le permutazioni casuali possono essere utili per restringere un bug difficile da diagnosticare, a patto che ci si dedichi in seguito a chiedersi: "Ok, cambiando vero a falso, ma perché?"

Il commento più spaventoso che abbia mai incontrato in un programma è stato

Do not touch this. It works. We don't know how or why, but it works.¹

ed è spaventoso solo perché riconosce che il pezzo di codice era il risultato di programmazione per coincidenza .

Per evitare di programmare per coincidenza, dovresti essere in grado di spiegare (a un collega tu stesso o un'anatra di gomma ) esattamente cosa fa il codice e perché funziona. I proiettili per la programmazione deliberatamente sono principalmente di aiuto nel muoversi verso l'obiettivo di essere in grado di spiegare il codice.

¹ Per il contesto, questo commento è apparso nel codice che gestisce gli switch di contesto in un sistema operativo primitivo. Il codice era già in produzione da diversi anni quando l'ho incontrato.

Per i nuovi programmatori, la parte più importante del superamento di questo è capire veramente cosa stanno facendo.

In molte aree, quando non sai come fare qualcosa, vai per tentativi ed errori. Prova qualcosa; se funziona, ottimo, se non, prova qualcos'altro.

Nella programmazione, specialmente quando si usa un linguaggio che ha il concetto di comportamento indefinito (come C o C ++), questo approccio semplicemente non funziona, perché il successo non è più una decisione booleana. Puoi avere cose che "tipo di" funzionano, che a volte funzionano, che funzionano per alcuni input ma non per altri.

In alcune occasioni ho istruito nuovi programmatori e la tendenza a provare a digitare cose casuali per vedere se funziona è comune. Scriveranno una riga, quindi si rivolgono a me e chiedono: "Funzionerebbe in questo modo?" mentre era chiaro che non avevano assolutamente alcun indizio se potesse.

Il takeaway è che come nuovo programmatore devi essere in grado di spiegare cosa fa il tuo codice. Devi imparare a leggere il codice, non solo a scriverlo.

(Ovviamente questo vale anche per i programmatori esperti, ma la mia esperienza qui è stata principalmente con nuovi principianti completi.)

È fin troppo facile codificare, testare e risolvere "sulla linea di regata". Hai alcune funzionalità che hanno dato X & Y, produce Z. Ma cosa succede se X è corrotto e Y non è disponibile? Cosa succede se non riesci a produrre Z? Ricorda sempre cosa può andare storto e prendine nota per il ciclo di test.

Mantieni le tue routine brevi e descrittive: il codice migliore richiede pochi (se ci sono) commenti.

Il metodo significativo, i nomi di classi e variabili aiutano a migliorare la leggibilità.

Se ti imbatti in un odore di codice, allora FERMA. È improbabile che quell'odore se ne vada e in seguito un piccolo sforzo potrebbe salvarti un'enorme quantità di dolore in seguito.

Includi test nel tuo processo di sviluppo. Sostengo l'uso di BDD piuttosto che TDD in quanto ti costringe a descrivere ciò che stai cercando di ottenere piuttosto che affidarti ciecamente a una serie di test che potrebbero darti un falso senso di sicurezza.

Resisti all'impulso di aggiungere funzionalità straordinarie (a meno che non sia il tuo progetto preferito). Qualsiasi codice aggiuntivo deve essere progettato, scritto, testato e mantenuto. Se non è richiesto dal cliente / azienda, rischi di diventare un enorme drenaggio delle tue risorse.