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


36

Ultimamente ho avuto un lavoro professionale, ho frequentato altri programmatori e fatto amicizia nel settore. L'unica cosa è che sono autodidatta al 100%. Ha causato il mio stile a deviare estremamente dallo stile di quelli che sono adeguatamente formati. Sono le tecniche e l'organizzazione del mio codice che sono diverse.

È una miscela di diverse cose che faccio. Tendo a fondere insieme diversi paradigmi di programmazione. Come funzionale e OO. Mi appoggio al lato funzionale più di OO, ma vedo l'uso di OO quando qualcosa avrebbe più senso come entità astratta. Come un oggetto di gioco. Poi vado anche sulla strada semplice quando faccio qualcosa. Al contrario, a volte sembra che il codice che vedo dai programmatori professionisti sia complicato per il gusto di farlo! Uso molte chiusure. E, infine, non sono il miglior commentatore. Trovo più semplice leggere il mio codice piuttosto che leggere il commento. E la maggior parte dei casi finisco per leggere il codice anche se ci sono commenti. Inoltre mi è stato detto che, grazie alla semplice scrittura del mio codice, è molto facile leggerlo.

Sento programmatori addestrati professionalmente andare avanti e avanti su cose come i test unitari. Qualcosa che non avevo mai usato prima, quindi non ho nemmeno la più pallida idea di cosa siano o come funzionano. Un sacco di caratteri di sottolineatura "_", che non sono proprio i miei gusti. La maggior parte delle tecniche che utilizzo sono dirette da me o da alcuni libri che ho letto. Non so nulla di MVC, ne ho sentito parlare molto con cose come backbone.js. Penso che sia un modo per organizzare un'applicazione. Mi confonde però perché ormai ho creato le mie strutture organizzative.

È un po 'un dolore. Non riesco affatto a usare le applicazioni modello quando imparo qualcosa di nuovo come con Ubuntu's Quickly. Ho difficoltà a capire il codice che posso dire proviene da qualcuno addestrato. La completa programmazione OO lascia davvero un cattivo gusto in bocca, eppure sembra essere quello che TUTTI gli altri usano rigorosamente.

Non mi ha lasciato così sicuro nell'aspetto del mio codice o mi chiedo se causerò scintille quando mi unirò a un'azienda o magari contribuirò a progetti open source. In realtà sono piuttosto spaventato dal fatto che le persone alla fine controlleranno il mio codice. È solo qualcosa di normale che passa ogni programmatore o dovrei davvero cercare di cambiare le mie tecniche?


2
Nessuno è diventato uno sviluppatore solido in una settimana / mese. Ci vuole tempo per imparare a consegnare il codice in uno stile affidabile e mantenibile. Diventerai sicuramente uno "sviluppatore di rock star" se manterrai la tua fase di apprendimento e sarai curioso di sapere come fare le cose meglio!
EL Yusubov,

11
Dovresti essere consapevole che il software di produzione tende a sopravvivere al suo autore originale - essere in grado di scrivere codice che altre persone possono capire per mantenere è un'abilità molto importante. Incoraggia gli altri a leggere il tuo codice e dirti cosa ne pensano, e imparare da esso.

1
"estremamente deviare dallo stile di coloro che sono adeguatamente addestrati" dove diavolo è questo posto? Mai una volta ho trovato un laureato adeguatamente addestrato.
Reactgular,

2
Sarei felice di lavorare con più persone che hanno capito le chiusure, e tanto meno pensato di pensare all'utilizzo della programmazione funzionale ...
Izkata,

Fino a quando si lascia che altri programmatori / datori di lavoro sanno il tuo background si dovrebbe andare bene. C'è una differenza tra essere autodidatta e non scrivere codice come qualcuno ben addestrato, ed essere addestrato e non scrivere codice come altri che hanno una formazione simile.
Pureferret

Risposte:


62

In realtà sono piuttosto spaventato dal fatto che le persone alla fine controlleranno il mio codice.

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 intere carriere per se stesse. C'è molto da imparare e da sapere, e quando lavori con altri programmatori, ci saranno sempre cose che sai che non fanno e cose che sanno di no. Questa è una buona cosa.

Se sei preoccupato che la tua esperienza sia incompleta, ci sono molti passaggi che puoi adottare per modificarlo attraverso l'educazione formale e la collaborazione con esperti qualificati. Ma sembra che tu abbia paura che ci sia un traguardo quantificabile dopo il quale la gente dice "Okay, ora che l'ho padroneggiato, sono ufficialmente un programmatore". Non esiste un traguardo simile. Ho avuto sicuramente dei momenti in cui ho pensato "sì, ora sto arrivando da qualche parte" dopo aver appreso qualcosa di nuovo, ma non esiste un elenco magico di cose che devi sapere e fare per definirti un programmatore.

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

Prendi l'inventario delle tue capacità, dei tuoi punti di forza e di debolezza. Ricevi feedback da persone con più esperienza di te. Cerca posizioni che si allineano abbastanza bene a dove pensi di essere, ma non aver paura di cercare un lavoro che è un po 'al di fuori della tua attuale padronanza. Se accetti solo lavori di cui sai già tutto, non imparerai mai al lavoro.


44
Un programmatore è qualcosa che impari costantemente ad essere . Dovrei forse tradurre questo in cinese e farne un tatuaggio?
Radu Murzea,

1
@SoboLAN Ti do il mio permesso per farlo. Voglio delle foto, però!
Asfallows

2
codereview.stackexchange.com è l'unico sito web che conosco di persona, anche se sono sicuro che ce ne sono altri. C'è molto valore nel chiedere a qualcuno di rivederlo personalmente e di parlarne uno a uno, comunque. Forse c'è un college / università vicino a te con un professore amichevole che sarebbe disposto a incontrarti? Questa è la cosa migliore che mi viene in mente sul posto - forse altri avranno idee migliori.
Asfallows

1
A mio avviso, il vero test è se hai un codice di spedizione che altri usano effettivamente.

4
@ ThorbjørnRavnAndersen: e la prima volta che ti rendi conto che le persone stanno effettivamente usando ciò che hai prodotto può essere molto spaventoso all'inizio. E molto potenziante in seguito. E poi di nuovo spaventoso, quando trovi quel grosso errore che hai commesso ;-)
Joachim Sauer,

16

Quando inizi a sviluppare applicazioni in collaborazione con altri sviluppatori, alcuni di questi problemi di stile personale si metteranno di mezzo.

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

A meno che il tuo stile di programmazione non sia estremamente evidente, ti conviene abituarti 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, acquista un buon libro. Ci sono molti buoni libri sui test unitari là fuori. Lo stesso con MVC.

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


5

La programmazione ha una componente artistica e una componente disciplinare. La componente artistica sta nel concepire 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 diverte. Naturalmente, questa è la parte che ti insegni per primo.

La componente disciplina è più di un fastidio: lo fai per necessità. È una componente vitale del lavorare in gruppo, però: non puoi allontanarti dal farlo, almeno in una certa misura. Una volta che il tuo codice è integrato con quello dei tuoi compagni di squadra, la tua flessibilità di "cambiare le cose a piacimento" fa un tuffo nel naso. Tuttavia, è necessaria la possibilità di modificare il codice in modo sicuro in risposta ai requisiti in evoluzione o di correggere i bug. È qui che entrano in gioco vari test "noiosi": con molti test in atto, è facile controllare se la tua ultima modifica si interrompe o meno.

Anche lo stile del codice acquista importanza, perché aderire 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 ti inviano via e-mail avvisi spiacevoli quando ti allontani.

Tornando alla tua domanda, concentrarsi sulla componente artistica è una fase iniziale naturale dello sviluppo del programmatore. Possono essere necessari diversi anni di lavoro nel settore prima di iniziare ad apprezzare la componente disciplina. Non è necessario cercare attivamente di "cambiare le tue tecniche", tuttavia: si trasformeranno naturalmente nel processo di lavoro in gruppo.


3

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

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

È fantastico che tu stia notando aree in cui fai qualcosa di diverso dagli altri, specialmente quando vedi che è uno standard. Hai individuato Unit Testing e MVC - e ora il passo successivo deve essere quello di conoscerli. Scopri come funzionano, di cosa hai bisogno per implementarli e prova a capire quando è una buona progettazione implementarli.

Questo è un campo in continua evoluzione con nuove lingue e modelli che aumentano e diminuiscono. Se ti senti a tuo agio con l'aspetto del codice, inizia a esaminare la parte di progettazione. Scopri cosa li rende buoni e quando usarli.

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


2

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

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

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


2

In realtà sono piuttosto spaventato dal fatto che le persone alla fine controlleranno il mio codice. È solo qualcosa di normale che passa ogni programmatore o dovrei davvero cercare di cambiare le mie tecniche?

Come faresti a sapere cosa cambiare senza un feedback da parte di programmatori più esperti?

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


2

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

La padronanza è meno sull'apprendimento di tutto / cosa / c'è da imparare, e di più 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 sei tra concerti pagati, prendi un giocattolo personale. Tempo libero un fine settimana? Lavora attraverso il 'ciao mondo' per una lingua o una 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 database orientati alle colonne. Otterrai anche una buona dose di stile Google "professionale".

Un buon generale sa come applicare le sue tattiche apprese e l'esperienza raccolta su una varietà di terreni. Sembra che tu abbia qualche tattica ed esperienza, ma devi incontrare un terreno sconosciuto. Questo è probabilmente il modo migliore per accertare ciò che sai e ciò che devi imparare dopo.

E se lo stile "professionale" è ciò che cerchi, affronta alcuni progetti "professionali". Trova un progetto open source che ti piace, assegnati una modifica da apportare e impostalo. Preparati per i revisori dei cretini, ma ricorda che la maggior parte delle persone in questo campo non è arrivata dove sono per avere abilità sociali fluide. Il punto è esporsi al massimo di ciò che vuoi essere il più possibile. E devi costruirti abbastanza bene per farlo da solo. Nessuna lezione può davvero insegnarti. In effetti, oggi c'è troppo dannatamente apprendimento delle lezioni in corso, e non abbastanza solida competenza nel mondo reale.


Grazie Johnny per aver reso la tua prima risposta pubblicata e benvenuto nel gruppo di programmatori su Stack Exchange. Consulta queste linee guida utili per domande e risposte sui siti di Stack Stack: programmers.stackexchange.com/questions/how-to-answer - DeveloperDon
DeveloperDon

1

Non mi ha lasciato così sicuro nell'aspetto del mio codice o mi chiedo se causerò scintille quando mi unirò a un'azienda o magari contribuirò a progetti open source. In realtà sono piuttosto spaventato dal fatto che le persone alla fine controlleranno il mio codice. È solo qualcosa di normale che passa ogni programmatore o dovrei davvero cercare di cambiare le mie tecniche?

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

  • Corretta?
  • Comprensibile?
  • Gestibile?
  • Efficiente?

Come primo principio, dovrebbe sempre essere il tuo obiettivo focalizzarti sulle qualità oggettive, piuttosto che sulle opinioni degli altri. Concentrarsi sulle opinioni degli altri è il percorso verso la mediocrità e, come stai vivendo, l'ansia.

L'unica ragione per preoccuparsi delle opinioni degli altri è quella di essere in grado di integrarsi bene socialmente (o in un ambiente di lavoro) con loro. Se hai in testa l'obiettivo di migliorare le qualità oggettive del tuo lavoro, allora non c'è bisogno di avere paura delle reazioni degli altri: sono solo opportunità di apprendimento o, nel peggiore dei casi, dettagli pratici da affrontare .

Sii fedele a te stesso !! Continua ad imparare e goditi ciò che fai.


Grazie Chris per aver reso la tua prima risposta pubblicata e benvenuto nel gruppo Programmers su Stack Exchange. Ho molto rispetto per il tuo modo di pensare. "Quello che la gente dice che non puoi fare, cerchi di scoprire che puoi." Henry David Thoreau. Consulta queste utili linee guida per domande e risposte sui siti di Stack Stack: programmers.stackexchange.com/questions/how-to-answer
DeveloperDon

1

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

Accettando grandi progetti su cui molte persone stanno lavorando e dovendo rispondere a domande di gestione come "Questa versione di bug è libera? Perché la rilasceremo al cliente". Crescerai come programmatore / ingegnere. Avrai dei colpi duri. Potresti trovare le cose che hai menzionato più preziose e potresti trovare cose nuove che nessuno ha mai pensato prima. Crescerai.

Anche il mio college non mi ha insegnato queste cose, anche se ci hanno provato.

Per Unit Testing cercare Test Driven Development.

Per commentare pensa al codice che hai scritto dopo che te ne sei andato. E il tempo che altre persone dedicheranno al reverse engineering.

Per linguaggi orientati agli oggetti. Comprendilo almeno. È uno strumento che è possibile utilizzare per risolvere i problemi in modo più leggibile.

Buona fortuna: D


0

In breve, il modo migliore per imparare è generalmente quello di uscire con qualcuno che si può imparare da . Se ritieni che le tue abilità non siano all'altezza, uscire con persone migliori di te è il meglio che puoi fare. Certamente molto meglio che ritirarsi e isolarsi ulteriormente.

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

E molto (ma non tutto) di quello che stai dicendo sembra davvero che tu sia quello che potrebbe insegnare loro un trucco o due.

Mi appoggio al lato funzionale più di OO, ma vedo l'uso di OO quando qualcosa avrebbe più senso come entità astratta.

Mi sembra fantastico. I migliori programmatori sono quelli che usano lo strumento giusto per il lavoro. Sceglierei sempre qualcuno che conosca entrambi i paradigmi e li usi ciascuno laddove ha senso su qualcuno che utilizza religiosamente un solo paradigma.

Poi vado anche sulla strada semplice quando faccio qualcosa. Al contrario, a volte sembra che il codice che vedo dai programmatori professionisti sia complicato per il gusto di farlo!

Ancora una volta, la semplicità è buona . Non rendere complesso il tuo codice fino a quando non deve essere complesso. Alcune persone non tendono a fare le cose fuori complesso di un'idea sbagliata di eleganza, o perché "Avremo bisogno di questa funzionalità in un secondo momento". In generale, è meglio fare la cosa più semplice che risolva il problema.

Uso molte chiusure. Buono. Ecco perché sono lì. Spaventano alcune persone che sono rimaste bloccate negli anni '90 e il modello quasi-OOP fuori moda di Java, ma in realtà, questo è il loro problema.

E, infine, non sono il miglior commentatore.

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

Sento programmatori addestrati professionalmente andare avanti e avanti su cose come i test unitari. Qualcosa che non avevo mai usato prima, quindi non ho nemmeno la più pallida idea di cosa siano o come funzionano.

Bene, chiediglielo. :) Il test del codice è essenziale e i test unitari sono uno strumento popolare e utile per questo.

Un sacco di caratteri di sottolineatura "_", che non sono proprio i miei gusti.

Come per i commenti, è soggettivo e dipende dalla lingua. In C e C ++, lowercase_with_underscoresè una convenzione di denominazione abbastanza comune. In molte altre lingue, non vedresti mai un carattere di sottolineatura. Ma alla fine, non è davvero importante. Se una funzione viene chiamata write_to_logo WriteToLognon farà effettivamente la differenza. Qualcuno dovrà semplicemente succhiarlo e conformarsi a ciò che la squadra ha concordato lì.

Non so nulla di MVC, ne ho sentito parlare molto con cose come backbone.js. Penso che sia un modo per organizzare un'applicazione. Mi confonde però perché ormai ho creato le mie strutture organizzative.

Come per i test unitari, non smettere mai di imparare. Lavori insieme a persone che sanno cose che non conosci e che provengono da un contesto diverso da quello che sai fare. Impara gli uni dagli altri. Ci sono chiaramente cose che puoi insegnare loro, ma ci sono anche cose che non sai, o di cui non hai mai sentito parlare, 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.

La completa programmazione OO lascia davvero un cattivo gusto in bocca

Lo stesso qui, e io sono ciò che chiamereste "addestrato professionalmente" (un diploma di laurea specialistica). Le persone a cui è stata insegnata la programmazione differiscono tanto quanto le persone che sono autodidatta. Sembra che tu stia lavorando con alcuni che hanno davvero bisogno di imparare alcuni nuovi trucchi.

In realtà sono piuttosto spaventato dal fatto che le persone alla fine controlleranno il mio codice. È solo qualcosa di normale che passa ogni programmatore o dovrei davvero cercare di cambiare le mie tecniche?

Tutti e due. Ovviamente è spaventoso vedere gli altri guardare (e giudicare) ciò che hai fatto. Ma è anche molto istruttivo. Possono dirti cosa avrebbero fatto altrimenti, o perché avrebbero fatto diversamente. Possono aiutarti a migliorare e potrebbero anche imparare qualcosa da soli. Mostra loro il codice che risolve un problema meglio di quanto avrebbe fatto la loro soluzione "preferita", e speriamo che vadano "oh, è pulito. Come hai fatto a saperlo? Come si chiama questo? Dovrei usare questa tecnica da solo "


0

Questa non è una risposta completa, ne hai già molte buone. Tuttavia, ci sono un paio di punti che per me sembrano un po 'confusi e non sono stati affrontati.

È una miscela di diverse cose che faccio. Tendo a fondere insieme diversi paradigmi di programmazione. Come funzionale e OO. Mi appoggio al lato funzionale più di OO, ma vedo l'uso di OO quando qualcosa avrebbe più senso come entità astratta. Come un oggetto di gioco.

Per me sembra che tu sia confuso dichiarativo contro imperativo programmazione , piuttosto che funzionale rispetto alla programmazione orientata agli oggetti. Se vuoi dire che ti inclini alla programmazione dichiarativa e lontano dall'imperativo, allora è una buona cosa. Dichiarativo cerca di rimuovere gli effetti collaterali, che dovrebbe facilitare la comprensione del codice.

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

La completa programmazione OO lascia davvero un cattivo gusto in bocca, eppure sembra essere quello che TUTTI gli altri usano rigorosamente.

Le lingue moderne sono spesso linguaggi 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.

Cosa intendi con OO completo? Non ho mai lavorato su un codice OO "puro". Forse puoi darci qualche dettaglio in più su ciò che non ti piace. Un'illustrazione da un progetto open source potrebbe aiutare.

La programmazione OO ci offre molte funzionalità per supportare cose come: astrazione dei dati, incapsulamento, messaggistica, modularità, polimorfismo ed eredità. Se guardassi una base di codice che non ne approfittava, mi avrebbe lasciato un cattivo gusto in bocca.


Perché il downvote?
Dave Hillier,

0

Risposta breve: si.

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

WRT apprendimento programmazione professionale, sì.
Cos'hai in mente?
Conferenze, seminari, certificazione, una laurea?
Ognuno ha un costo / beneficio.
Quando il ROI è buono, se hai le risorse, provaci.

Valutare i consigli sui gradi considerando la 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 è senza valore? Dal punto di vista del dollaro, difficile da discutere.
I laureati fanno quasi sempre più soldi, ma attenzione ai prestiti universitari.

La conoscenza-saggio? Può essere.
Se odi la scuola, non otterrai più di quanto tu abbia inserito.

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

Scavare più a fondo e scoprire 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 quali sono 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 borse di studio per merito, necessità e cento altre ragioni.

Se vai, scegli prof e gemme intelligenti.


0

Seconda domanda: posso usare il mio stile?

Hai due domande.

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

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

  • Autodidatta al 100%.
  • Diversi per tecnica e organizzazione.
  • Miscela di funzionale e orientata agli oggetti.
  • Meno complicato
  • Molte chiusure.
  • Pochi commenti
  • Nessun test unitario.
  • Pochi trattini bassi.
  • No MVC.
  • No backbone.js.
  • Nessuna applicazione modello.

Riassumendo, penso che tu stia chiedendo se va bene che usi l'approccio Frank Sinatra - "L'ho fatto a modo mio". Sento l'ambivalenza mentre chiami il codice degli altri professionisti, ma non sei d'accordo. Lo stile è una questione personale appiccicosa e il dibattito su ciò che è un buon codice è infinito e spesso una perdita di tempo. Alcuni problemi potrebbero essere più semplici se il tuo gruppo utilizza una convenzione di codifica scritta. Si prega di verificare:

http://en.wikipedia.org/wiki/Coding_conventions

C'è un galateo nell'uccidere il codice di qualcun altro, e questa è un'altra cosa su cui dovresti lavorare con la tua squadra. 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 che gli altri vedessero 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 di rendere ogni punto di stile una trattativa.

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 meschini, ma ci sono vantaggi per la coerenza.

Si prega di essere aperti ai test unitari e allo sviluppo guidato dai test. Quando sei solo, non fai parte di progetti a pagamento, è più come un hobby. Le tue cose non devono combaciare con quello che fanno gli altri. Se il tuo codice si arresta in modo anomalo, non è un grosso problema. Ma quando sei coinvolto in una squadra, il codice che scrivi può influenzare l'intera squadra, in particolare se arriva ai clienti.

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

Se il tuo team utilizza backbone.js, lo usi anche tu. La tua squadra è come anatre che volano in formazione. Allinearsi insieme li aiuta a consumare meno energia, li rende più sicuri e li aiuta ad arrivare dove stanno andando in modo più efficace. L'analogia si interrompe se la spingi molto, ma ci sono grandi vantaggi nell'usare strumenti, tecniche e allineamenti comuni dietro le decisioni dei team.


0

Il consiglio dato è abbastanza utile, ma provo a ricordare che il mio obiettivo principale è quello di creare un "software funzionante" utile per i miei utenti. Il mio pubblico di solito NON è un gruppo di programmatori: sono uomini d'affari disposti a pagare per una soluzione automatizzata (gli utenti non si preoccupano di metodologie OO, framework, test unitari, commenti di codice, ecc. Quindi non capisco troppo ha riattaccato.)

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

  • Individui e interazioni su processi e strumenti
  • Software funzionante su documentazione completa
  • Collaborazione con i clienti sulla negoziazione del contratto
  • Rispondere al cambiamento seguendo un piano

0

Mi riferisco completamente a questa domanda. Ho esattamente gli stessi sentimenti e uno sfondo molto simile (ma non esattamente lo stesso). Dovrei essere addestrato professionalmente (o piuttosto accademicamente), quindi dovrei conoscere la 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 capito la ragione d'etre. Infatti, l'unica volta che ho capito OO è stato quando ho fatto un lavoro commerciale e sono stato costretto a farlo da due grandi mentori.

Sono sicuro che il mio professore sia stato altrettanto brillante ma vedete il vero vantaggio nella pratica in un ambiente commerciale rispetto alla programmazione funzionale, ma non avete la possibilità di vederlo in un corso progettato per funzionare, insegnare e terminare entro 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 raccogliere i concetti che lavorano da un libro, ma ne comprenderò i vantaggi quando lo vedo 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 un modo più semplice. Il mio consiglio è di non essere timido 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 che ho iniziato a imparare a programmare.


Non c'è sostituto per l'esperienza del mondo reale, non importa quanto sia buono l'insegnamento
Andrew,
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.