Come faccio ad essere in grado di scrivere codice per diventare un buon sviluppatore?

10

Sono frustrato dalla mancanza di spiegazioni concrete su come passare dalla possibilità di scrivere script (bash, awk) e scrivere applicazioni semplici (c, php, python) per progettare e sviluppare software più grandi e più complicati. Sembra che da un lato ci siano i libri di programmazione e dall'altra ci sono i libri di ingegneria del software / gestione del progetto progettati per i team di programmatori.

Ho letto molto di entrambi. Ho letto i classici di XP / Agile e ho una discreta 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 disegna uno spazio vuoto e non so da dove cominciare.

L'ho appena estratto? Esistono flussi di lavoro strutturati per singoli sviluppatori che non lavorano in team o per una grande software house? Non ho alcun desiderio di ottenere un PMP o lavorare per un'azienda di software. Sto solo cercando un flusso di lavoro efficace, efficiente e pratico.

    
posta Thomas Owens 02.12.2011 - 04:43
fonte

7 risposte

11

Secondo me, diventi un buon sviluppatore avendo esperienza e lavorando con diversi modi di fare le cose. Hai affermato che hai un problema da "ecco la mia idea" a "ecco la mia soluzione". Questo è qualcosa di più verso le metodologie di sviluppo del software oltre ad essere uno sviluppatore esperto.

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

Ci sono alcune cose che ho imparato nel corso degli anni da altri e lavorando su vari progetti, come ad esempio:

  • Rendi tutto verificabile, 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 / inserire di più qui, senza avere esperienza nel farlo;
  • È difficile progettare un buon software se non si ha esperienza e si impara dagli altri;
  • Non avrai mai un design perfetto la prima volta, anche se uno sviluppatore esperto - le cose cambiano e quindi; anche il tuo design potrebbe;
  • Scrivi le cose: scrivendo / disegnando / lavagna / dipingendo / con qualsiasi cosa ti trovi a tuo agio, ti semplifica la vita se scrivi qualcosa. Come progetti di GUI, diagrammi di classe, ecc. Nella mia esperienza, solo "hackerare qualcosa insieme" ha il potenziale per fallire in modo catastrofico;
  • Non reinventare la ruota, non dovresti. Se stai cercando di implementare la tua HashMap, probabilmente stai facendo qualcosa di sbagliato. Fai ricerche e pensa prima di scrivere codice.

Spero che questo aiuti.

    
risposta data 02.12.2011 - 04:57
fonte
5

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

Come medico non può essere bravo con solo le lezioni di medicina, o un avvocato non può conoscere tutto il lato politico dell'essere un procuratore con la sola laurea, essendo un buon sviluppatore ha bisogno di esperienza e tempo.

L'esperienza non arriva leggendo il codice di terze parti. Se si ottiene uno studente di medicina, lui / lei sarebbe in grado di indicare molte procedure, malattie, medicinali ecc., ma il l'effettiva applicazione di queste cose (quando applicare una procedura, quale malattia da diagnosticare ecc.) viene solo con la supervisione e l'esperienza.

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

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

Comunque, penso che non ci sia una scorciatoia per acquisire esperienza, e deve essere perseguito con discipline e pazienza .

    
risposta data 02.12.2011 - 04:57
fonte
4

Puoi iniziare migliorando il codice di altre persone. Prendi un progetto che hai e aggiungine una funzione. Dovrai decidere cosa farà la funzione e come dovrebbe farlo. Lavorando all'interno del framework del codice esistente, progetta la tua soluzione.

E non aver paura di hackerare cose. Un sacco di nuovi sviluppi sono fatti raffinando (o preferibilmente riscrivendo) prototipi veloci e sporchi. Vai avanti e usa tutte le peggiori pratiche e antipattern nel libro, solo sfornare qualcosa che fa quello che vuoi. Quindi, tornare indietro e progettarlo correttamente. Di solito, mi trovo a pensare "Sai, un modo migliore per farlo sarebbe ..." mentre sto codificando con fatica alcuni parametri di configurazione nella mia mostruosità a tre procedure di 800 righe.

So che al momento è fuori moda, ma le tecniche dell'analisi strutturata mi hanno davvero aiutato a capire come progettare il software. Gioca con alcuni grafici a bolle e DFD per farti un'idea dei problemi di decomposizione e progettare diverse parti di un sistema per lavorare insieme.

    
risposta data 02.12.2011 - 14:27
fonte
2

Come altri hanno già detto, l'esperienza deriva dalla scrittura del codice. Ma dovresti anche avere qualcun altro che riveda 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.

    
risposta data 02.12.2011 - 15:50
fonte
1

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

Pensa ad un blog, per esempio. Vuoi essere in grado di creare e modificare post che altri possono leggere. Subito puoi dividere il progetto in admin e sezioni pubbliche. Come minimo, l'amministratore richiede 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 del blog richiede un controllo per assicurarsi che l'utente amministratore abbia i 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 riuscito a mappare il tuo software in questo modo, puoi dare un'occhiata a come diverse parti interagiscono tra loro. Dove potresti ripetere il codice? Cosa può essere astratto? Questo dovrebbe essere un processo iterativo sia come pianifichi che mentre scrivi il codice stesso.

Suggerirei di capire quale sia il set di funzioni minimo da cui iniziare e di implementarlo prima di aggiungerne altri. Dovrai codificare in modo difensivo in modo che le modifiche future non siano troppo difficili, ma allo stesso tempo non vuoi implementare le mezze funzioni che potrebbero non essere mai completate. È una linea difficile da percorrere tra la flessibilità e l'essere disposti a uccidere spietatamente i tuoi cari, a prendere in prestito un riferimento letterario. Essere bravi in quel particolare atto di bilanciamento viene solo dall'esperienza.

E questo è quanto, come hanno detto le altre risposte: esperienza. L'unico modo per ottenerlo è iniziare. Non preoccuparti tanto di renderlo perfetto sin dall'inizio. Prima di tutto fai in modo che il codice funzioni, quindi rendilo bello, quindi rendilo veloce.

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

    
risposta data 02.12.2011 - 17:32
fonte
0

So che dici di non voler lavorare per una società di software, ma è un buon posto dove fare esperienza di cui parlano molte delle altre risposte. E che tu voglia 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 Pair Programming da solo. E se sei in coppia con qualcuno più intelligente di te, ottieni il beneficio ulteriore di ottenere migliori pratiche da loro mentre acquisisci esperienza in quella metodologia.

A proposito, ho reso la mia pratica provare a lavorare con gruppi in cui mi sento al di sotto della media di esperienza, abilità e simili. Solleva enormemente il mio gioco. È molto più difficile da fare da solo o dove sei il ragazzo "esperto".

    
risposta data 02.12.2011 - 19:16
fonte
0

Quello che stai cercando sono 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 col seguire il metodo scientifico, con alcuni fronzoli.

  1. Hai un problema (usa strumenti e tecniche per aiutare a definire questo)
  2. Si ipotizza una soluzione (modelli e aiuto esperienza)
  3. Verifica ipotesi (potresti non avere nemmeno il codice qui)
  4. Ripeti i passaggi 2 e 3 fino a quando l'ipotesi rimane valida. Ora hai una teoria (programma di lavoro per risolvere il problema)
  5. Sviluppa un esperimento sulla teoria dello stress, cercando i buchi (casi di test!)
  6. Se i casi di prova sono validi, hai una soluzione! Altrimenti, risciacqua e ripeti

Si noti che questo è piuttosto alto livello. Ogni passaggio coinvolge in genere diversi passaggi secondari, come la determinazione di cosa sia effettivamente il problema. Ad esempio, cerca di risolvere problemi di parole in matematica. Raccogli fatti (uno strumento) e determina ciò che è realmente voluto. Quindi, esaminate i fatti, tentando di associarli alla soluzione.

Questo finisce per diventare problemi secondari del problema principale. Quindi, segui di nuovo i passaggi. Abbiamo bisogno di un oggetto intermedio per ottenere il risultato finale, quindi diventa il nostro nuovo problema. Questo decompone il problema in sezioni piccole e facilmente comprensibili. Quando ogni pezzo viene risolto, la soluzione viene riunita.

    
risposta data 02.12.2011 - 18:02
fonte

Leggi altre domande sui tag