Differenze tra programmazione a scuola e programmazione nell'industria? [chiuso]

Molti studenti quando si laureano e ottengono il loro primo lavoro, sentono di non sapere davvero come programmare, anche se potrebbero essere stati dei bravi programmatori al college.

Quali sono alcune delle differenze tra la programmazione in un ambiente accademico e la programmazione nel "mondo reale"?

In un tradizionale programma di informatica non impari solo la programmazione. Ma il mondo reale non vuole persone che sono solo programmatori. Il mondo reale vuole veri ingegneri del software. So che molte descrizioni di lavoro non sembrano esprimere questa distinzione, che confonde solo la questione. Nel mondo reale devi essere in grado di:

• Raccogli e analizza i requisiti quando non ti vengono dati direttamente
• Progetta e analizza l'architettura con possibilità pressoché infinite
• Creare piani di test e agire su di essi per valutare e migliorare la qualità di un sistema
• Lavora in collaborazione con un team di persone con background e livelli di esperienza diversi
• Stima e pianifica il lavoro anche se non sai esattamente cosa costruire
• Comunicare efficacemente con le parti interessate che hanno esigenze diverse che non si allineano necessariamente
• Negozia programma, budget, qualità e funzionalità senza deludere le parti interessate

Oh sì, e devi anche essere in grado di scrivere codice, anche se ciò richiede, in media, solo il 40 - 60% del tempo di un ingegnere del software.

Quindi, non è che gli studenti di informatica appena coniati non sappiano programmare (molti sono in realtà programmatori molto bravi). È che molti di loro non sanno come fare nient'altro.

All'università...

Il tuo insegnante ti offre:

• Un problema ben definito e isolato, la cui soluzione può essere fornita in un arco di tempo breve e ben definito (e verrà scartata in seguito)
• Un set di strumenti ben definito a cui è stata introdotta prima dell'assegnazione
• Una misura ben definita per la qualità della tua soluzione, con la quale puoi facilmente determinare se la tua soluzione è abbastanza buona o no

Nel mondo reale"...

• Il problema è sfocato, complesso e integrato nel contesto. È un insieme di requisiti contraddittori che cambiano nel tempo e la tua soluzione deve essere abbastanza flessibile e robusta per poter reagire a tali cambiamenti in un tempo accettabile.
• Gli strumenti devono essere scelti da te. Forse c'è già qualcosa di utilizzabile nella base di codice di 10 anni del tuo team, forse c'è qualche progetto open source, o forse una biblioteca commerciale o forse dovrai scriverlo da solo.
• Per determinare se l'attuale iterazione del tuo software è un miglioramento (perché non hai quasi mai effettivamente fatto un progetto software), devi fare test di regressione e test di usabilità, quest'ultimo dei quali di solito significa che lo sfocato, il complesso, il contraddittorio , i requisiti integrati nel contesto cambiano ancora una volta.

Conclusione

La programmazione a scuola e la programmazione nel mondo reale sono così intrinsecamente diverse dal punto in cui in realtà vi è davvero poca sovrapposizione. CS ti preparerà per lo sviluppo del software "mondo reale" come l'allenamento di atletica preparerebbe un esercito per la battaglia.

Si trovano ad affrontare un aspetto diverso del problema:

Il mondo accademico si concentra principalmente sulla "scienza della programmazione", studiando in tal modo il modo di rendere efficiente un algoritmo particolare o sviluppando linguaggi su misura per rendere più espressivi alcuni paradigmi. L'industria si concentra principalmente nella produzione di oggetti che devono essere venduti. Deve fare affidamento su "strumenti" che non sono solo i linguaggi e gli algoritmi, ma anche le librerie, i framework ecc.

Questa differenza di "focus" è ciò che rende un master accademico in C praticamente incapace di scrivere un'applicazione Windows (poiché noi API di Windows non siamo nello standard C99!), Sentendosi così "incapace di programmare". Ma, in effetti, ha tutte le capacità per imparare da solo ciò che gli manca. Qualcosa che - senza studi accademici adeguati (non necessariamente realizzati in Academia) - è piuttosto difficile da trovare.

Buone risposte. Consentitemi di aggiungere che la programmazione accademica tende ad essere quasi simile a quella di un giocattolo. Questo è buono per insegnare. Come insegnante, stai cercando di trasmettere idee in modo più efficiente. L'aspetto negativo è che la programmazione realistica è così qualitativamente diversa, che è difficile colmare il divario.

Un'area di differenza è nell'analisi delle prestazioni. Ho scritto molti post cercando di evidenziarlo. L'analisi delle prestazioni riguarda solo superficialmente algoritmi e misurazioni. Per farlo davvero in modo efficace, devi affrontarlo come un processo di debug.

Un'altra area di differenza è la manutenibilità. Questo comprende tutto, dallo stile al design del linguaggio specifico del dominio. Non puoi farlo in modo efficace se non sai davvero cosa stai cercando di minimizzare.

Queste cose non vengono insegnate e fanno un'enorme differenza nella produttività.

Nel mondo accademico, la maggior parte delle persone studia informatica o corsi correlati. Dijkstra una volta osservò che "L'informatica non riguarda più i computer di quanto l'astronomia riguardi i telescopi". Una persona che studia informatica sta innanzitutto imparando a diventare uno scienziato e non un programmatore. Come programmatore, rimarrà un dilettante e il passaggio a un programmatore professionista è di conseguenza difficile.

Aggiornamento: come se qualcuno mi stesse leggendo nella mente: aspettative laureate contro realtà ...

La mia opinione, altri due fattori:

Dimensione del problema : in ambito accademico, dovevo principalmente sviluppare software "da zero", il che significava che il più grande programma che avevo incontrato era il più grande che ho scritto. Ciò sottolinea la capacità necessaria per gestire e far fronte alla complessità che emerge da diversi software che interagiscono insieme. Se fossi consapevole dello sforzo necessario per comprendere con complessità, avrei potuto scegliere di non essere affatto nel settore.

Lettura VS Scrittura : Un altro effetto collaterale della dimensione del problema è che spesso, nel "mondo reale" siamo esposti al lavoro che è stato scritto da altri, sia per scopi di manutenzione (non ho fatto manutenzione in ambito accademico da nessuna parte), estensione o semplicemente divisione del lavoro. Pertanto la lettura del codice diventa molte volte più importante della scrittura.

Una proposta per migliorare l'educazione alla programmazione : il mondo accademico dovrebbe esporci maggiormente alle situazioni del mondo reale senza regredire alla formazione professionale. I dottori devono affrontare un cadavere a un certo punto per vedere se sono "fatti per questo" (ho sentito storie di persone che abbandonano il corso dopo questa esperienza). Se avessi visto nei miei vent'anni un progetto LOC di 20K composto da diversi stili di programmazione, che avrei dovuto capire in un giorno e correggere un bug in tre, avrei potuto prendere in considerazione altre opzioni di carriera - anche se probabilmente no.

La più grande differenza che ho riscontrato tra la programmazione accademica e quella industriale riguarda la robustezza. Quasi tutti hanno sperimentato il paradosso "Funziona per me" nella loro carriera, e questa è un'estensione di questa condizione. In ambito accademico, l'attenzione è rivolta agli algoritmi e alle funzioni e poca attenzione viene posta sull'usabilità e la stabilità del software in condizioni quotidiane.

Ad esempio, nel mio ufficio abbiamo un ingegnere che prenderà il software ed è un maestro nel causare incidenti da condizioni angolari. Farebbe clic su un pulsante il più velocemente possibile fino a quando qualcosa non si blocca ... se un'operazione richiede troppo tempo, inizierà semplicemente a fare clic in modo casuale sullo schermo (per frustrazione? IDK ....)

Cambiare le nostre filosofie di programmazione in modo da rendere le cose "a prova di Steve" ha in generale migliorato la stabilità della nostra applicazione.

Non ho esperienza personale con la formazione di programmazione a scuola - ero un inglese maggiore. Chiedimi di Keats e Byron! - ma ho ricevuto diversi nuovi laureati, li ho cresciuti e li ho seguiti nel mondo dello sviluppo di software professionale. Quindi posso parlare da quella prospettiva.

La mia esperienza è che TUTTO quello che hanno ottenuto dalla loro scuola era un interesse per la programmazione. Le loro abilità variavano da zero a trascurabili. La loro capacità di auto-dirigere era inesistente anche nelle persone più esperte. Il loro pensiero non era solo su piccola scala; pensavano davvero in miniatura. Un sistema che comprende più di una dozzina di righe di codice le ha fatte cadere completamente a pezzi.

Ma sai una cosa? Hanno acquisito un interesse , e questo è un grosso problema. Un interesse è abbondante . Posso lavorare con qualcuno che è interessato. Posso trasformarli in uno sviluppatore, a condizione che vengano da me interessati a esserlo. Inferno, è tutto con cui ho iniziato. Questo e un apprezzamento per i romanzieri americani post-moderni.

Nel mondo accademico,

INCONVENIENTI

• Abbiamo scadenze che sono principalmente per segnare punti.
• I bug non causano davvero problemi, poiché la maggior parte dei progetti non viene mai utilizzata nelle applicazioni del mondo reale.

plus

• Abbiamo tempo a sufficienza per la ricerca.
• Ondeggiare dagli obiettivi iniziali non causa molti problemi.

Nell'industria,

• Lavoriamo su progetti che verranno effettivamente utilizzati dalle aziende.
• Lavoriamo sotto stress per le mutevoli esigenze dei clienti.
• Le scadenze sono raramente flessibili, poiché ciò potrebbe comportare enormi perdite finanziarie sia per la società di software che per i clienti.

Controllalo:

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html

La programmazione accademica riguarda di più la codifica da soli. Questo è importante per imparare come funziona. La qualità del codice e il controllo di revisione non contano molto. Con notevoli eccezioni, il codice non ha una durata oltre l'assegnazione. La portata dei progetti tende ad essere piuttosto limitata e difficilmente si insinua.

Nel mondo reale, dovresti avere il minor codice originale possibile. Un sacco di codice è sviluppato dai team. È meglio usare le routine di libreria piuttosto che codificarlo da soli. La qualità del codice e il controllo di revisione diventano più importanti. Il codice tende ad avere una vita molto al di là di quanto inizialmente previsto. L'ambito del progetto è generalmente piuttosto ampio e tende a insinuarsi in modo significativo se non gestito.

In realtà,

è impossibile distinguere completamente tra programmazione a livello accademico e programmazione nel mondo reale.

Direi che la differenza più grande potrebbe essere questa: nella programmazione del mondo reale - devi sapere più della programmazione e dovresti essere in grado di adattarsi rapidamente.

A seconda del settore in cui lavori, devi essere conforme alle sue leggi.

Michael ha toccato la punta dell'iceberg solo dichiarando compiti relativi alla programmazione, che classificherei come roba facile (se valga l'impasto che ti viene pagato).

In generale, dovrai affrontare almeno un paio di sfide per argomento in un settore:

• Leggi applicabili (es. Riservatezza del cliente per i medici)
• Know-how soggetto (es. Sistema fiscale di fatturazione, inventario, gestione delle risorse, schemi medici, standard di settore)
• Requisiti del cliente mancanti o inesistenti o diversi dagli standard di settore / dalle leggi in vigore

Se si confronta un progetto di programmazione a livello di dottorato di ricerca con uno del mondo reale, è probabile che siano molto simili in difficoltà, know-how di livello di ingresso e simili.

L'unica vera differenza è che il progetto del mondo reale

• ha un cliente
• ha budget (tempo, denaro, risorse umane)

È un gioco con la palla diverso quando qualcun altro stabilisce le regole :)

Se guardi le materie studiate in IT in ambito accademico, troverai circa la metà del tempo sprecato in matematica, scienze, elettivi, ecc. E l'altra metà in materie accademiche come: progettazione di compilatori, teoria degli algoritmi, architettura del computer, Ottimizzazione, sistemi operativi, elettronica digitale e pochi altri corsi relativi all'industria come la programmazione C e la programmazione Web.

La maggior parte delle materie sopra menzionate sono utili da conoscere, ma non forniranno direttamente una solida base in ciò che è richiesto nell'IT corrente.

Soddisfa i requisiti di programmazione Web Microsoft (ovvero, le aree richieste da qualcuno per essere un membro del team produttivo in un'organizzazione):

1- C #. NET o VB.NET

2- ASP.NET

3- HTML e CSS

4- SQL Server (o un altro database)

5- Programmazione e progettazione di applicazioni OO

6- Script Java

7- Quadro MVC

8- Alcune esposizioni agli strumenti di controllo del codice sorgente

9- Alcune esposizioni a strumenti di test automatizzati

Strumento di tracciamento a 10 bug

11 concetti di e-commerce (opzionale)

12-ORM

13-Alcune abilità di analisi aziendale

14-Alcune abilità comunicative

15-Probabilmente, alcuni fondamentali del cloud computing

Come puoi vedere, la maggior parte dei requisiti di cui sopra sono raramente focalizzati (puoi ottenere 1 corso in alcuni al massimo) durante il college / università.

Non si può incolpare completamente le istituzioni poiché ci sono molte pile di tecnologia e continuano a cambiare.

La maggior parte di quanto sopra di Microsoft non aiuterà qualcuno che vuole sviluppare applicazioni in Java.

Il vero problema è che nessuna delle pile tecnologiche che oggi sono necessarie all'azienda viene mai completamente coperta.

Quanto sopra copre la questione dell'idoneità dei laureati a lavori aziendali come la programmazione in ambiente aziendale. Questa esigenza non copre le esigenze di ricerca nei laboratori, ecc. Anche altre aree richiedono più competenze di quanto sopra, come lo sviluppo di giochi, lo sviluppo integrato, lo sviluppo di sistemi in tempo reale, ecc.

Scale & Focus
Dalle mie esperienze, in un ambiente accademico, generalmente la scala dell'applicazione su cui stai lavorando è molto più piccola, qualcosa che può essere completato in un giorno o settimana, o forse fino a quando il semestre di uno o due programmatori- - tipicamente tutto ciò che scrivi sarà un codice usa e getta che verrà scartato dopo il termine. Nel mondo reale, potresti trovarti a lavorare su un'applicazione che un team più grande ha impiegato mesi, se non anni, per svilupparsi completamente. Trascorri molto più tempo e esegui il debug del codice di altre persone e cerchi di capire l'infrastruttura di una base di codice, destreggiandoti senza rompere le parti esistenti per aggiungere alcuni requisiti nuovi o modificati.

Requisiti, integrazione, clienti
Inoltre, ci sono aspetti nello sviluppo del codice, come l'analisi dei requisiti, i test di integrazione, ecc. Che tendono ad essere meno rappresentati nei progetti accademici. Per motivi di equa valutazione, in genere i requisiti sono già stati stabiliti dall'istruttore e non vengono decisi in modo collaborativo durante le riunioni. Non si tende a dover "vendere il cliente" con un approccio particolare che non è proprio quello che volevano, ma a differenza dei loro desideri è in realtà fattibile dal punto di vista tecnico. In un ambiente accademico il tuo cliente (il selezionatore o l'istruttore) tende ad avere un'idea abbastanza concreta di ciò che vuole, nel mondo reale, potresti incontrare clienti che non sanno davvero cosa vogliono e devono scegliere il cervello per capire cosa dovrebbe essere costruito.

Manutenzione e manutenibilità

Nel mondo accademico (almeno a livello universitario), il software è costruito tenendo conto degli obiettivi a breve termine, di solito per completare alcuni compiti a casa o progetti a termine. Una volta completato il compito, il codice viene gettato via e mai più visto.

In un ambiente professionale, la maggior parte dei software è stata scritta pensando all'uso a lungo termine; il software deve essere utilizzato per almeno alcuni anni e deve essere costruito per essere facilmente mantenuto e aggiornato nel tempo.

A questo si collega il lavoro di manutenzione. La maggior parte del lavoro di programmazione professionale prevede l'aggiornamento o la manutenzione di software esistente. I cosiddetti progetti "green-field" sono l'eccezione, piuttosto che la norma.