Come programmare qualcosa con l'aspettativa che funzioni la prima volta?

Costruisci piccoli componenti con i loro cablaggi di test indipendenti che dimostrano che ogni pezzo funziona. Far funzionare un programma per la prima volta è solo questione di mettere insieme componenti (intendo "pezzi", non sto parlando di una particolare tecnologia dei componenti) che funziona già.

"Ho appena attivato il debugger non appena ho finalmente ottenuto ciò che sto lavorando per compilare - mi fa risparmiare tempo." Questo mi spaventa in molti modi.

Sì, ho spesso con piccoli moduli. Le funzionalità o il sottosistema completi sono davvero difficili da ottenere correttamente la prima volta.

"Questa è solo una sorta di vecchia stolta ricerca della grandezza applicabile solo a compiti finiti che nessuno dovrebbe sperare nelle nostre vite professionali perché la programmazione è troppo complessa"

In realtà, penso che questo dovrebbe essere SEMPRE il tuo obiettivo principale quando scrivi software. Troppi programmatori abusano del fatto che è piuttosto semplice cambiare semplicemente un pezzo di codice e ricompilare. Questo metodo NON dovrebbe essere il tuo modo principale per risolvere i problemi del software. Ognuno fa un errore, ma se torni in un modulo più di tre volte per aggiustare qualcosa, allora hai un difetto di progettazione o non hai idea di quale sia il codice che la tua scrittura dovrebbe fare.

C'è un margine di manovra se stai imparando una nuova tecnologia.

Sì, ci sono stati numerosi incarichi universitari e funzioni app al lavoro che hanno funzionato solo la prima volta che ho provato. Non succede tutte le volte, ma succede.

Non c'è molto da fare. Si trattava solo di avere una buona padronanza di ciò che stavo facendo e di non affrettare l'implementazione. Essere molto familiare con altre parti del programma mi ha aiutato anche perché non ero così suscettibile di essere inciampato da ipotesi sul codice di qualcun altro.

Certo che ho, il primo!

10 print "mattias"
20 goto 10

Ma in tutta serietà, perché vorresti fare? La programmazione è un processo incrementale, farlo in un colpo solo è come mangiare un melone in un solo sorso.

Guarda il TDD per lo sviluppo guidato dai test. Con la sua natura di scrivere un test prima del codice non funziona mai la prima volta. : -)

TDD è probabilmente il miglior framework per scrivere codice affidabile di qualità. Ha la migliore copertura di test e grazie al suo design riduce la quantità di codice "what if". Dato che devi scrivere un test prima di scrivere il codice, anche IMO riduce la quantità di funzioni extra che le cose del programmatore sono "cool", dal momento che lo sviluppatore deve effettivamente creare uno scenario di test completo attorno a quella caratteristica interessante, ma non necessaria. p>     

Ho spesso scritto programmi non banali (~ 200 LOC o così), li ho eseguiti e hanno funzionato la prima volta. Come altri hanno già detto, aiuta a scrivere in modo modulare in modo da avere la certezza che ogni pezzo funzionerà come previsto.

Scrivere programmi modulari richiede una pianificazione. Spendo probabilmente circa la metà del mio sforzo cognitivo di fronte solo a pensare al problema. Aiuta anche a programmare da oltre 30 anni; molte tecniche di programmazione comuni sono diventate dei pattern e io li scrivo senza pensarci troppo.

Faccio del mio meglio con una lingua che non mi ostacola: Perl. La sua sintassi flessibile mi consente di ottenere rapidamente le mie idee senza troppi problemi. I tipi deboli e dinamici significano che non devo preoccuparmi di dichiarare le variabili prima di usarle, né devo preoccuparmi delle perdite di memoria e del corretto dimensionamento delle strutture di dati. Funzionano e posso mettermi al lavoro.

Un modello comune è quello che sfonda un file di testo, ignorando i commenti, tagliando gli spazi vuoti e scartando le righe vuote. Il resto viene messo in un array.

while (<>)
{
    s/#.*$//;          # Trim comments
    s/^\s+|\s+$//g;    # Trim blanks
    next if (/^$/);    # Discard blank lines
    push @lines, $_;
}

Per me accade di solito con singoli componenti di complessità abbastanza semplice. Penso che sia un buon esercizio da fare una volta ogni tanto in quanto ti costringe a pensare completamente attraverso il "flusso" del tuo codice piuttosto che il metodo tweak e compilare. Ti rende anche più veloce a lungo termine perché alla fine migliorerai nella scrittura di codice pulito fin dall'inizio e quindi trascorrerai meno tempo a sistemare le cose. Se dipendi costantemente dal compilatore, avrai sempre l'overhead associato a "tweak / compile".

Debug costante per vedere se il codice appena scritto funziona correttamente tende a perdere tempo, a mio parere. Può essere necessario occasionalmente, ma se il codice non è abbastanza semplice da pensarci, trovo più produttivo scrivere test automatici. Quindi, puoi semplicemente eseguirli / modificarli mentre codifichi e vedere se le tue asserzioni sono vere.

Dai un'occhiata al capitolo "Programmi di scrittura corretta" di "Programming Pearls" di Jon Bentley, in particolare la sezione 4.2. Personalmente non posso immaginare di andare a questo livello di rigore su ogni singola cosa che scrivo, ma penso che sia un buon esempio del tipo di pensiero che devi fare per farlo bene la prima volta.

Quando lavoro in Smalltalk faccio quasi tutti il mio sviluppo nel debugger.

Scrivo un test che fallisce, dimostrando il comportamento corretto del codice ancora da scrivere, e premo il pulsante Vai sul corridore del test. Il test fallisce. (Se non fallisce, prima scopro perché!) Faccio clic sul test, facendo apparire il debugger. Passo il punto in cui il problema è, digito quello che devo fare per fare passare il test - definire una classe, scrivere un metodo, qualunque cosa - e poi premere "procedi". Speriamo che il test passi ora. In caso contrario, eseguo il rollback dello stack di chiamate per scoprire dove ho commesso l'errore e continuo a eseguire il test.

Dopo aver finito, di solito eseguo l'intera suite, solo per assicurarmi di non rompere nulla.

Per me, qualunque cosa scriva funziona solo per la prima volta, non è quello che succede a tutti gli altri?

In tutta serietà, programmare è come digitare a occhi chiusi, più scrivi, più è probabile che tu commetta un errore e più tempo ci vorrà per trovarlo. Se presti particolare attenzione, potresti essere in grado di scrivere un accordo equo, ma se non puoi essere sicuro che sia giusto allora qual è il punto?