Scrivendo il mio approccio alla risoluzione dei problemi su carta? [chiuso]

Non c'è niente di sbagliato nell'elaborare prima gli algoritmi su carta. Non tanto per la codifica quotidiana, ma per algoritmi più complessi, i programmatori professionisti li elaborano sempre su carta o su una lavagna, soprattutto se un formato grafico lo rende più chiaro. Per uno studente, il programma ogni è complesso.

Se vuoi migliorare la progettazione degli algoritmi su un computer, tuttavia, ci sono alcune tecniche che puoi praticare. Non iniziare solo scrivendo il codice, scrivi le stesse cose che metterei su carta come commenti, quindi espandi il codice in codice reale o commenti più dettagliati uno per uno.

Ad esempio, se sto cancellando un elemento dal centro di un elenco collegato, potrei iniziare con qualcosa del tipo:

// find the element
// point the previous element to the next element
//    How do I get a pointer to the previous element?
//        doubly-linked list?
//        another find?
//        keep track during the first find?
// delete the element

Quindi potrei sostituire // find the element con una funzione con più pseudocodice e continuare fino a quando non avrò una soluzione completa. Non pensare che il codice debba essere scritto in modo lineare.

Vai per questo! Se chiamiamo ciò che stai facendo pensando e progettando la tua soluzione, allora è logico che il tuo processo sia molto più rapido del semplice codice.

Alle persone piace pensare (e ai rumorosi piace dirci) che il loro modo di fare è meglio. Ma la capacità e il mix di abilità di ognuno sono diversi. Quindi fai ciò che funziona per te. Man mano che acquisisci pratica, probabilmente passerai a fare più lavoro di progettazione nella tua testa e utilizzerai la carta per problemi più grandi.

Una cosa da tenere a mente è quale forma prenderanno gli esami. Saranno su carta o saranno basati sul computer? Se sono basati su carta, allora il tuo modo ti darà un vantaggio. Se sono basati su computer, allora va bene anche: fai un disegno su carta, poi scrivi il codice. Qualunque cosa funzioni meglio!

Non penso che ci sia qualcosa di intrinsecamente sbagliato nella stesura del codice (pseudo o altro) sulla carta - non è davvero diverso da scrivere su una lavagna, cosa che molte persone fanno quando discutono su come affrontare un problema.

Scrivete prima le bozze dei saggi per le classi non CS su carta prima di dattilografarli? In effetti, lo facevo anni fa quando ero ancora uno studente universitario, ma dopo il mio primo anno, mi sono obbligato a scrivere tutte le bozze su uno schermo, poiché rendeva la scrittura di bozze successive molto più semplice, e la stessa idea si applica per scrivere codice.

Ti suggerisco di provare a digitare i tuoi algoritmi, anche se è solo in un editor di testo come Word. Più lo fai, più ti sentirai a tuo agio senza fare affidamento su carta e penna. E se le tue abilità di battitura sono un po 'carenti e questo è in realtà la fonte della tua frustrazione, prendi un corso di battitura! Sarebbe la cosa migliore che potresti fare per la tua futura carriera.

Non metto giù il codice reale sulla carta, ma per qualcosa di non banale quasi sempre esco su una lavagna o un quaderno. Di solito abbozzo fuori:

• Algoritmi / processo / flusso di controllo
• Strutture dati
• Rapporti
• Componenti (come posso risolvere questo problema)

Di solito è una combinazione di schizzi, pseudocodice e inglese.

Trovo che, facendo ciò, è più facile visualizzare quando comincio la codifica. Individuerò anche i difetti prima . Mi avvio nel codice perché riesco a vedere tutto davanti a me (invece di scorrere incessante e saltare la finestra). Non solo, una volta scritto, posso lasciare che le cose si formino nella mia mente mentre sto lavorando ad altri compiti. Posso anche lavorare in modo non lineare, dare un'idea alla carta quando mi colpisce e poi tornare indietro quando raggiungo il punto in cui ne ho bisogno.

Comunicare qualcosa alla carta è un enorme aiuto per la conservazione della memoria. La tagline per il taccuini di appunti Field Notes è questa:

I’m not writing it down to remember it later, I’m writing it down to remember it now.

Dopo aver adottato un approccio più focalizzato per scrivere le cose su carta, anche se faccio un ingresso nell'app ToDo sul mio telefono un attimo dopo, trovo che il pensiero è cementato nella mia testa molto meglio che solo rendendo l'elettronica Nota. IOW, pianificando la mia codifica su carta / lavagna, le idee mi stanno meglio nella mente.

Serve anche come utile riferimento quando è il momento di documentare ciò che ho scritto.

Risolvendo il problema e scrivendo il codice che implementa la tua soluzione ci sono due diverse attività.

Se non conosci una lingua, passerai molto tempo sul codice stesso e non abbastanza per trovare una buona soluzione. Se la carta, la lavagna o l'avvio al soffitto ti aiutano in tal senso, allora fallo con tutti i mezzi.

(Personalmente, mi ritrovo a scendere dal computer e girare in tondo cercando di costruire una soluzione nella mia mente)

Farai delle interviste! Ti fanno scrivere codice su carta o sulla lavagna. Sono l'esatto contrario. Cercando di scrivere graffe o tagliare & incollare con una penna è così noioso!

Mio padre ha utilizzato molta carta durante la programmazione di COBOL. Penso che sia solo il tuo modo di pensare.

Avevamo una classe di due semestri chiamata The Basics of Programming. Sia i test di metà semestre che gli esami alla fine sono stati fatti su carta. Se hai fatto degli errori di compilazione hai perso una seria quantità di punti. Se hai fatto enormi errori di compilazione, hai fallito. Tuttavia ritengo che abbia sviluppato l'abilità in noi di dare un'occhiata a qualsiasi codice e trovare linee buggy in un periodo di tempo relativamente più breve.

Non c'è niente di sbagliato in quello che stai facendo, ho imparato a programmare usando anche carta e penna.

Come altri hanno suggerito di fare ciò che funziona per te. Ricordo che il primo programma Java che ho scritto era principalmente su carta e poi ho passato due ore a digitare e quindici minuti a piangere quando ho visto più di 200 errori del compilatore. Ce n'erano di più ma il compilatore mostrerebbe solo i primi 200! Il punto che sto facendo è che scrivendo il codice su carta sono riuscito a pensare attraverso l'algoritmo e la funzionalità di base per ciò che il programma doveva fare. Il compilatore ha sottolineato i motivi per cui il mio programma non sarebbe stato eseguito. Il 90% dei problemi era fuori dalle eccezioni con gli array.

Man mano che acquisisci più esperienza e sicurezza, ti ritroverai a usare carta e penna in meno. Saprai già come utilizzare concetti di base come ad esempio loop e così via. Avrai degli esempi in altri programmi, che potrai riutilizzare. Userai il compilatore e un IDE per trovare bug ovvi durante la scrittura del programma. In questo momento però non hai questa esperienza.

Leggendo la tua domanda mi chiedo se alcuni dei tuoi problemi potrebbero essere dovuti alla messa a fuoco. Se l'uso di carta e penna in un ambiente silenzioso ti aiuta a mettere a fuoco, allora è fantastico.

Sei ancora al college e stai ancora imparando. In definitiva, tutto quello che stai facendo è ciò che funziona per te. Se usando carta e penna stai ordinando i tuoi pensieri e pensieri in modo chiaro e tranquillo, allora stai programmando.

Il mio codice è organizzato molto meglio quando scarabocchia appunti e approcci su un blocco note, controllo libri, controllo sul web e riflessione. Sono anche molto più una persona visiva, quindi disegnare immagini con strutture dati è molto utile. Non scrivo tutte le righe, ma scribble ciò che considero frammenti "importanti" o funzionalità chiave. Per i progetti più grandi accendo Visio. Non sono sicuro del motivo per cui qualcuno sosterrebbe di saltare direttamente su una tastiera a meno che non siano molto più efficienti o pagati a ore.

Fai ciò che funziona per te. Non scriverei codice su carta. Scrivo pseudocodice e disegno diagrammi di flusso su carta, ma scrivere il codice completo mi sembra una perdita di tempo.

Anch'io sto affrontando lo stesso problema nel mio primo giorno di apprendimento delle competenze tecniche.

Ma questo tipo di pratica non dovrebbe dare il 100% di successo perché se scriviamo codice su carta non c'è possibilità di correggere i bug, c'è la possibilità di risolvere gli errori e le eccezioni durante il lavoro su carta.

Quindi il lavoro cartaceo non offre alcuna navigazione per risolvere i problemi. E possiamo ottenere la velocità del tipo come bonus grazie alla pratica del sistema.

I am also doing paper work but when before implementing my functionality just do rough estimation after this I will start My implementation on system.

Prova a dedicare più tempo alla pratica del sistema. Questo darà il 100% di confidenza e risultato.