Quando si sviluppano algoritmi, saltare la fase penna e carta è una cattiva abitudine? [chiuso]

Alcuni sviluppi algoritmici possono richiedere un sacco di test ed ottimizzazione di prove ed errori, in quanto si può scoprire che le ipotesi che verrebbero inserite in un progetto rigorosamente cartaceo risultano non sufficientemente accurate quando vengono forniti dati reali e vincoli prestazionali.

Forse l'iterazione (think-code-test-think-code-test ...), piuttosto che una semplice scelta o per l'"abitudine" ottimale.

C'è anche una via di mezzo, che di solito uso. Non pensare troppo in anticipo, e non perdersi nei dettagli del mio codice ...

TDD (Test driven development) ti lascia pensare un po ', poi fallo funzionare; quindi pensa un po 'di più a ciò di cui hai bisogno, poi fallo funzionare, disponendo della rete di sicurezza che il tuo caso d'uso precedente continua a funzionare in ogni momento ... I passaggi sono:

1. Scrivi un test (vale a dire un caso d'uso).
2. Guardalo fallire, rendi comprensibile l'errore.
3. Scrivi il codice.
4. Rifattore del codice e del test.

Questo dipende dalle tue abitudini di pensiero e dalla complessità dell'algoritmo.

La penna e la carta offrono una "forma libera" pensando senza che un compilatore urli a ogni personaggio che scrivi.

Alcuni di noi che usano carta e penna, prenditi il tempo necessario per regolare i limiti del loop, provare valori diversi, ecc.

Quindi, immagino che scrivere il codice incoraggi direttamente l'approccio test-first laddove la penna e la carta promuovono un approccio al primo approccio. È chiaro che se l'attività è banale, puoi codificarla al volo (se sei abbastanza esperto) ma gli algoritmi complessi probabilmente necessitano di un approccio di sviluppo diverso.

I diagrammi aiutano in alcuni casi, ma questo richiede che tu abbia familiarità con loro e li abbia già usati prima.

Penso che il tuo sia l'approccio più comune. Se l'algoritmo è particolarmente complesso o difficile, può essere difficile sia capire l'algoritmo che implementarlo contemporaneamente, ma in generale dubito che aiuti la maggior parte delle persone.

Ma non vorrei, per esempio, inventare regole per un grammer e implementare un parser per questo senza scrivere le regole su carta (o magari con qualche strumento speciale che non ho) prima, o implementare un B-Tree senza pseudo-codice disponibile.

Non direi che hai una brutta abitudine a meno che non ti faccia del male, e penso che noteresti se lo fosse.

puoi creare un disegno mentre fai le classi, i metodi e i test di stub ma puoi impantanarti durante la creazione dei dettagli

per le cose veramente complesse (compilatori e simili) un design a penna e carta (o almeno su uno strumento di progettazione di sorta) contribuirà a tenerti in pista e ad osservare l'intera immagine ed evitare cattive scelte di progettazione e persino ti consente di scegliere determinati schemi di progettazione dall'inizio

ma alla fine dipende da quanto puoi continuare a vedere l'immagine grande

Consiglierei di tracciare le indicazioni generali (la fase "penna e carta") prima di passare all'implementazione per risparmiare tempo, eliminando i più ovvi requisiti / vincoli.

Quindi puoi rifinirlo nel modo in cui dato che non puoi mai indovinare tutto all'inizio perché ulteriori contravvenzioni potrebbero / appariranno più avanti nello sviluppo, per vari motivi.

In questo modo sai dove stai andando, ma puoi comunque adattarti ai cambiamenti.

1. La quantità di preparazione necessaria è tipicamente proporzionale alla complessità di ciò che stai facendo. Non ha senso scrivere a penna e carta 2 giorni interi per un algoritmo che viene usato una volta in un quarto, esegue un'ora singlethreaded su una macchina solo. Ha senso scrivere a penna e tre settimane uomo (se necessario) per progettare il nuovo modulo di compensatore di flusso ad alte prestazioni che sarà in grado di elaborare mezzo milione di richieste all'ora e deve funzionare 24/7/365 senza tempi di fermo.

2. Puoi capire se è una cattiva abitudine entro 30 secondi se osservi quali soluzioni stai codificando. Hai chiesto se è una buona o una cattiva abitudine. Bene, questo dipende da te. Se sei uno studente lento all'inizio della tua carriera di programmatore, è probabilmente una buona idea scrivere a penna e su carta tutti i dettagli. Se hai qualche anno di esperienza, basterà pensarci per 5 minuti e poi farlo. Naturalmente ancora rispetto a 1. sopra.

Bottom line

Solo il tuo codice dice al vero se hai bisogno di più o meno penna e carta. Non permettere a nessuno di dettarlo a te, ma scoprilo da solo. Questo ti aiuta ad imparare.

_{Disclaimer: questo potrebbe non essere ciò che viene definito pensiero mainstream e buon senso. Va bene. Basta impostare un segnalibro e leggerlo di nuovo tra cinque anni.}