Diventare involontariamente un programmatore: come farlo nel modo giusto? [chiuso]

Il mio background è ingegneria elettrica, DSP per essere più precisi. La società per cui lavoro attualmente fa molti progetti diversi, principalmente nella costruzione di hardware analogico. Essendo un po 'più vicino ai computer rispetto a tutti gli altri qui, sono spesso l'unico codice di scrittura per entrambi i dispositivi embedded (con cui sto perfettamente bene) e per il sistema operativo Windows o Linux. È quest'ultimo che è territorio straniero per me.

Sono in grado di programmare e conosco alcuni linguaggi (C / C ++, Java, alcuni VB.NET), ma li ho usati solo per simulazioni di algoritmi nell'elaborazione di segnali e immagini, reti neurali e altre applicazioni simili. Per me la programmazione è stata uno strumento computazionale più di ogni altra cosa. Tuttavia, ottengo sempre più progetti in cui devo scrivere un vero software completo e non so davvero come farlo, perché non ho mai dovuto farlo e non sono mai stato abbastanza interessato. Ho visto alcuni ingegneri che si sono convertiti in programmatori in una certa misura a causa delle richieste di lavoro, e la maggior parte di loro non era così brava in quello che hanno fatto. Sono sicuro che molte persone hanno incontrato lo stesso.

Se dovessi imparare a scrivere un software adeguato con una buona interfaccia utente, una buona architettura interna e così via, come posso farlo? Non abbiamo nessuno al lavoro che possa dirmi quali sono le buone pratiche e cosa no. Dato che posso scrivere il codice nel senso più grezzo della parola, cos'altro c'è da sapere sulla scrittura di un buon software e come posso arrivarci da solo?

Ci sono alcuni libri che ti aiuteranno molto. Suggerisco di avere sempre accanto a te il codice completo . È un riferimento inestimabile. In una precedente compagnia in cui lavoravo questo era anche il libro che avevamo consegnato a tutti i programmatori junior dopo essere stato assunto.

Anche Pragmatic Programmer è una risorsa davvero utile ed è piuttosto breve, ma ti consiglio di leggerlo dopo aver completato il codice.

Questi libri ti faranno iniziare, quindi codice, codice, codice e codice altro ... ma sai quando fermarti, il tuo software non sarà mai perfetto.

La mia compagnia lo fa sempre ... e mi fa impazzire.

"Sono uno sviluppatore di software, come posso diventare un EE?"

Bene, penso che la risposta sia abbastanza ovvia. Ci vuole molto tempo e duro lavoro. E, naturalmente, i materiali didattici giusti. La formazione ingegneristica aiuta, nella mia università il CS e le scuole di ingegneria erano nello stesso edificio con molte sovrapposizioni. Gli algoritmi e le basi matematiche ci sono.

Un errore che vedo fare la maggior parte dei nuovi arrivati ​​è quello di mordere molto più di quanto possano masticare. Materiale di apprendimento nell'interfaccia utente, architetture, codice di qualità ... questo è molto terreno . Qualcosa che richiede anni davvero ed è spesso fatto da team di diversi esperti delle società di software.

Per non dire che non puoi essere abbastanza decente da solo, se metti il ​​tempo. Basta riconoscere l'entità dei materiali in modo da non sopraffare te stesso e A. Esci o B. Costruisci importanti debiti tecnici nelle tue app prendendo scorciatoie importanti nel tuo processo di apprendimento.

A causa di tutto ciò, non c'è nessun "catch-all" diventare un fantastico sviluppatore con questo libro là fuori. Ti consiglio di iniziare raccogliendo un libro ben valutato sulla tua lingua più utilizzata e anche partecipare alla comunità Stack in particolare per le revisioni del codice.

Prova Amazon.com, hanno buone recensioni di libri.

Libri : la cosa principale è leggere (buoni) libri nella tua lingua preferita. Una volta che conosci la tua lingua preferita, puoi ottenere " X più efficaci " o "Best practice Y" e così via. Trovo che i libri di cucina siano molto bravi a colmare le lacune che potresti avere. Quindi, immagino che siano almeno tre i libri che devi procurarti. Una cosa: fai esercizi e codifica kata per migliorare la tua comprensione della lingua. Naturalmente, è necessario un buon modello xUnit .

Gli algoritmi sono particolarmente importanti e dovresti scegliere un libro che li descriva in dettaglio, sempre nella tua lingua preferita. Design Patterns e Anti-Patterns valgono la pena conoscere in qualsiasi lingua.

In conclusione: ci vuole tempo. Non abbiate fretta.

Fai schifo in programmazione. Sì.

Ma questo non significa che non puoi distribuire software, il che rende felici le persone;)

Sii umile. Scrivi la logica "aziendale" di cui hai bisogno. Usa il codice della libreria per tutto il resto. Non tentare di scrivere algoritmi fondamentali (come l' ordinamento degli array ), non usare "trucchi fantasiosi", attenersi ad alcune convenzioni di codice draconiane .

Usa un buon IDE. Questo è essenziale, in quanto ti aiuterà a formattare il tuo codice e tracciare errori di battitura / semplici errori.

Leggi libri come " Codice completo " e " Programmatore pragmatico ", prova a forzare te stesso e impara OOP (è semplice e ti aiuterà a mantenere il tuo codice più mantenibile).

Usa SVN , esegui il commit spesso, in modo da poter ripristinare le modifiche (quando rovinerai qualcosa).

Trova qualcuno, che è un vero programmatore , con background accademico, se possibile. Quindi sarai in grado di parlare con lui condividendo i tuoi problemi con i principianti e ottenere risposte illuminanti.

E, naturalmente, la cosa più importante è mantenere la codifica, la codifica, la codifica .

ps: se sei in grado di scrivere codice C ++ che funziona e scrivi reti neurali (!) - allora il tuo cervello è adatto alla programmazione;) Buona fortuna!

Ci sono buone risposte qui.

Un grande giro a tuo favore è il semplice fatto che vuoi sapere.

Gran parte dell'ingegneria del software (che dovresti prendere con sano scetticismo, ovviamente) riguarda come farlo in modi che non ti pentirai in seguito. Un esempio è l'uso di un sistema di controllo della versione del codice sorgente. Un altro è quello di dividere il codice in file, quindi è più facile lavorarci su frammentariamente. Un altro è essere un pignolo sull'ordinamento : formattazione del codice e convenzioni di denominazione. Le convenzioni esatte non contano tanto quanto essere coerenti al riguardo.

In questo modo, quando tornerai al codice tra un anno o più, non penserai "Chi ha fatto questo casino?" Sarai in grado di trovare le cose e cambiarle senza troppi rischi di rottura. **

Un buon modo per iniziare è trovare vari programmi di esempio e lavorarci sopra. Quindi puoi adattarli alle tue esigenze.

** Uno dei miei più grandi mal di testa sta cercando di lavorare con il codice scritto da persone che non pensavano che la formattazione o la denominazione fossero importanti.

Mentre ci sono molte e buone risorse su come fare e non fare le cose, alla fine la cosa più importante è vedere un sacco di codice e lavorare con esso e vedere quanto sia facile o complicato da mantenere per te stesso.

Un buon modo per imparare è avere qualcuno che abbia esperienza nel fare il progetto iniziale e poi rivedere il tuo codice e mostrarti tecniche utili che hai usato per loro. Quindi, se per caso riesci a convincere i tuoi capi ad assumere almeno un ingegnere software con esperienza nella conduzione di (piccoli) progetti software e nella progettazione di software per guidare i progetti, penso che sarebbe l'opzione migliore.

Se non riesci a convincere nessuno a dividerti, al giorno d'oggi c'è un forte movimento open source. Forse usi alcuni strumenti open source nel tuo lavoro, quindi prova a correggere i bug in essi o aggiungere semplici funzionalità che hai usato e discutere su come fare quelle cose con la rispettiva comunità. È un esercizio poco pratico di apprendimento pratico per imparare ad applicare le regole generali che troverai nei libri su problemi pratici reali.

Una cosa che consiglierei davvero per imparare la programmazione di qualità e le preoccupazioni di architettura sarebbe l'insegnamento di "Zio Bob" (Robert Martin). Ha alcuni video da $ 1 che sono di dimensioni ridotte, anche se forse eccessivamente stravaganti, oltre ad alcuni buoni libri.