Consigli o tecniche da usare quando non sai come codificare qualcosa? [chiuso]

Piccoli passi.

Rompere un grosso problema in problemi più piccoli. Quindi risolvi i problemi più piccoli.

Punti bonus se puoi eseguire il backup delle tue soluzioni ai problemi minori con i test automatici delle unità.

Di solito scrivo le cose sulla carta mentre sto riflettendo sulle cose. In questo modo posso scrivere pseudo-codice o fare disegni (di solito entrambi), e non devo preoccuparmi dei limiti del software di disegno o di ciò che può essere contenuto in un commento.

Trovo che se sto facendo qualcosa di almeno leggermente complicato, ho davvero bisogno di mettere le cose per iscritto, altrimenti finisco con qualcosa di hacky, come hai detto tu.

Se finisco con qualcosa di hacky, spesso quasi funziona. A volte posso incidere su di esso fino a quando finalmente funziona, a volte no. Se mi prendo del tempo per lavorare su carta, spesso funziona senza troppi problemi.

Penso che tu abbia risposto alla tua stessa domanda, e non intendo ciò in modo negativo - è un consiglio comune che il modo migliore per imparare a codificare è semplicemente la codifica. Cercherò personalmente di evitare di copiare il codice direttamente da una fonte, a meno che non sia assolutamente chiaro su cosa sta succedendo (vale a dire che non c'è necessariamente un altro buon modo per fare qualcosa), anche se molti di questi tipi di problemi sono sintattici. Prendendo il tempo per capire cosa sta succedendo e come tu (o qualcun altro) stai implementando è più importante.

Nel tempo che ho speso per imparare a sviluppare, ho scoperto che lavorare con le tecnologie MVC è un ottimo modo per capire come progettare, come Rails (con cosa sto lavorando proprio adesso) o iOS / Cocoa Touch. Poiché stai lavorando in un ambiente di progettazione orientato agli oggetti, quando inizi a pensare in termini di modelli e la loro logica separata dalla vista (con i controller che sono la colla che li lega), inizi anche a pensare in termini di come puoi mantenere i tuoi oggetti astratti in modo logico, ma (si spera!) senza complicazioni.

Questo è basato sulle mie esperienze, ovviamente, ma spero che i miei pensieri sulla tua domanda possano essere di aiuto.

Oltre alle risposte già fornite, uno dei modi migliori per iniziare a saltare è imparare da un'applicazione semplice e in cui è disponibile il codice sorgente.

È qui che brillano questi repository sociali come Github. Un posto incredibile da sfogliare per esempi. E quando ne trovi uno, puoi posizionarlo immediatamente come tuo e fare ciò che vuoi per l'applicazione, quindi una volta ottenuto:

• puoi eseguirlo
• modificarlo qua e là e vedere come cambiano le cose
• man mano che ti senti più a tuo agio, apporti modifiche più grandi
• scoprirai presto che stai imparando davvero

Un'altra opzione è quella di utilizzare le classiche implementazioni di riferimento di esempio documentate in così tante diverse posizioni. Ad esempio, il framework Java Spring utilizza il venerabile esempio di "Pet Store". Penso che tu possa persino trovare quell'esempio su Github.

Altri framework / tecnologie come il framework di Groovy's Grail usano altri classici come un'applicazione Book per la permanenza e la visualizzazione di libri e autori, ecc.

L'ultima opzione che ho provato è seguire un buon libro di programmazione e iniziare a digitare gli esempi a mano e inserirli in un repository come Github; questo ha almeno due vantaggi: 1) c'è un riferimento per te con le tue note che ti aiuteranno a ricordare cose interessanti in un modo che ricorderai e 2) se entri in luoghi difficili puoi facilmente ottenere amici o colleghi guarda il tuo codice e ascolta i consigli.

La scienza e in particolare la programmazione sono davvero basate sulle esperienze degli altri. In termini figurativi, copiare / incollare e poi modificare fino a quando non capisci è ciò che aiuta gli sviluppatori a diventare ingegneri.

Immagina di dover fare un rapporto sul tuo problema a qualcun altro.
 Analizza il problema. Cerca di formularlo il più chiaramente possibile. Scrivi pseudocodice, disegna i diagrammi.
 Pensa a cosa potrebbe causare il problema e perché il tuo approccio è sbagliato.
Chiediti se ci sono altre prospettive da cui puoi visualizzare il tuo problema.
 Non limitarti a farlo, mettilo su carta (o un documento sul tuo computer).

Se nessuno di questi ti aiuta immediatamente, cerca di non pensare al problema per un po '. Buona notte di riposo. Ancora nessuna soluzione? Prova a cercare su google il tuo problema o a cercare SO per una soluzione.

Se tutto il resto fallisce, fai una domanda su SO (o SE Programmers se è più appropriato per la tua particolare domanda). Assicurati di includere effettivamente il tuo "rapporto" (o le parti importanti di esso) quando fai la domanda.
Quando ottieni una risposta, chiediti perché il tuo approccio non ha funzionato e cosa potrebbe averti aiutato a trovare la soluzione da solo. Potrebbe aiutarti a trovare una soluzione per alcuni problemi che incontri in futuro e che richiedono un approccio simile.

Sono d'accordo con il pensare sulla carta. Di norma, identifico ogni elemento di informazione di cui ho bisogno e da dove verrà, in primo luogo. Non deve essere elegante, solo accurato. Domande di logica aziendale e strategie di progettazione di solito vengono durante questo processo.

Con ciò, mentre uno sviluppatore java lavora da capo a capo su un'applicazione, divido ulteriormente le cose per livelli: presentazione, web, logica aziendale e livello di accesso ai dati. Quando ho tempo, di solito scrivo i miei nomi di classe durante questa parte.

Infine, cerco sempre di eseguire test per il back-end, prima di scrivere codice. Puoi collegare tutto elegantemente, ma se non riesci a raggiungere il back-end: database o servizio web, ad esempio, non funzionerà!

Alcuni dei principi dello sviluppo basato sui test aiutano molto qui.

Uno dei modi migliori per risolvere problemi complessi è risolverlo per casi d'uso specifici e quindi scoprire una generalizzazione. Usare TDD promuove esattamente questo. Crei un semplice caso di prova e fallo funzionare, quindi crea un altro test case e fallo funzionare. Finalmente vedi se c'è qualche generalizzazione che puoi fare che ti permette di gestire entrambi i casi di test con la stessa logica. Se è possibile, probabilmente gestirà anche molti altri casi di test. Poiché puoi eseguire tutti i casi di test in qualsiasi momento, puoi sentirti libero di migliorare la tua logica senza preoccuparti di rompere qualcosa. In questo modo, una soluzione hacky non deve rimanere hacky.

Lo sviluppo basato su test promuove anche

• suddividere i problemi di grandi dimensioni in quelli più piccoli, in modo che sia più facile ottenere una buona copertura di prova.
• pensa in anticipo a cosa vuoi veramente ottenere prima di impantanarti nei dettagli dell'implementazione.
• evitare l'over-engineering cercando di far passare i test nel modo più semplice possibile, e le soluzioni semplici sono solitamente le migliori.

In realtà c'è un libro che risponde esattamente a questa domanda:

Come progettare programmi - Un'introduzione alla programmazione e all'informatica di Matthias Felleisen, Robert Bruce Findler, Matthew Flatt e Shriram Krishnamurthi

Attualmente stanno lavorando su una seconda edizione , e in seguito, un secondo volume (How progettare componenti).

La cosa davvero interessante di questo libro è che ti offre una serie di ricette per la progettazione di programmi. In altre parole, ti fornisce istruzioni dettagliate che puoi seguire (semi) per seguire un programma.

Oppure, per dirla in un altro modo: contiene una serie di programmi per scrivere programmi, in modo che non devi capire come scrivere un programma: gli autori hanno capito tutto per te!

Oltre alle risposte di cui sopra, a volte non si tratta di conoscere la logica in sé, ma di conoscere la struttura e il linguaggio con cui si lavora. Ogni struttura o linguaggio ha le sue caratteristiche ed è di grande aiuto familiarizzare con questo.