Come posso passare dalla possibilità di scrivere codice all'essere un buon sviluppatore?

Sono frustrato dalla mancanza di spiegazioni concrete su come passare dalla capacità di scrivere script (bash, awk) e scrivere semplici applicazioni (c, php, python) alla progettazione e allo sviluppo di software più grandi e complicati. Sembra che da un lato ci siano libri di linguaggio di programmazione e dall'altro ci siano libri di ingegneria del software / project management progettati per team di programmatori.

Ho letto un sacco di entrambi. Ho letto i classici di XP / Agile e ho una buona comprensione teorica del processo di sviluppo del software. Mi piace leggere il codice di altre persone e posso seguirlo abbastanza bene. Ma quando ho un'idea per un progetto o voglio passare da "ecco il problema / necessità" a "ecco la soluzione", la mia mente si svuota e non so da dove cominciare.

Lo faccio solo? Esistono flussi di lavoro strutturati per singoli sviluppatori che non lavorano in team o per una grande software house? Non ho davvero alcun desiderio di ottenere un PMP o lavorare per una società di software. Sto solo cercando un flusso di lavoro efficace, efficiente e pratico.

Secondo me, diventi un buon sviluppatore avendo esperienza e lavorando con molteplici modi di fare le cose. Hai dichiarato di avere un problema passando da "ecco la mia idea" a "ecco la mia soluzione". Questo è qualcosa in più rispetto alle metodologie di sviluppo del software oltre ad essere uno sviluppatore esperto.

L'uso di una metodologia di sviluppo software è molto più di un semplice "hacking di codice" e queste metodologie forniscono flussi di lavoro strutturati. La famiglia Agile offre una buona struttura per piccoli team di sviluppo (o individui) che puoi seguire per aiutarti a passare dalla fase "idea" alla fase "prodotto finito".

Ci sono alcune cose che ho imparato negli anni da altri e lavorando su vari progetti, come:

• Rendi tutto testabile, questo renderà la tua vita molto più semplice;
• Non puoi aspettarti di avere un design perfetto ed essere in grado di progettare applicazioni aziendali / il prossimo titolo di gioco più grande / inserirne di più qui, senza avere esperienza nel farlo;
• È difficile progettare un buon software se non hai avuto esperienza nel farlo e imparato da altri;
• Non avrai mai un design perfetto la prima volta, anche come sviluppatore esperto - le cose cambiano e quindi; anche il tuo design potrebbe;
• Scrivi le cose: scrivere / disegnare / fare una lavagna / dipingere / qualunque cosa tu ti senta a tuo agio, ti semplifica la vita se le cose sono scritte. Come i progetti della GUI, i diagrammi di classe, ecc. Nella mia esperienza, solo andare a "hackerare qualcosa insieme" ha il potenziale per fallire catastroficamente;
• Non reinventare la ruota, non dovresti. Se stai cercando di implementare la tua HashMap, probabilmente stai facendo qualcosa di sbagliato. Cerca le cose e pensa prima di scrivere il codice.

Spero che questo aiuti.

Bene, secondo me, come in ogni professione, essere un buon professionista tutto ciò che serve - oltre alla formazione teorica - è esperienza .

Come medico non può essere bravo solo con le lezioni tenute alla scuola di medicina, o un avvocato non può conoscere tutto il lato politico di essere un attourney con solo la sua laurea, essere un buon sviluppatore ha bisogno di esperienza e tempo.

L'esperienza non arriva leggendo codice di terze parti. Se ottieni uno studente di medicina, lui / lei sarebbe in grado di indicare molte procedure, malattie, medicine ecc., Ma l'applicazione effettiva di queste cose (quando applicare una procedura, quale malattia diagnosticare ecc.) Arriva solo con supervisione ed esperienza.

Dal momento che non vuoi lavorare per una grande azienda (o per qualsiasi altra società), ti suggerisco di iniziare sviluppando piccole applicazioni, un passo alla volta. Lo sviluppo di software da solo richiede molto tempo, credimi.

Un'altra cosa che ti suggerisco di diventare un buon sviluppatore / ingegnere di software, è di contribuire al software open source. Molti ragazzi hanno fatto una buona quantità di denaro (ed esperienza, tra l'altro) aiutando a sviluppare software open source e dando consulti in seguito. Si sono fatti un nome con i loro contributi all'open source.

Ad ogni modo, penso che non ci sia una scorciatoia per acquisire esperienza, e deve essere perseguito con disciplina e pazienza .

Puoi iniziare migliorando il codice di altre persone. Prendi qualche progetto che hai e aggiungi una funzionalità ad esso. Dovrai decidere cosa farà la funzione e come dovrebbe farlo. Lavorando nell'ambito del codice esistente, progetta la tua soluzione.

E non aver paura di hackerare le cose. Molti nuovi sviluppi vengono effettuati perfezionando (o preferibilmente riscrivendo) i prototipi rapidi e sporchi. Vai avanti e usa tutte le peggiori pratiche e gli antipasti del libro, fai semplicemente uscire qualcosa che faccia quello che vuoi. Quindi, torna indietro e progettalo correttamente. Di solito, mi ritrovo a pensare "Sai, un modo migliore per farlo sarebbe ..." mentre sto codificando alcuni parametri di configurazione nella mia mostruosità su tre procedure a 800 righe.

So che è attualmente fuori moda, ma le tecniche di analisi strutturata mi hanno davvero aiutato a capire la progettazione del software. Gioca con alcuni grafici a bolle e DFD per avere un'idea dei problemi di decomposizione e progettare diverse parti di un sistema per lavorare insieme.

Come altri hanno già detto, l'esperienza viene dalla scrittura del codice. Ma dovresti anche chiedere a qualcun altro di rivedere il tuo codice, se possibile. Un programmatore più esperto può segnalare problemi nel codice e mostrarti modi migliori di fare le cose. Contribuire a un progetto open source ti darà la possibilità di fare entrambe le cose.

Per me, aiuta a scomporre un software più grande in blocchi più piccoli. E poi spezzare quei pezzi in parti ancora più piccole e così via. Ogni programma software è una raccolta di piccoli pezzi di logica.

Prendi in considerazione un blog, ad esempio. Vuoi essere in grado di creare e modificare post che altri possono leggere. Immediatamente puoi dividere il progetto in sezioni amministrative e pubbliche. Come minimo, l'amministratore richiederà agli utenti amministratori, una pagina di accesso e una sezione per la gestione del blog. La sezione per la gestione del blog può essere suddivisa in un'interfaccia CRUD (Crea, Leggi, Aggiorna, Elimina). La creazione di un nuovo post sul blog richiederà un controllo per assicurarsi che l'utente amministratore disponga dei privilegi giusti, un modulo, la convalida del modulo e la possibilità di salvare nel database. E così via.

Più si interrompe un problema o una funzionalità, più diventa gestibile. È dividere e conquistare. Una volta che sei stato in grado di mappare il tuo software in questo modo, puoi dare un'occhiata a come diversi pezzi di esso interagiscono tra loro. Dove potresti ripetere il codice? Cosa si può sottrarre? Questo dovrebbe essere un processo iterativo sia durante la pianificazione che durante la scrittura del codice stesso.

Consiglierei di capire qual è il tuo set minimo di funzionalità e di implementarlo prima di aggiungere altri pezzi. Ti consigliamo di programmare in modo difensivo in modo che i cambiamenti futuri non siano troppo difficili, ma allo stesso tempo, non vuoi implementare metà funzionalità che potrebbero non essere mai completate. È una linea difficile camminare tra la flessibilità e la volontà di uccidere spietatamente i tuoi cari, prendere in prestito un riferimento letterario. Essere bravi in ​​quel particolare atto di bilanciamento proviene solo dall'esperienza.

E questo è ciò che si riduce, come hanno già detto le altre risposte: l'esperienza. L'unico modo per ottenerlo è solo iniziare. Non preoccuparti così tanto di renderlo perfetto fin dall'inizio. Prima fai in modo che il codice funzioni, quindi rendilo bello, quindi rendilo veloce.

Inoltre, a differenza di questo paragrafo, non considerare la sicurezza alla fine come ripensamento. Dovresti avere un'idea dei modi in cui il tuo software potrebbe essere compromesso, ma per iniziare, non fidarti mai degli input dell'utente.

So che dici di non voler lavorare per un'azienda di software, ma è un buon posto per fare l'esperienza di cui parlano molte altre risposte. E se vuoi o meno lavorare su grandi progetti, l'esposizione al lavoro e agli stili di lavoro di altre persone sono buone cose da avere.

Ad esempio, non puoi provare la programmazione della coppia da solo. E se sei accoppiato con qualcuno più intelligente di te, ottieni l'ulteriore vantaggio di guadagnare da loro migliori pratiche mentre acquisisci esperienza in quella metodologia.

A proposito, ho fatto pratica per provare a lavorare con gruppi in cui sento di essere al di sotto della media in termini di esperienza, abilità e simili. Aumenta enormemente il mio gioco. È molto più difficile farlo da soli o dove sei il ragazzo "esperto".

Quello che stai cercando sono le capacità di problem solving . Ho notato che si presume che lo sviluppatore possa già farlo, il che è sciocco. Fortunatamente, la risoluzione dei problemi è un'abilità generale, utilizzata in matematica, ricerca, vita quotidiana e così via.

In primo luogo, dovresti finire seguendo il metodo scientifico, con alcuni fronzoli.

1. Hai un problema (usa strumenti e tecniche per aiutarti a definirlo)
2. Ipotizzi una soluzione (schemi e aiuto dell'esperienza)
3. Verifica l'ipotesi (potresti non avere nemmeno il codice qui)
4. Ripetere i passaggi 2 e 3 fino a quando l'ipotesi è valida. Ora hai una teoria (programma di lavoro per risolvere il problema)
5. Sviluppa un esperimento per la teoria dello stress, alla ricerca di buchi (casi di test!)
6. Se i casi di test sono validi, hai una soluzione! Altrimenti, sciacquare e ripetere

Si noti che questo è piuttosto alto livello. Ogni passaggio comporta in genere diversi passaggi secondari, ad esempio determinare quale sia effettivamente il problema. Ad esempio, guarda come risolvere i problemi di parole in matematica. Raccogli fatti (uno strumento) e determina ciò che è effettivamente desiderato. Quindi, esamini i tuoi fatti, tentando di mapparli alla soluzione.

Questo finisce per diventare sotto-problemi del problema principale. Quindi, segui di nuovo i passaggi. Abbiamo bisogno di un articolo intermedio per ottenere il risultato finale, quindi diventa il nostro nuovo problema. Questo scompone il problema in sezioni piccole e di facile comprensione. Man mano che ogni pezzo viene risolto, la soluzione viene messa insieme.