Non riesco ancora a capire come programmare?


122

Ho letto molti libri per vari linguaggi di programmazione, Java, Python, C, ecc. Capisco e conosco tutte le basi dei linguaggi e comprendo algoritmi e strutture di dati. (Equivalente di due anni di lezioni di informatica)

MA, non riesco ancora a capire come scrivere un programma che fa qualcosa di utile.

Tutti i libri di programmazione mostrano come scrivere la lingua, ma NON come usarla! Gli esempi di programmazione sono tutti molto basilari, come costruire un catalogo di carte per una libreria o un gioco semplice o usare algoritmi, ecc. Non ti mostrano come sviluppare programmi complessi che effettivamente fanno qualcosa di utile!

Ho esaminato i programmi open source su SourceForge , ma per me non hanno molto senso. Esistono centinaia di file in ciascun programma e migliaia di righe di codice. Ma come posso imparare come farlo? Non c'è niente in nessun libro che posso comprare su Amazon che mi dia gli strumenti per scrivere uno di questi programmi.

Come si passa dalla lettura di Introduzione a Java o alla programmazione in Python o al linguaggio di programmazione C, ecc., Per poter effettivamente dire che ho un'idea per il programma X? È così che lo sviluppo?

Sembra che ci sia molto di più nello scrivere un programma di quanto tu possa imparare in un libro o da una lezione. Sento che c'è qualcosa.

Come posso essere messo sulla strada giusta?


52
Alcune persone non sono pensate per programmare. Solo tu puoi rispondere se un percorso alternativo ti risolverebbe o se è il momento di provare qualcos'altro. È improbabile che tu ottenga una risposta che sarà utile qui.
Duffymo,

3
Cosa considereresti "utile"?

7
@Michael - Io, per esempio, ho votato Off-Topic, passo a P.SE. Ho pensato che sarebbe stato un posto più appropriato per una discussione sulla programmazione come carriera e mestiere.

12
@duffymo: E alcune persone non hanno lo scopo di commentare le domande.
davidk01,

4
Penso che stai facendo solo salti troppo lunghi. Passare dagli esempi di libri ai progetti completi di Sourceforge è vasto e scoraggiante. Invece, prova ad estendere ciò che hai già creato. Aggiungi funzionalità, aggiungi GUI, aggiungi funzionalità di rete; e molto presto, immagino che avrai il tuo progetto su Sourceforge.
gablin,

Risposte:


93

Costruire programmi più complessi arriva con l'esperienza. Quando ho programmato per la prima volta pensavo di fare bene se fosse lungo più di 25 righe (e dovevo usare la barra di scorrimento) Ora scrivo centinaia di righe al giorno per anni sulla stessa applicazione di progetto.

Potresti trovare questa pagina interessante "Insegnati a programmare in dieci anni" http://norvig.com/21-days.html

A proposito: è molto difficile avviare un programma. Uno scrittore potrebbe chiamarlo "blocco degli scrittori". Invece ti suggerisco di iniziare a scrivere codice e migliorarlo. Non abbiate paura di eliminare grandi sezioni che non fanno ciò di cui avete bisogno. Ricomincia, questa volta scriverai con un'idea migliore di ciò che stai facendo. Ricomincia e scoprirai che non hai bisogno della metà delle cose che hai scritto l'ultima volta. Quando un autore scrive una storia, ci vuole molto tempo, molta scrittura e riscrittura, ecc. Molte recensioni e feedback ed è finito solo quando deve essere pubblicato (rilasciato)


13
+1 Per quello che ha detto Bill e per aver discusso del "blocco dello scrittore".
David Weiser,

Accidenti, lo faccio da alcuni anni (10 + -2) e ogni tanto scrivo ancora un po 'di codice e finisco per cancellarlo. Ho avuto alcuni "refactor" su cui ho lavorato per alcuni giorni e annullato (tramite il controllo del codice sorgente) perché ero un ritardante (per essere schietto).
Ken Henderson il

5
+1 per l'analogia con la scrittura di una storia. I miei programmi sono ancora nella fase "C'era una volta ...".
Andy,

4
Una delle cose più spaventose della programmazione è un documento vuoto. Una volta superato questo ostacolo, hai fatto buoni progressi.
gablin,

1
il blocco dello scrittore. l'hai inchiodato lì!
abel

70

Sono sempre stato travolto anche da progetti molto grandi, come quelli che trovi su SourceForge o GitHub. Mi chiedevo come chiunque, o anche un team, potesse capire cosa stava succedendo tra 10 o 100 di file, con migliaia e migliaia di righe di codice.

Nessuno lo fa. Almeno inizialmente.

I progetti sono cose organiche. Ciò che inizia come un'idea davvero semplice, può espandersi rapidamente in un enorme lavoro. Questo è, credo, il motivo principale dello sviluppo iterativo invece del classico approccio a cascata.

Pensa a costruire un'auto. Mentre sembra abbastanza semplice dall'esterno, approfondendo anche un piccolo modo in te scopri che ci sono un numero enorme di considerazioni, compromessi e casi innocenti che devono essere gestiti.

Esempio:

Nel caso di un progetto semi-grande, spesso inizia in piccolo. "Voglio costruire un server cache". Quindi trascorri qualche giorno a fare a pezzi e arrivi a qualcosa che funziona, ma che potrebbe essere migliorato notevolmente. Quindi aggiungi il concetto di threading.

Quindi si verificano problemi di concorrenza dovuti a tale thread. Quindi risolvi modificando le strutture di dati simultanee.

Ora il processo è rallentato. Quindi si modificano le strutture di dati simultanee in quelle normali, ma si forniscono meccanismi di blocco per la sincronizzazione.

Sembra che tutto funzioni correttamente, tranne per il fatto che gli utenti iniziano a lamentarsi del fatto che le operazioni non sono atomiche e che i dati vengono danneggiati.

Quindi aggiungi alcune classiche operazioni atomiche, come l'incremento e il salvataggio. Funziona e i tuoi utenti sono felici. Ma qualcuno apre un ticket chiedendo se è possibile fare operazioni di lista.

Quindi trascorri una settimana o due a costruire quella caratteristica. A questo punto, un amico decide di aiutarti. Ci lavori insieme, lo completi e lo rilasci.

Due biglietti aperti. C'è un bug nell'elaborazione dell'elenco e ci sono alcuni rari casi che sono deadlock.

Il tuo amico lavora sul bug di elaborazione dell'elenco, mentre affronti il ​​deadlock. Ti rendi conto che deve avvenire una riscrittura abbastanza significativa per le operazioni atomiche.

... e così via.

Questo sembra abbastanza tipico di come cresce un progetto. Circa 10 file sono appena cresciuti a 20 in un paio di settimane. Sono state aggiunte nuove funzionalità che non erano parte del piano originale. Aggiunte correzioni di bug contorte che aumentano in modo innaturale il codice.

Il mio consiglio:

Non lasciarti sopraffare. Se hai un'idea, implementa funzionalità. Se vale la pena proseguire dopo, aggiungi poco a poco. Lascia che il tuo progetto cresca in modo naturale.


Sì, è quasi come se provenisse dall'esperienza personale ...
NickAldwin il

@Nick, non abbiamo avuto tutti un'esperienza simile con il progetto "X" con le caratteristiche "Y" e "Z"? Ho avuto due progetti simili nell'ultimo anno. Nessuno dei due era Redis = P
Josh Smeaton il

Questo descrive quasi tutti i programmi che ho scritto.
Tim Post

Così è andata. Kurt Vonnegut incontra la programmazione informatica
Zoot il

1
Ottimo esempio, ma se fosse potuto iniziare un po 'più piccolo sarebbe stato ancora meglio. Ad esempio, iniziando con la creazione di alcune strutture di dati, quindi un codice che fornisce un'API per queste strutture di dati, quindi un codice che utilizza questa API per implementare la funzione cache e infine una GUI. Voilá, hai scritto un server cache!
gablin,

28

Anche il più grande programma inizia con un'idea e viene scritto una riga alla volta.

Il modo migliore (forse l'unico) per imparare a scrivere programmi del mondo reale è iniziare a farlo. Quando si verificano problemi, si cerca nel Web o si chiedono qui soluzioni a tali problemi. Alla fine, acquisirai esperienza e dovrai chiedere meno spesso.

Tuttavia, ci sono alcune cose di cui dovresti essere consapevole fin dall'inizio:

  • Oggigiorno quasi nessuna grande applicazione è completamente scritta da zero. Puoi fare molto di più in un tempo molto più breve se usi librerie e framework di alta qualità esistenti. Iniziare con questi spesso sembra abbastanza frustrante e richiede più lavoro che farlo da soli, ma non è quasi mai vero.
  • Pensare attentamente a come strutturare il programma (come progettarlo) è molto importante quando i programmi diventano più grandi. Dedica un po 'di tempo a questo, e leggi alcuni libri sul design (in particolare consiglierei "Clean Code") e sull'ingegneria del software e sulle basi tecniche.

6
"Il modo migliore (forse l'unico) per imparare a scrivere programmi del mondo reale è iniziare a farlo." Più o meno quello che sto per dire. Puoi solo leggere e "capire le basi" così tanto ... la gomma deve colpire la strada da qualche parte.
WernerCD,

1
+1 per la riga "Inizia a farlo". Non puoi imparare l'esperienza da un libro.
riwalk

+1 per menzionare il libro "Codice pulito". Dovresti sempre rendere il tuo codice leggibile. Facile da leggere == facile da capire == facile da modificare
Igor Popov

15

Quello di cui stai parlando è più ingegneria del software che programmazione. È un po 'di architettura, un po' di "buone pratiche" e "modelli di progettazione", un po 'di lavoro con gli altri. Mentre ci sono libri che possono aiutare, la maggior parte proviene dall'esperienza. Nessuno inizia a scrivere, diciamo, Microsoft Word.

Pensa a un grande programma "reale" che vorresti scrivere. Ora pensa ai vari pezzi che devi costruire per farlo funzionare come desideri. Ad esempio, in un moderno gioco in prima persona avrai bisogno di un motore grafico 3D, AI non di carattere giocatore, un modulo audio / musicale, un motore fisico e un modulo di livello superiore che applica le regole del gioco (sa la "mappa", come interagiscono i vari personaggi, ecc.). E poi c'è la grafica, il design dei personaggi e la musica, nessuno dei quali è un codice ma che è necessario per completare il gioco.

Ora: quale di questi ti costruirai e quale andrai altrove? La maggior parte dei progetti software di grandi dimensioni non è programmata da zero. Forse utilizzerai un motore 3D standard e un modulo musica / suono e programmerai solo le cose che rendono unico il tuo gioco. OK, quindi devi capire quali moduli di terze parti utilizzerai, che coinvolgeranno fattori come il costo, con quali lingue lavorano, con quali caratteristiche hanno, come sono progettate le loro API (ovvero, come completarle è, come si adatta al tuo stile di programmazione personale, ecc.). Magari scriverai "prove di concetto" o testerai programmi usando uno o due candidati per i vari moduli di terze parti per assicurarti che facciano tutto ciò di cui hai bisogno e che siano facili da usare.

Inoltre, anche il codice che vuoi scrivere da solo potrebbe essere un lavoro troppo grande per te da solo da completare nell'intervallo di tempo che hai in mente. Di quanti altri programmatori hai bisogno per lavorare al progetto? Come suddividerai il lavoro? Come saranno progettati i vari moduli in modo che si adattino tutti insieme anche se sono stati scritti da persone diverse? Come lavorerete tutti sullo stesso codice sorgente senza cancellare le reciproche modifiche (risposta: controllo di versione, che è estremamente utile quando lavori da solo ma indispensabile quando lavori con altri).

Dopo aver capito quali moduli vuoi scrivere internamente, esegui lo stesso processo. Capisci i pezzi di ciascun modulo, come dovrebbero combaciare, e quale ti scriverai e quale andrai altrove. Continua a scomporre le cose fino a quando ogni pezzo non è abbastanza piccolo da tenerlo in mente, così da poter dire "sì, potrei scriverlo!" E poi fallo. Mentre lo fai, incontrerai ostacoli imprevisti nel modo in cui i vari pezzi del tuo programma si incastrano. Questi saranno frustranti, ma sono opportunità per te per saperne di più sul tuo mestiere e dovrebbero essere visti in questo modo.

Inizialmente, sarai in grado di contenere solo piccoli pezzi del tuo programma - diciamo, singole funzioni - nella tua mente, e quindi dovrai scomporre molto le cose prima di iniziare a scrivere codice. Come si acquisiscono esperienza, si pensa a funzioni piuttosto che dover pensare su funzioni e cominciare a pensare su oggetti. E poi penserai agli oggetti e penserai a moduli più grandi. Infine, penserai in moduli e penserai a programmi interi, grandi e reali.

E poi scoprirai che hai ancora molto da imparare ... ma così va. Se, come programmatore, smetti mai di imparare, sei obsoleto e verrai sostituito con un modello più recente.

Comunque, non aver paura e non preoccuparti se questo suona ... terribile o impossibile e dopo tutto non vuoi davvero essere un programmatore. Non è per tutti. Amo la musica e i dessert e so suonare un po 'le chiavi e cucinare alcuni piatti, ma non sono disposto a dedicare il tempo necessario per diventare un grande musicista o un grande chef.

Se risulta che non vuoi essere un programmatore che scrive applicazioni desktop grandi e reali, esistono altri tipi di lavori di programmazione. Ad esempio, potresti diventare un programmatore incorporato. Ci sono sfide definite e interessanti coinvolte nella scrittura di programmi integrati e stai facendo un lavoro utile, ma in genere i programmi sono piuttosto più piccoli delle applicazioni desktop. Oppure potresti scrivere applicazioni web. Sul Web, è facile incollare insieme un po 'di funzionalità, in modo da poter scrivere (ad esempio) un sistema di commenti Web e sarebbe utile anche se non è un'intera applicazione Web. È facile migliorare in modo incrementale anche le cose sul Web, quindi puoi iniziare con (diciamo) un client di posta Web di base e, nel tempo, evolverlo in qualcosa come Gmail. (Ma non farlo, perché allora competerai con Gmail.)

Se non vuoi assolutamente essere un programmatore, ma vuoi comunque lavorare con i computer, potresti andare nel settore IT o in qualche altro campo tecnico. In questi casi, conoscere tutta la programmazione che già fai è molto utile, perché i tuoi colleghi potrebbero non avere nemmeno così tanto. O, sai, diventa un musicista se questo piace, perché (come la maggior parte dei campi) coinvolge i computer oggi. Scrivi piccoli programmi che manipolano i file audio o MIDI in vari modi intelligenti, rendendoti così un musicista migliore. Scoprirai che qualsiasi abilità di programmazione possiedi può essere applicata in molti campi per renderti migliore nel tuo lavoro.


Non sono d'accordo sul fatto che i programmi integrati siano in genere più piccoli delle app desktop. Potrebbe essere stato così in passato, ma ho lavorato su alcuni prodotti embedded che hanno richiesto oltre 100 anni-uomo di sviluppo e questi non sono stati considerati particolarmente grandi.
Bart van Ingen Schenau,

1
Immagino che dipenda da cosa intendi per "incorporato". Se intendi qualcosa come smartphone o sistemi automobilistici integrati, posso credere ai tuoi 100 anni-uomo. Ci sono comunque molti sistemi più piccoli su cui lavorare in quello spazio.
kindall

+1 per iniziare a pensare a cose più piccole, per poi passare a pensare nelle stesse cose e a cose più grandi.
gablin,

1
Qual è il danno nel competere con GMail? Se qualcosa che hai scritto da solo può davvero competere con qualcosa che Google ha rilasciato, puoi considerarti un dannatamente bravo programmatore.
gablin,

Il motivo principale è che ritengo che GMail abbia risolto la posta Web. La maggior parte dei programmatori non trova molto interessante lavorare su problemi che sono già stati risolti (e risolti bene) da altri. Probabilmente puoi trovare un problema che non è stato ancora risolto e divertirti molto di più - e potenzialmente portarlo sul mercato senza dover competere con un gorilla da 800 libbre.
kindall

9

Non capirai come programmare a meno che tu non debba affrontare un vero compito. Nessuna teoria avrebbe mai sostituito un semplice compito nel mondo reale. Prima di iniziare a lavorare su scenari rw, stavo leggendo ingenuamente molti libri, con tutti gli esempi, ma quando ho affrontato un problema reale, non sono riuscito a raccogliere tutte le mie conoscenze teoriche per completare l'attività. Se sei un principiante, ti consiglierei di ottenere le attività ovunque tu sia. Non pensare che siano inutili se non li hai risolti. Come primo passo, prova a risolvere i problemi della struttura dei dati, come ordinare un elenco collegato, eseguire DFS, BFS su alberi, grafici, ecc. Non solo migliorerà le tue capacità di codifica, ma ciò che è più importante, migliorerà le tue capacità analitiche e di algo , che mi fido di me è una conoscenza preziosa. Quindi, quando saprai che puoi oscillare con puntatori, ricorsione,

Linea di fondo. Si tratta di pratica. Continua a scavare e codice, codice, codice.


7

Inizia con i giochi per computer, come hanno fatto tutti gli altri. Un buon gioco è sia una sfida di programmazione che di progettazione, richiede un'attenta riflessione sulla struttura interna e utilizza le librerie di sistema in modi che insegnano molto, ma non tendono a rompere le cose e non richiedono una "buona ragione con un buon risultato" come fa il vero software "utile".

La regola generale è che dopo aver scritto abbastanza cose, accadrà inevitabilmente una sorta di illuminazione.

Un buon punto di partenza (se hai voglia di C) è http://gamedev.net/ , in particolare http://nehe.gamedev.net/ . Ci sono anche molti altri punti positivi per iniziare: D


4
(Oh, e ho appena capito perché tutti iniziano con i giochi. Le cose belle e brillanti sono motivanti.)

10
tutti quanti ? Affermazione audace.

4
Non ho iniziato con un gioco. Lo troverei oltre il complesso = P
Josh Smeaton il

4
La maggior parte delle persone in questi giorni inizia con una webapp, barriera molto più bassa all'ingresso (è solo testo).
slebetman,

4
Il tuo primo commento è stato probabilmente migliore della tua risposta - le cose brillanti e carine sono motivanti . Questo è ciò che conta.
Scorchio il

6

Stai guardando l'intero programma enorme e sembra impossibile. Ma il tutto è composto da piccoli stupidi programmi come quelli che stai dicendo "non fare nulla di utile".

Ciò di cui hai bisogno è l'esperienza di scomporre enormi compiti complessi in piccoli compiti semplici. Questa è la radice di tutta la programmazione. Il resto è solo semantica.


6

Proprio come guidare o cucinare, la programmazione è qualcosa che impari a fare facendo. La pratica è insostituibile.

Se gli esempi di libri di testo sono già troppo semplici per te, è fantastico! È ora di muoversi per qualcosa di più complesso - e già puoi capire alcuni esercizi stimolanti per te stesso.

Oppure, se hai in mente un'idea specifica, spezzala a pezzi. Risolvi prima un piccolo sottoinsieme del problema. Quindi espandere. Quando l'integrazione del nuovo codice con il codice esistente diventa difficile, riprogetti tutto.


5

Scrivi uno script di 200 righe. Quindi inizia a migliorarlo.

Featuritis ti porterà a 100 file sorgente e diverse centinaia di KLOC in pochissimo tempo :)


5

"Non ti mostrano come sviluppare programmi complessi che effettivamente fanno qualcosa di utile!"

Senza una definizione di "utile" non c'è davvero molto che possiamo fare per portarti sulla strada "giusta".

Non sappiamo come stai fallendo o cosa non va. Non possiamo dire su quale traccia stai seguendo.

In qualche modo, hai in testa l'idea che non stai comunicando.

Il software, ovvero la programmazione, si basa su come ottenere un'idea in qualche lingua (Python, Java, inglese, qualunque cosa).

Un passo importante nella programmazione (e nel porre domande) è definire i termini. Cosa intendi con "fai qualcosa di utile"? Sii molto chiaro, molto completo e molto preciso.


Votato, sono davvero interessato alla risposta di OP in questo argomento.
Scorchio,

5

Mi viene sempre fatta questa domanda, ad es. Come iniziare. È davvero semplice. Ecco un passo dopo passo.

  1. Fatti venire un'idea. Sembra che tu l'abbia già fatto.
  2. Semplifica la tua idea al suo nucleo di base - qualcosa che pensi di poter affrontare
  3. Layout dell'interfaccia utente su un pezzo di carta o tovagliolo, qualunque cosa.
  4. Prova a strutturare l'interfaccia utente nel tuo ambiente di sviluppo.
  5. Se riscontri difficoltà, google, google, google, poni domande su StackOverflow, usa le strane risorse di Internet per ottenere aiuto. Chiedi ad amici e colleghi programmatori di aiutarti in situazioni specifiche. Torna al passaggio 4.
  6. Inizia a scrivere la logica della tua applicazione. In caso di difficoltà, andare al passaggio precedente e riprovare.
  7. Presto, presto avrai qualcosa che funziona.

+1 per il flusso di lavoro - dovrebbe funzionare in qualche modo. Non so dire quanto sia importante il secondo passo. Forse è questo il passaggio che deciderà se è possibile gestire l'attività o meno.
Scorchio il

"Sembra che tu l'abbia già fatto." Lo contesterei. Se ci fosse un'idea, sarebbe parte della domanda.
S.Lott

In realtà, imho, dovresti iniziare a scrivere la logica per l'app, quindi aggiungere l'interfaccia utente ad essa. È più semplice
CaffGeek,

Se riesci a pensare a uno strumento / applicazione che useresti sarebbe ancora meglio. Buttare via i progetti può essere de-motivante. Qualunque cosa sia, inizia in piccolo e costruisci da lì. Vorrei suggerire uno strumento da riga di comando.
Carlosfocker,

1
@ Non ero d'accordo con te. Per i noob, la logica è astratta, ma l'interfaccia utente è facile da capire. Il contrario arriva con esperienza.
AngryHacker il

4

Crea qualcosa di piccolo. Non importa, il tuo programma sarà il 1000 ° a farlo.

Qualche idea:

  • un orologio (prima digitale, poi analogico),
  • creatore automatico di labirinto,
  • visualizzatore della struttura di directory,
  • listener di album mp3,
  • eccetera.

Scegliendo la piattaforma, gli strumenti sono la parte dell'attività.


In realtà sarei d'accordo con te in linea di principio. Tuttavia, l'OP chiede informazioni su software utile. Un listener di album mp3 sarebbe una buona scelta. Un lettore mp3 di base sarebbe meglio, dato che avrebbe avuto le difficoltà di un progetto. Compreso LOC.
Josh Smeaton,

@Josh, la decodifica mp3 non è banale per avere ragione per un programmatore principiante.

@Thor, assolutamente non è banale. Ma sarebbe utile e insegnerebbe molto rapidamente come i programmi possono diventare così grandi. Tutte le sfumature, correzioni di bug, casi limite. Potrebbe non essere appropriato in questo caso particolare, ma potrebbe essere appropriato in generale. Essere in grado di usare te stesso, un software che hai scritto è una cosa grandiosa.
Josh Smeaton,

@Josh, non penso ancora che un decoder MP3 sia roba piccola e adatta a questo scopo.

3

Ok iniziamo con la tua idea per il programma X che fa qualcosa di utile e scomponiamo:

  • Utilizzare software cartacei, di mappatura mentale o diagrammi per disporre il flusso / i flussi logici del programma.

  • Dato che hai appena iniziato, scegli UNO di quegli elementi (preferibilmente vicino all'inizio) e scomponi ulteriormente.

  • Scrivi prima il codice per quello e usalo per costruire

Il programma X deve aprire un file, manipolarlo e creare un file di output? Verifica se riesci ad aprire ed eseguire l'eco del file come primo passo. Vuoi una bella interfaccia utente? Creane uno in grado di eseguire il tuo programma di eco file, ecc. Non solo costruirai passo dopo passo il codice che puoi utilizzare nel tuo programma complesso, ma costruirai anche le tue conoscenze linguistiche mentre devi cercare e cercare informazioni.

Come dice il proverbio - Gnome non è stato costruito in un giorno :-)


3

(Risposte già sopra nei commenti. È stato suggerito di inviarlo come risposta dopo la riapertura della domanda.)

Inizi con un problema - qualcosa che vuoi risolvere - non importa quanto pensi che sia complesso. Quindi prendi questo problema e lo scrivi e inizi a romperlo in problemi più piccoli. Quindi abbatti quei piccoli problemi, ecc. Fino a quando non hai qualcosa di primitivo che sai già come risolvere o che puoi fare con qualche sforzo. Inizi a codificare ciascuno di questi pezzi e li organizzi in diverse funzioni o classi diverse, ecc.

Quindi lavori al prossimo sotto-problema. Mentre stai lavorando su ogni problema, puoi scrivere piccoli casi di test e vedere effettivamente i tuoi progressi diventare realtà. Ci saranno sempre sfide lungo la strada, ma in nessun momento lo vedremo come qualcosa di troppo colossale per persino avvicinarsi (ciò che sembra avere a che fare ora). Questo è vero per la programmazione e molte delle sfide della vita. La chiave è romperlo.

Per quanto riguarda cosa fare - l'idea. Puoi provare a inventare qualcosa di nuovo, ma puoi anche prendere qualcosa per cui potresti avere una passione ed esiste già, ma renderlo migliore o addirittura solo diverso. Attualmente sto scrivendo un'app per l'accordatore di chitarra per Android nel mio tempo libero. So che esistono già molte altre app per l'accordatore di chitarre, ma ho pensato che sarebbe stato un progetto divertente e stimolante, quindi l'ho accettato. All'inizio mi è sembrato quasi impossibile, ma dopo aver rotto il problema in passaggi più piccoli, in realtà si sta unendo bene. Dividi e conquista ed essere persistente con i tuoi obiettivi.


3

Una delle cose più difficili da fare quando sei un principiante è stabilire obiettivi realistici per ciò che un esercizio "come posso migliorare" dovrebbe contenere al tuo livello attuale.

Quindi suggerirei di scegliere di esercitarsi a risolvere piccoli esercizi dati, perché la capacità di finire un programma secondo una determinata specifica è una cosa molto preziosa per tutti coloro che programmano per vivere.

Ti suggerirei di dare un'occhiata più da vicino a http://projecteuler.net/ che ha molti esercizi e un sistema automatico di "verifica risposta", che ti consente di lavorare al tuo ritmo. Gli esercizi sono ben formulati, ma possono richiedere di pensare. Alcuni potrebbero anche richiedere di pensare molto, ma anche non riuscire a risolverli, ti insegnerà qualcosa di utile.

La formulazione completa del problema 1 è:

Se elenchiamo tutti i numeri naturali al di sotto di 10 che sono multipli di 3 o 5, otteniamo 3, 5, 6 e 9. La somma di questi multipli è 23.

Trova la somma di tutti i multipli di 3 o 5 al di sotto di 1000.

Pensi di poterlo risolvere? Allora fallo!


3

Hai bisogno di esperienza nel mondo reale !! . Nessun libro può insegnartelo!

Devi imparare a leggere il codice degli altri, come mantenerlo, come odiarli (sia il codice che il programmatore) come migliorarlo, come pensare di poterlo fare meglio e qualche mese dopo urlare ad alta voce io ' Ucciderò chi ha mai scritto questo codice !!! Solo per scoprire nel controllo della versione sorgente sei stato tu!

Devi capire che i libri sono molto specifici e alcune volte per le persone che già sanno come sviluppare software.

Quindi ti suggerirei di trovare un lavoro di programmazione. Se necessario, richiedere il livello base più elementare. Probabilmente non guadagnerai quanto pensi di meritare, ma utilizzerai alcuni mesi per imparare come si sviluppa il software nel mondo reale (e non è sempre così perfetto e con tutte quelle belle best practice che leggiamo nel web , molte volte, la qualità del codice è molto bassa, a seconda di dove lavori, ma fa parte dell'esperienza)

Continua a leggere i tuoi libri, lo scoprirai, ogni anno capisci un po 'di più (o in modo diverso) lo stesso argomento, perché puoi vederlo sapere con il bicchiere dell'esperienza.

Se riesci a trovare un lavoro con sviluppatori di talento, molto meglio. Impara da loro, non aver paura di sbagliare.

Fino a quando non dovrai correggere il tuo primo bug urgente di produzione live, non saprai quale bug software è!

:)


2

Prova un progetto open source, vedi se riesci a inserirti. Inizia scaricando il sorgente e vedi se riesci a ritirare alcuni biglietti


15
I programmatori inesperti non dovrebbero provare ad aderire a un progetto open source; ti metterai semplicemente in mezzo. I progetti open source non sono lì per tutor i principianti.

Un'alternativa per essere direttamente coinvolti è di rovesciare la fonte di un progetto e provare a sistemare i biglietti sul proprio ramo e semplicemente lasciarlo a quello. I valori della lettura del codice scritto e rivisto da più persone, le strutture di progetto che sono ben organizzate e possono servire da modelli per le tue creazioni e capire come funziona il processo di collaborazione sono numerosi. Basta osservare le parti pubbliche e confondere il codice privatamente.
jellyfishtree,

3
@jellyfishtree, se non puoi programmare questo potrebbe essere un po 'troppo ambizioso.

@Thorbjorn sicuramente, ma è qualcosa che vorrei fare di più rispetto a quando ho iniziato. Come in ogni altra cosa, penso che tu impari molto solo per osmosi e prima immergendoti in testa. Come minimo otterrai una misura migliore di ciò che là fuori che non conosci / capisci - qualcosa di molto più prezioso quando inizi e desideri ardentemente sapere dove fissare i tuoi obiettivi e su cosa lavorare.
jellyfishtree il

@jellyfish, certo, e sono certo che sia un buon passo da fare, ma non ancora in questo caso.

2

Quando voglio imparare una nuova lingua, di solito cerco di implementare un grafico frattale. In questo modo avrai un feedback immediato su se funziona ed è molto gratificante. E ci sono molti modi per migliorare un frattale. L'implementazione ingenua di mandelbrot è lenta da morire.

Non è molto utile, ma impari molto ed è bello da guardare.


Mi piace questo - un modo abbastanza poetico per imparare una nuova lingua. Ma non so se dovremmo raccomandarlo per un principiante: D
Scorchio il

2

La programmazione riguarda la risoluzione dei problemi e la comunicazione, non la scrittura di molto codice. Il codice è solo una necessità, di solito dovresti provare a scrivere meno codice, non di più.

Se non sai da dove cominciare, forse non hai problemi!

Guarda Linux e altri sistemi simili a Unix: sono tutti costituiti da molte piccole applicazioni che fanno solo una cosa, ma lo fanno bene .

Quando avevo bisogno di uno script per trovare 10 file più grandi in una cartella sul mio computer, non stavo leggendo libri. Ho appena cercato su google e usato una delle soluzioni esistenti. Ho scritto qualche codice? - No. Il problema è stato risolto? - Sì. Questo programma su una riga è utile? - Diamine si.

I programmi con migliaia di righe di codice sono generalmente scritti da più di un programmatore. Non sarai in grado di scrivere interi sistemi operativi da solo e non è necessario. Spesso usano anche cheat come il controllo di versione e test unitari .


Si prega di non menzionare il controllo della versione e il test dell'unità come "cheat". Fare una copia di backup del proprio lavoro e lavorarci è una necessità. Il controllo della versione aiuta a mantenerlo sano di mente. Lo stesso per i test unitari: tutti coloro che hanno scritto una singola riga di codice sanno che alcuni test devono essere eseguiti, perché non tenerlo organizzato?
Scorchio il

@Scorchio Intendevo solo dire che l'uso del controllo versione e dei test unitari ti dà un vantaggio rispetto alle persone che non li usano (abbastanza). Soprattutto quando si tratta di grandi progetti.
kolobos,


2

Quando ho iniziato a programmare, adoravo i giochi per computer. Così ho iniziato a scrivere i miei giochi, non appena avevo gli strumenti a portata di mano per farlo.

Abbastanza naturalmente, il mio primo gioco è stato un'avventura testuale. Allo stesso modo, potresti iniziare con un quiz o qualcosa del genere, o una sorta di ipotesi di giochi.

Inoltre, potresti iniziare con qualcosa, come una slot machine (non hai davvero bisogno delle animazioni, o persino delle immagini. Usa semplicemente A = mela, L = limone, S = inizio, P = Prugna ecc.).

Questo ti insegnerà le basi della gestione di alcuni input dell'utente, il mantenimento dello stato del gioco e la generazione dell'output di conseguenza.

Ho seguito questa strada abbastanza lontano. Ho imparato progressivamente, come leggere lo stato della tastiera, o il mouse, come usare il codice grafico. Ho imparato di più sulla lingua stessa (ho iniziato con PASCAL) e l'ho usato per migliorare i miei giochi esistenti o ho appena iniziato qualcosa di nuovo.

Penso che i giochi siano davvero fantastici per imparare a programmare. Anche con poca esperienza, puoi creare piccole cose che ti regalano piccoli momenti di orgoglio. Perché crei qualcosa, è divertente. Costruire applicazioni reali è abbastanza inutile, perché ci vuole molto lavoro per creare qualcosa, che è effettivamente utile, mentre è sorprendentemente semplice creare un piccolo gioco, che risulta avvincente.

Potresti voler effettivamente usare un linguaggio educativo (nel mio caso, questo era PASCAL e in retrospettiva, penso che si sia rivelata una buona scelta). Molti di loro sono specificamente finalizzati alla creazione di giochi e simili.

Creare applicazioni non è solo creare algoritmi. Devi progettare funzionalità, devi organizzare e strutturare il tuo codice in diversi livelli e moduli. A differenza dei problemi piuttosto "atomici" che ti vengono dati all'università, le applicazioni a volte sono meglio sviluppate in modo incrementale. Inizi con qualcosa e aggiungi delle cose sopra. Quindi, avendo già qualcosa con cui iniziare (come faresti in alcune delle lingue elencate nell'articolo di Wikipedia), ti risparmi molta frustrazione e inizi a creare qualcosa immediatamente. (Un mio collega ha iniziato a programmare scrivendo mod di Quake 2). Ad un certo punto, arriverai a trovare i limiti di questi strumenti di facile utilizzo, ma fino ad allora avrai una visione e una comprensione molto più approfondite. Probabilmente abbastanza,


2

Al college, c'era una classe chiamata Practicum di programmazione che sostanzialmente insegnava questa rampa. All'inizio ti è stata data un'interfaccia utente per un'applicazione di shopping di base e hai dovuto codificare il backend, l'ultimo mese è stato Tetris da zero. Penso che circa il 50% dei nuovi studenti (non riprendere la lezione) abbia fallito, perché passare da piccoli a grandi è incredibilmente difficile.

Suggerirei uno o più dei seguenti:

  • Scarica un progetto open source e aggiungi qualcosa. Non deve essere utile o buono, ma dovrai guardare la struttura, che ti darà un'idea di quanto è costruito il grande progetto.

  • Progetta il tuo progetto finale su carta, con le frecce per le dipendenze. Se stai realizzando un serpente, potresti avere una testa di serpente, una coda di serpente, cibo, spazio vuoto, muro, tavola, direzione corrente, ecc. Potrebbe aiutarti a capire se il tuo progetto è molto più grande di quanto pensi.

  • Prendi un progetto di base e rendilo sempre più grande. Probabilmente farai molto refactoring e spero che imparerai come realizzare progetti più piccoli a cui è possibile aggiungere facilmente.

  • Se conosci qualcuno che ha esperienza, digli la tua idea per un progetto e chiedi loro di scrivere le tue lezioni + alcuni metodi importanti, probabilmente impiegherebbe circa un'ora. In questo modo puoi semplicemente compilare i metodi e sapere sempre cosa devi fare dopo.

Infine, qualunque cosa tu faccia, probabilmente dovresti usare un modello di progettazione MVC di base (Modello, Vista, Controller). Senza entrare nei dettagli, inserisci la tua vista (UI) in 1+ classi, il tuo controller (Input, output, ecc.) In 1+ classi e il tuo Modello (Logica, Dati, praticamente tutto il resto) in diverse classi. È un modo semplice per ottenere un'organizzazione di base.

Ricorda, questo passaggio è difficile. È vero che alcune persone semplicemente non possono programmare, ma probabilmente sei solo bloccato in questa fase. In bocca al lupo!


2

In primo luogo, stai già facendo i prerequisiti prendendo lezioni, leggendo materiale di riferimento, guardando progetti open source e rimanendo curioso con le domande. Lo sottolineo perché ho incontrato personalmente domande simili prima che la persona avesse fatto qualsiasi lavoro di gamba da parte sua (in particolare, gli individui che eludevano le lezioni e speravano di prendere scorciatoie). Ora, ripenso a quando avevamo dei laboratori sulle macchine di Turing e su come all'epoca pensassi che non fosse una vera programmazione. Queste sono le esperienze che farai per evitare che chiunque prenda scorciatoie.

  • Iscriviti per progetti studenteschi. Sono stato coinvolto con (CSUA) un gruppo di studenti affini per costruire un gioco per lo stand del carnevale durante il mio ultimo anno. Se continui a divertirti e pensi di voler espandere il tuo coinvolgimento, sfrutta davvero le risorse. Scopri i progetti, parla con i tuoi compagni di classe, i tuoi professori e trova uno stage.

  • Siediti con un programmatore esperto. Ci sono state circa tre volte nella mia storia quando ho visto un altro programma di persone che è stato davvero d'ispirazione. Per loro, stavano solo scrivendo codice e pensando ad alta voce. Nessuna esagerazione, mi sentivo come se avessi assorbito più ascoltandoli di quanto avrei fatto da solo. Se incontri di più, sei molto più ricco. Siamo fortunati a trovarci in un'epoca in cui possiamo guardare video, ispezionare archivi di fonti completi e cercare istantaneamente un enorme negozio online di conoscenze. Non sostituisce l'esperienza di persona, ma in assenza di un tutor è un notevole miglioramento rispetto al materiale tradizionale. Guardare il codice non elaborato da altri, tuttavia, non può portare a nulla. Avrai voglia di qualcosa in mente e un buon debugger per entrare nella logica. Uno dei miei momenti più cari è stato realizzare una mod di Quake e non era la mod stessa che aveva qualcosa di memorabile. Stava vedendo la logica di gioco di Carmack. La mod è stata solo una ragione per cui mi sono tuffato.

  • Esercitati a spiegare e rispondere alle domande poste dal tuo partner di laboratorio. Volontariato per aiutare a insegnare. Forse formare un gruppo di studio e richiedere che ogni membro diventi un esperto su un argomento di classe. Quindi griglia quella persona e fagli grigliare. Quando sei costretto a rispondere alle domande, sarai obbligato a imparare tu stesso le risposte. Quando puoi spiegare chiaramente i concetti agli altri, hai arricchito la tua comprensione fino al punto in cui sei in grado di trasmetterli al di fuori di un libro e dei tuoi pensieri.

  • Infine, non aver paura di imparare nel modo più durosporcarsi le mani, commettere errori. Questa può anche essere chiamata esperienza. Come esempio più pratico per quanto riguarda la tua domanda sui progetti con base di codice ingombrante e numero di file elevato, esegui questo esercizio: usa un singolo file per il tuo lavoro. Davvero non sto scherzando. Questa stessa domanda è stata posta nella mia azienda attuale e precedente. Qui un altro sviluppatore ha osservato che preferisco mantenere un file per ogni classe. Questo gli sembrava estraneo e, in una questione correlata, non gli piacevano nemmeno le lezioni parziali. Quindi un modo per avere un'idea di quando o dove è opportuno suddividere la logica in file separati sarebbe quello di iniziare con un solo file. Dopo aver praticato la regola di un file su più progetti, si spera di aumentare la complessità, potresti imbatterti in un progetto in cui ci sono così tante classi in un unico file che trovi difficile leggere o che a causa del controllo della versione diventa difficile collaborare. A questo punto, si desidera creare file separati per raggruppare classi diverse. Data la tua preferenza, puoi decidere in anticipo che ti piacciono tutte le classi di dati in un file. Poi di nuovo forse più tardi, potresti decidere che ti piacciono i file separati anche tra le classi di dati come gruppo.


+1 bella risposta. Devo dire che sedersi con un programmatore esperto può essere intimidatorio quando si inizia anche per nuove persone. Accelerare attraverso cose che ti avrebbero richiesto una notevole quantità di tempo. Ma, a seconda del tipo di persona, le cose del genere potrebbero essere un fattore motivante e accendere un po 'di quel fuoco nella pancia. Ti spinge a voler calciare il culo.
Terrance

1

Non devi avere una grande idea per iniziare a programmare qualcosa. Vorrei iniziare dalla parte facile. Ad esempio, un programma che già lo usi. Prova a fare qualcosa che sai già come funziona. Affronta i tuoi problemi, quindi lo imparerai più velocemente. Una volta che hai più esperienza, inizierai ad avere alcune buone idee di programmi per semplificarti la vita durante la programmazione, o semplicemente un buon programma per fare qualcosa che non ci hai mai pensato prima. Sto programmando Java da quasi un anno e altre lingue da un paio d'anni. Ci è voluto del tempo per iniziare a fare quello che volevo davvero fare. Ho appena iniziato a fare le mie cose. Grazie a StackOverflow. Non lo sapevo prima.


1

Quindi ci sono un sacco di risposte, quindi perdonami se ripeto gran parte di ciò che è già stato detto, ma ecco i miei 2 centesimi.

Innanzitutto scegli un'idea. Qualsiasi idea andrà bene, qualcosa di semplice probabilmente sarebbe meglio di grande. I progetti hanno la tendenza a crescere molto rapidamente nel loro campo di applicazione (alcuni lo chiamano "creep").

Quindi crea uno scheletro per il progetto. Ciò richiederà un po 'di conoscenza dell'architettura e del design e probabilmente sbaglierai le prime dieci volte che lo provi - l'ho fatto. Disporre semplicemente una struttura di file decente e forse un piccolo scheletro di codice che mostri le parti importanti del sistema.

Salva lo scheletro nel tuo VCS (raccogli il tuo veleno con questo e resisti quando conduce a una guerra santa). Una volta che hai iniziato a usare VCS, usarlo costantemente per piccoli cambiamenti diventa una seconda natura, ma assicurati di iniziare.

Ora scegli una funzionalità piccola ma importante per il sistema e realizzala. Non preoccuparti di assicurarti di avere tutto incapsulato perfettamente e che abbia il design "migliore" (che si evolverà con il sistema). Ottieni qualcosa che funzioni. Anche ottenere alcuni test unitari ti aiuterà a sapere cosa è successo quando qualcosa si rompe, se esegui i test regolarmente.

Costruisci il tuo sistema. Sarebbe anche un buon momento per ottenere un sistema di compilazione automatizzato e una continua integrazione. Se non sai cosa sono, o impara e prova, oppure continua a tuo rischio e pericolo; in entrambi i casi continua a funzionare.

Ora scegli un'altra funzione e ripeti e ripeti e ripeti.

Una volta che pensi che funzioni bene, mostralo a un amico. L'amico non deve sapere come programmare o nemmeno sapere cosa fa il programma. Uno ti farà sentire bene nel mostrare a qualcuno e due ti aiuterà a sapere esattamente cosa fa il sistema.

Se arrivi al punto in cui sei molto sicuro di ciò che hai realizzato, rilascialo online e prova a ottenere feedback. Un hub di repository o il sub-reditt dei programmatori potrebbero fornire alcune critiche costruttive. Prova a trovare un professore CS / SE e faglielo vedere. Magari chiedi a un programmatore professionista. Basta avere un'altra opinione dei programmatori.

Una volta terminato (o probabilmente prima) ti renderai conto che il codice che hai inizialmente scritto è molto peggio di quello che hai fatto di recente. Questo è perfettamente naturale e succede a tutti noi. Ora devi trovare un nuovo progetto e imparare qualcosa di nuovo, forse una nuova strategia di test o come utilizzare l'architettura orientata ai servizi.


1

Qualcosa che può aiutare è pensare a un semplice problema che hai ogni giorno in cui qualcosa che potresti fare con carta e matita potrebbe essere sostituito da un programma.

Questo ti dà un problema relativamente semplice con una soluzione abbastanza nota che richiede solo un livello di automazione. Tieni presente che questo non deve essere il prossimo MS Word / WordPad / NotePad; solo qualcosa che risolve il tuo (semplice) problema.

Ad esempio, un problema che continuo a reimplementare quando lavoro con una nuova lingua è una semplice app per il cronometraggio. L'app viene utilizzata per tenere traccia delle ore fatturabili per diversi progetti durante il giorno. Un programma abbastanza semplice con molti piccoli trucchi, ad esempio come gestire i riavvii a metà giornata o come aggiungere / rimuovere elementi dall'elenco.


1

Penso che parte del problema sia che quando leggi libri di programmazione, ti insegnano semplicemente la lingua. Non menzionano che per programmare quasi tutto, è necessario accedere alla programmazione di BIBLIOTECHE e SDK, ecc. Sfortunatamente conoscere la lingua purtroppo non è sufficiente.


1

Immagino che il tuo problema provenga da: 1. il conflitto che esiste tra teoria e pratica, e anche che ... 2. ... devi capire che il tuo codice verrà eseguito da un altro codice. 3. non puoi codificare qualcosa se non hai idea di cosa potresti fare. 4. Conosci metà della difficoltà

  1. Conoscere una lingua per teoria non significa che "parli": è la differenza tra leggere l'inglese e parlarla. Anche il gran numero di strumenti diversi disponibili per compilare, collegare, modificare un codice sorgente farà girare la testa.

  2. quando si impara a programmare, soprattutto se il tempo viene utilizzato da un terminale per immettere / emettere testo, poiché questo è il modo più semplice di gestire la programmazione. In effetti, i programmatori usano librerie (come Qt), framework (django immagino) e altri codici di scelta rapida per essere produttivi. Ovviamente se ritieni di poter scrivere la tua ruota, non reinventarla e leggere libri sulla progettazione di compilatori e sulla progettazione del kernel: c'è molto da imparare in questi: forse ti senti stupido per le app che non richiedono molto di tecnicità.

  3. Inventa qualcosa! Ovviamente potresti fare un editor di testo, un gioco, ecc. Il fatto è che non li farai se non vedi alcun motivo per: questi programmi saranno inutili per te se tutto ciò a cui pensi è già stato fatto . Personnaly Sogno ancora di essere in grado di codificare un protocollo p2p decentralizzato simile a Facebook con chat, messaggi offline, ecc. Tutto in uno in modo che possa essere utilizzato con dispositivi wireless integrati. Internet offre molte possibilità, non dimenticare di pensarci.

  4. In realtà la teoria è necessaria per esercitarsi, ma non è tutto: algoritmi e tecniche non fanno parte della teoria della programmazione, ci sono molti paradigmi e altri modi "standard" per fare il tuo codice: schemi di progettazione, liste collegate, ecc ecc.


1

Forse potresti scegliere un linguaggio di scripting per iniziare. Ho iniziato a programmare con il linguaggio C. Secondo me è facile iniziare con il linguaggio C, ma è necessario molto più tempo per conoscere l'algoritmo e qualcosa sul sistema operativo. E ogni volta che mi alleno è semplicemente con una GUI DOS, che mi rende depresso.

E più tardi ho scelto un linguaggio di scripting chiamato ActionScript per iniziare. Il linguaggio di scripting è un linguaggio orientato agli oggetti e può controllare il comportamento di un filmato Flash. Il linguaggio di scripting è semplice per eseguire alcune operazioni vicine al dominio problematico , proprio come trace("HelloWorld")in ActionScript per generare una stringa. E ha un potente IDE che ti consente di verificare se il tuo programma sta andando bene.

In una parola, se vuoi iniziare a programmare in modo rapido , un linguaggio di scripting potrebbe essere una buona scelta :-)


1

Scrivi una specifica. Cosa vuoi che faccia il tuo programma? Le schermate (se si tratta di un programma basato sull'interfaccia utente), la logica, l'input / output, ecc. Mantengono l'ambito limitato a ciò che è possibile fare in un ragionevole lasso di tempo (una settimana? Un mese?).

Quindi costruiscilo. Attenersi alle specifiche, farlo funzionare in base alle specifiche richieste. Sicuramente ti imbatterai in distrazioni, sicuro che dovrai fare qualche ricerca perché non hai mai affrontato un problema particolare prima, ma costruirai qualcosa che volevi costruire. Questo è diverso dalla costruzione di qualcosa che puoi "costruire".

Una volta terminato, refactoring del codice, cerca di renderlo più efficiente. Quindi se pensi che il tuo programma non sia ancora finito, ricomincia, migliora le specifiche, migliora il codice e continua a farlo.

Ricorda, la maggior parte dei software commerciali risolve un'esigenza. È molto importante definire la necessità e la soluzione per soddisfare tale esigenza prima di risolvere effettivamente il problema. E man mano che la necessità diventa sempre più grande, anche il tuo software crescerà nel tempo!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.