Devo continuare la mia pratica di codifica autodidatta o imparare a fare la programmazione professionale? [chiuso]

In fact I'm rather scared of the fact that people will eventually be checking out my code.

Buono. Essere consapevoli del fatto che le persone guarderanno il tuo codice ti farà provare di più.

La programmazione è diventata un campo incredibilmente ampio. Ci sono dozzine di argomenti, strumenti, nicchie e specializzazioni, alcune delle quali sono carriere intere. C'è una grande quantità da imparare e conoscere, e quando lavori con altri programmatori, ci saranno sempre cose che sai che non lo fanno e cose che sanno che non lo fai. Questa è una buona cosa.

Se sei preoccupato che la tua esperienza sia incompleta, ci sono molti passi da fare per emendarla attraverso l'educazione formale e la collaborazione con esperti qualificati. Ma sembra che tu abbia paura che ci sia una pietra miliare quantificabile dopo la quale la gente dice "Ok, ora che l'ho imparato, sono ufficialmente un programmatore". Non c'è una pietra miliare del genere. Ho sicuramente avuto momenti in cui ho pensato "sì, ora sto andando da qualche parte" dopo aver imparato qualcosa di nuovo, ma non c'è una lista magica di cose che devi sapere e fare per chiamarti un programmatore.

Conosco un sacco di cose sulla programmazione, ho usato una dozzina di lingue in molti progetti, eppure il sottoinsieme di conoscenze di programmazione che posso chiamare mio è minuscolo. E mi piace. Francamente, un programmatore non è qualcosa che sei. Un programmatore è qualcosa che stai costantemente imparando ad essere.

Considera l'inventario delle tue capacità, i tuoi punti di forza e le tue debolezze. Ricevi feedback da persone con più esperienza di te. Cerca posizioni che si allineino abbastanza bene con dove pensi di essere, ma non aver paura di intraprendere lavori che sono un po 'al di fuori della tua attuale padronanza. Se prendi solo lavori di cui sai già tutto, non imparerai mai al lavoro.

Quando inizi a sviluppare applicazioni in collaborazione con altri sviluppatori, alcuni di questi problemi personali si intrometteranno.

Se inizi a lavorare in un negozio che utilizza caratteri di sottolineatura, utilizzerai caratteri di sottolineatura. Tutti, indipendentemente dal loro passato precedente, seguono lo standard del negozio per lo stile di codifica.

A meno che il tuo stile di codifica sia estremamente ovvio, è meglio abituarsi a scrivere commenti chiari e concisi che spieghino come funziona il tuo codice, in modo che altri sviluppatori possano seguirlo.

Se non sai nulla dei test unitari, compra un buon libro. Ci sono un sacco di buoni libri sui test unitari là fuori. Lo stesso con MVC.

Gli sviluppatori di software professionali sanno come giocare bene con gli altri, senza sporcare la sandbox. I migliori sanno come leggere e scrivere codice indipendentemente dallo stile.

La programmazione ha una componente artistica e una componente di disciplina. La componente artistica è nel pensare i migliori approcci e implementarli; la disciplina è assicurarsi che tu l'abbia fatto correttamente e che altri possano capire il tuo codice e migliorarlo quando necessario.

La componente artistica è divertente: lo fai perché ti piace. Naturalmente, questa è la parte che prima insegni a te stesso.

La componente della disciplina è più fastidiosa: lo fai per necessità. Tuttavia, è una componente vitale del lavoro in una squadra: non si può evitare di farlo, almeno in una certa misura. Una volta che il tuo codice è integrato con quello dei tuoi compagni di squadra, la tua flessibilità nel "cambiare le cose a piacimento" fa un tuffo nel naso. Tuttavia, è necessaria la capacità di modificare il codice con sicurezza in risposta a requisiti in evoluzione o per risolvere bug. È qui che avvengono diversi test "noiosi": con molti test in atto, è facile verificare se il tuo ultimo cambiamento rompe o meno le cose.

Anche lo stile del codice acquista importanza, perché attenersi a uno stile comune rende il codice più facile da leggere per tutti. Nelle aziende più grandi troverai lavori notturni che testano automaticamente la conformità agli standard di codifica e inviano messaggi di posta elettronica indesiderati quando decidi.

Tornando alla tua domanda, concentrarsi sulla componente artistica è una fase iniziale naturale dello sviluppo del programmatore. Ci possono volere diversi anni di lavoro nel settore prima di iniziare ad apprezzare la componente della disciplina. Non hai bisogno di guardare attivamente a "cambiare le tue tecniche", però: si trasformeranno in modo naturale nel processo di lavoro in una squadra.

Alla tua domanda, dovresti sempre cercare di cambiare la tua tecnica, abbracciare il progetto unico e la tecnologia emergente.

@ il punto di vista di "assfallows" "Francamente, un programmatore non è qualcosa che sei. Un programmatore è qualcosa che stai costantemente imparando ad essere". è davvero l'essere tutto e finire tutto del codice.

È fantastico che tu stia notando aree in cui fai qualcosa di diverso dagli altri, specialmente quando vedi che è uno standard. Hai individuato i test unitari e MVC - e ora il tuo prossimo passo deve essere quello di conoscerli. Guarda come funzionano, cosa hai bisogno di implementarli e cerca di capire quando è un buon progetto implementarli.

Questo è un campo in continua evoluzione con nuovi linguaggi e modelli in aumento o in diminuzione. Se sei a tuo agio con l'aspetto del codice, inizia a esaminare la parte del progetto. Scopri cosa li rende buoni e quando usarli.

Sicuramente entrare a far parte di un team è un grande vantaggio: hai sempre bisogno di altri occhi per guardare il tuo codice per individuare le aree in cui ti sei precipitato o non hai pensato a tutte le implicazioni.

Non è necessario essere un commentatore più grande. Ma dovresti essere un buon committer (sì, inizia ad usare una sorta di VCS - Raccomando Git).

Lo stile è una cosa che si evolve SEMPRE. Non preoccuparti per questo Imparerai cos'è un codice riutilizzabile e cosa no. Ma devi esercitarti e ottenere aiuto per questo.

Prova ad aiutare in alcuni progetti Open Source su Github. Alcune persone sono davvero carine e cercheranno di aiutarti. Questo è il consiglio migliore che posso darti.

In fact I'm rather scared of the fact that people will eventually be checking out my code. Is this just something normal any programmer goes through or should I really look to change up my techniques?

Come sapresti cosa cambiare senza il feedback dei programmatori più esperti?

Avere altre persone rivedere il tuo lavoro può essere scoraggiante, specialmente le prime volte, ma è il modo migliore per ottenere le critiche costruttive necessarie per migliorare le tue abilità. C'è un sito SE per recensioni del codice che potresti trovare utile. Chiedere agli amici intelligenti di guardare il tuo codice è un altro buon modo per ottenere un feedback.

La cosa più importante è sviluppare flessibilità. Più familiarità con i concetti fondamentali, più reattivi puoi essere in qualsiasi lingua, approccio di programmazione, stile o ambiente.

La padronanza è meno sull'imparare tutto / cosa / c'è da imparare, e altro sull'apprendimento / come / per risolvere un problema, in una varietà di situazioni.

E la migliore prescrizione per questo è la pratica. Dovresti sempre avere un progetto; se ti trovi tra un concerto a pagamento, prendi un giocattolo personale. Tempo libero un fine settimana? Lavora attraverso il "mondo Ciao" per una lingua o piattaforma che non hai mai usato prima. Cerca modi per imparare molto in una volta. Ad esempio, crea qualcosa in Google App Engine e imparerai tutto in una volta su Python, BigTable e i database orientati alle colonne. Riceverai anche una buona dose di stile Google "professionale".

Un buon generale sa come applicare le sue tattiche apprese e le esperienze raccolte in una varietà di terreni. Sembra che tu abbia qualche tattica ed esperienza, ma devi affrontare un terreno non familiare. Questo è probabilmente il miglior modo per accertarti di ciò che sai e di cosa hai bisogno di imparare.

E se lo stile "professionale" è quello che cerchi, affronta alcuni progetti "professionali". Trova un progetto open source che ti piace, assegnagli una modifica da apportare e impostalo. Preparati per i critici, ma ricorda che la maggior parte della gente in questo campo non ha raggiunto il punto in cui si trova per avere buone capacità sociali. Il punto è esporsi a ciò che vuoi essere il più possibile. E devi costruire te stesso abbastanza bene da farlo da solo. Nessuna classe può davvero insegnarti. In effetti, oggi c'è troppo dannatamente apprendimento di classe, e non abbastanza solide competenze nel mondo reale.

It's left me not that confident in the look of my code, or wondering whether I'll cause sparks when joining a company or maybe contributing to open source projects. In fact I'm rather scared of the fact that people will eventually be checking out my code. Is this just something normal any programmer goes through or should I really look to change up my techniques?

A mio parere, non è necessario preoccuparsi di ciò che gli altri pensano del tuo codice se ti concentri su misure oggettive della sua qualità. È

• Corretto?
• Comprensibile?
• mantenibile?
• efficiente?

Come primo principio, dovrebbe sempre essere il tuo obiettivo concentrarti sulle qualità oggettive, piuttosto che sulle opinioni altrui. Concentrarsi sulle opinioni degli altri è la via della mediocrità e, come tu stai vivendo, dell'ansia.

L'unica ragione per preoccuparsi delle opinioni degli altri è essere in grado di integrarsi bene socialmente (o in un ambiente di lavoro) con loro. Se hai in prima linea nella tua mente l'obiettivo di migliorare le qualità oggettive del tuo lavoro, allora non c'è bisogno di sentirsi spaventato dalle reazioni degli altri - sono solo opportunità di imparare o, nel peggiore dei casi, dettagli pratici da affrontare .

Sii fedele a te stesso !! Continua a imparare e goderti quello che fai.

Mi ricordi di me stesso dopo essere andato all'università per diventare un ingegnere del software. Se vuoi essere un programmatore, direi prendere una posizione. Avrai bisogno di commentare il tuo codice, scrivere test unitari, capire, completamente, codice orientato agli oggetti. Ma in questo momento non hai una vera ragione per farlo. Finché stai solo lavorando su piccoli progetti personali. Dove non devi rispondere a nessuno tranne te stesso. Non crescerai ulteriormente come sviluppatore.

Assumendo progetti di grandi dimensioni su cui molte persone stanno lavorando e dovendo rispondere a domande sulla gestione come "Questo bug di rilascio è gratuito? Perché lo stiamo rilasciando al cliente". Crescerai come programmatore / ingegnere. Otterrai dei colpi duri. Potresti trovare le cose che hai menzionato più di valore e potresti trovare cose nuove che nessuno ha mai visto prima. Crescerai.

Anche il mio college non è riuscito a insegnarmi queste cose anche se ci hanno provato.

Per i test unitari cerca lo sviluppo guidato da test.

Per i commenti, pensa al codice che hai scritto dopo che te ne sei andato. E il tempo che gli altri impiegheranno per decodificarlo.

Per le lingue orientate agli oggetti. Comprendilo almeno. È uno strumento che puoi utilizzare per risolvere i problemi in modo più leggibile.

Good Luck: D

In breve, il modo migliore per imparare è generalmente uscire con qualcuno che puoi imparare da . Se ritieni che le tue capacità non siano all'altezza, uscire con persone che sono migliori di te è il meglio che puoi fare. Sicuramente molto meglio che ritirarti e isolarti ulteriormente.

Tuttavia, penso che dipingete un'immagine molto semplificata e fuorviante. Lontano da tutti i programmatori "istruiti professionalmente" sono davvero buoni. Solo perché fanno qualcosa non significa necessariamente che sia la cosa giusta da fare.

E molto (ma non tutti) di quello che stai dicendo suona davvero come se tu potessi insegnare a loro un trucco o due.

I lean to the Functional side more than OO, but I see the use of OO when something would make more sense as an abstract entity.

Mi sembra grandioso. I migliori programmatori sono quelli che usano lo strumento giusto per il lavoro. Prenderò sempre qualcuno che conosce entrambi i paradigmi, e li usa ognuno dove ha senso per qualcuno che usa religiosamente un solo paradigma.

Next I also go the simple route when doing something. When in contrast, it seems like sometimes the code I see from professional programmers is complicated for the sake of it!

Ancora una volta, la semplicità è buona . Non rendere complesso il tuo codice fino a quando ha bisogno di essere complesso. Alcune persone fanno tendono a rendere le cose complesse da un'idea sbagliata dell'eleganza, o perché "avremo bisogno di questa ulteriore funzionalità in seguito". In generale, è meglio fare la cosa più semplice che risolva il tuo problema.

I use lots of closures. Good. That's why they're there. They do scare some people who got stuck in the 1990's and Java's outmoded quasi-OOP model, but really, that's their problem.

And lastly, I'm not the best commenter.

Cosa dovrebbe essere commentato, e come, è altamente soggettivo. Non c'è vero "giusto" o "sbagliato" lì, ma quando si lavora in un team, è importante scrivere un codice che l'intero team, e non solo l'autore del codice, possa capire. E a volte, devono essere fatti dei compromessi per conformarsi allo stile di codifica della squadra. Ciò non significa necessariamente che dovresti scrivere più commenti, significa semplicemente che è qualcosa su cui tu e il tuo team dovrete concordare.

I hear professionally trained programmers go on and on about things like unit tests. Something I've never used before so I haven't even the faintest idea of what they are or how they work.

Bene, chiedili a loro. :) Test del codice è essenziale, e le unit test sono uno strumento popolare e utile per questo.

Lots and lots of underscores "_", which aren't really my taste.

Come nel commentare, questo è soggettivo e dipende dalla lingua. In C e C ++, lowercase_with_underscores è una convenzione di denominazione abbastanza comune. In molte altre lingue, non vedresti praticamente mai un trattino basso. Ma alla fine, non è davvero importante. Se una funzione è chiamata write_to_log o WriteToLog , in realtà non farà alcuna differenza. Qualcuno dovrà limitarsi a succhiarlo e conformarsi a ciò che il team ha concordato lì.

Don't know anything about MVC, I've heard a lot about it though with things like backbone.js. I think it's a way to organize an application. It just confuses me though because by now I've made my own organizational structures.

Come con i test unitari, non smettere mai di imparare. Collabori con persone che sanno cose che non conosci e che provengono da un contesto diverso da quello che hai. Impara dagli altri. Ci sono chiaramente cose che puoi insegnare loro, ma ci sono anche cose che non conosci, o che non hai mai sentito, che possono insegnarti. Ciò non significa che tu (o loro) sia un cattivo programmatore. Significa che un buon programmatore è colui che si sforza di migliorare e di imparare dagli altri.

Complete OO programming really leaves a bad taste in my mouth

Lo stesso qui, e io sono quello che chiameresti "professionalmente preparato" (un diploma CS). Le persone a cui è stata insegnata la programmazione differiscono tanto quanto le persone autodidatte. Sembra che tu stia lavorando con qualcuno che ha davvero bisogno di imparare alcuni nuovi trucchi.

In fact I'm rather scared of the fact that people will eventually be checking out my code. Is this just something normal any programmer goes through or should I really look to change up my techniques?

Entrambi. Ovviamente è spaventoso vedere gli altri (e giudicare) ciò che hai fatto. Ma è anche molto educativo. Possono dirti cosa avrebbero fatto altrimenti, o perché l'avrebbero fatto diversamente. Possono aiutarti a migliorare e potrebbero anche imparare qualcosa da soli. Mostra loro il codice che risolve un problema meglio della loro soluzione "preferita", e speriamo che vadano "oh, è pulito. Come sapevi farlo? Come si chiama? Dovrei usare questa tecnica da solo "

Questa non è una risposta completa, ne hai già presi parecchi. Tuttavia, ci sono un paio di punti che mi sembrano un po 'confusi e non sono stati affrontati.

It's a mixture of several things I do. I tend to blend several programming paradigms together. Like Functional and OO. I lean to the Functional side more than OO, but I see the use of OO when something would make more sense as an abstract entity. Like a game object.

A me sembra che tu stia confondendo dichiarativo contro imperativo programmazione, piuttosto che Functional Vs Object Oriented programming. Se intendi che ti appoggi alla programmazione dichiarativa e lontano dall'imperativo, allora questa è una buona cosa. Il dichiarativo cerca di rimuovere gli effetti collaterali, che dovrebbero rendere il codice più facile da capire.

I linguaggi di programmazione moderni spesso supportano il modello di programmazione dichiarativa. Ad esempio, in C #, l'utilizzo di Linq ha come risultato uno stile dichiarativo, perché non stai dicendo come ottenere ciò che vuoi; stai solo dicendo quello che vuoi.

Complete OO programming really leaves a bad taste in my mouth, yet that seems to be what EVERYONE else is strictly using.

Le lingue moderne sono spesso lingue multi-paradigma. È raro che qualcuno usi un linguaggio "puro". Molti linguaggi funzionali supportano oggetti ed effetti collaterali. Le lingue considerate orientate agli oggetti spesso non impongono il vincolo che tutto sia un oggetto.

Che cosa intendi per OO completo? Non ho mai lavorato al codice OO "puro". Forse puoi darci qualche dettaglio in più su ciò che non ti piace. Un'illustrazione da un progetto open source potrebbe essere d'aiuto.

I programmi OO ci offrono molte funzionalità per supportare cose come: astrazione dati, incapsulamento, messaggistica, modularità, polimorfismo ed ereditarietà. Se guardassi un codice base che non ne approfittava, mi lasciava l'amaro in bocca.

Risposta breve: sì.

Insegnare te stesso è quasi tutto buono.
Filtrare con buon senso, buon consiglio.

WRT apprendimento programmazione professionale, sì.
Che cosa hai in mente?
Conferenze, seminari, certificazione, una laurea?
Ognuno ha un costo / beneficio.
Quando il ROI è buono, se hai le risorse, vai a farlo.

Valutare i gradi in base alla fonte: le persone con / senza di loro hanno interessi acquisiti.
Parla con una mezza dozzina di ciascuno.

Il mondo accademico è isolato dall'industria? Spesso.
Una laurea è inutile? Dollaro saggio, difficile da discutere.
I laureati guadagnano quasi sempre più soldi, ma fai attenzione ai prestiti del college.

La conoscenza-saggio? Forse.
Se odi la scuola, non otterrai più di quello che hai messo.

Se ritieni che una laurea sia un obiettivo degno per te, probabilmente lo è.

Scava più in profondità e scopri il programma di studio, i costi, l'ambiente. Assicurati di avere interesse, impegno, tempo e risorse. Probabilmente sei andato a scuola per tredici anni, quindi cosa sono gli altri quattro? Saranno i più costosi e la persona principale su cui farai affidamento per renderli i più preziosi sei tu.

I costi possono essere piuttosto spaventosi, ma raccontano solo una parte della storia perché ci sono molte borse di studio e sovvenzioni per merito, necessità e cento altri motivi.

Se vai, scegli i prof e boccioli intelligenti.

Seconda domanda: posso utilizzare il mio stile?

Hai due domande.

Il primo è nel tuo titolo. Si prega di consultare la mia risposta precedente.

Il secondo è dettagliato in circa cinque paragrafi in cui descrivi come il tuo stile differisce dallo stile professionale con i punti elencati di seguito:

• 100% autodidatta.
• Diversi nella tecnica e organizzazione.
• Miscela di funzionale e orientata agli oggetti.
• Meno complicato.
• Un sacco di chiusure.
• Alcuni commenti.
• Nessun test unitario.
• Pochi underscore.
• No MVC.
• No backbone.js.
• Nessuna applicazione modello.

Riassumendo, penso che tu stia chiedendo se va bene che usi l'approccio di Frank Sinatra - "L'ho fatto a modo mio". Sento l'ambivalenza quando chiami il codice professionale di altre persone, ma non ne sei all'altezza. Lo stile è un problema personale e il dibattito su ciò che è buono è un codice infinito e spesso una perdita di tempo. Alcuni problemi potrebbero essere più semplici se il tuo gruppo utilizza una convenzione di codifica scritta. Per favore controlla:

link

C'è un'etichetta per uccidere il codice di qualcun altro, e questa è un'altra cosa su cui dovresti lavorare con il tuo team. Metti la tua pelle spessa e spera che non siano troppo brutali, ma qualunque cosa tu faccia, non andare in guerra.

Hai commentato l'ansia per gli altri che hanno visto il tuo codice. Preparati perché non solo lo vedranno, ma lo riscriveranno e ti diranno cosa c'è di sbagliato nel tuo stile. I tuoi colleghi possono essere flessibili o rigidi. Ad ogni modo, ti consiglio di non riscrivere il loro codice per stile o rendere ogni trattativa di stile una negoziazione.

Le ragioni per avere un codice uniforme (e una formazione uniforme) sono di aumentare la velocità e la produttività dello sviluppo e, in qualche modo, istituzionalizzare l'apprendimento delle migliori pratiche. Problemi come camelCase o use_underbars possono sembrare banali e insignificanti, ma ci sono benefici per la coerenza.

Si prega di essere aperti ai test unitari e allo sviluppo basato sui test. Quando sei da solo, non fa parte del fare progetti a pagamento, è più come un hobby. Le tue cose non hanno bisogno di adattarsi a ciò che fanno gli altri. Se il tuo codice si blocca, non è un grosso problema. Ma quando sei coinvolto in una squadra, il codice che scrivi può influenzare l'intero team, in particolare se arriva ai clienti.

Allo stesso modo, se il tuo team utilizza MVC, ti preghiamo di informarti, si spera, dalle stesse fonti a cui si riferiscono. I metodi di strutturazione dei programmi possono fare un'enorme differenza, come è stato dimostrato dall'esperimento. Ancora una volta, prendi l'esempio e la guida della tua squadra.

Se il tuo team utilizza backbone.js, lo usi anche tu. La tua squadra è come le anatre che volano in formazione. Mettersi in fila insieme aiuta a spendere meno energia, a renderli più sicuri e li aiuta a raggiungere il punto in cui stanno andando più efficacemente. L'analogia si interrompe se la si spinge molto, ma ci sono grandi vantaggi nell'usare strumenti, tecniche e allineamenti comuni dietro le decisioni dei team.

Il consiglio dato è abbastanza utile, ma cerco di ricordare che il mio obiettivo principale è creare un "software di lavoro" che sia utile per i miei utenti. Di solito il mio pubblico NON è un gruppo di programmatori: sono imprenditori disposti a pagare per una soluzione automatizzata (agli utenti non interessano le metodologie OO, i framework, i test delle unità, i commenti al codice, ecc. appeso su di esso.)

Ho trovato gli ideali del Manifesto Agile utili nella mia carriera (www.agilemanifesto.org)

• Individui e interazioni su processi e strumenti
• Software di lavoro su documentazione completa
• Collaborazione con il cliente per la negoziazione del contratto
• Risposta al passaggio successivo a un piano

Sono completamente correlato a questa domanda. Ho esattamente gli stessi sentimenti e uno sfondo molto simile (ma non esattamente lo stesso). Dovrei essere formato professionalmente (o meglio accademicamente) quindi dovrei sapere della programmazione OO ecc. La programmazione non era il mio argomento principale, ma l'ho fatto. Ho imparato OO in alcuni dei miei corsi e non ho mai capito la ragione d'essere. Infatti, l'unica volta che ho capito OO è stato quando ho fatto un lavoro commerciale e sono stato costretto da due grandi mentori.

Sono sicuro che il mio professore è stato altrettanto geniale, ma vedi il vero vantaggio nella pratica in un ambiente commerciale rispetto alla programmazione funzionale ma non hai la possibilità di vederlo in un corso progettato per funzionare, insegnare e terminare all'interno pochi mesi. Non ho avuto la possibilità di lavorare sulla struttura basata su MVC ma sono sicuro che sarà lo stesso, cioè potrei essere in grado di riprendere i concetti che funzionano da un libro, ma capirò il suo vantaggio quando lo vedrò in uso in un ambiente commerciale. E sono totalmente d'accordo con te, perché usare OO e MVC e qualsiasi altra struttura complessa se riesci a risolvere un problema in modo più semplice. Il mio consiglio è di non essere timido di lavorare perché ti esporrà a situazioni diverse e ti permetterà di capire le stesse cose sotto una luce diversa.

Certo, ho imparato la sintassi e i concetti nel mio background accademico, ma è nel mondo commerciale in cui ho iniziato a imparare a programmare.