Perché non insegnano queste cose a scuola? [chiuso]

Durante l'estate, ho avuto la fortuna di entrare in Google Summer of Code. Ho imparato molto (probabilmente più di quanto ho imparato nella somma di tutti i miei corsi universitari). Mi chiedo davvero perché non insegnano alcune delle cose che ho imparato prima a scuola però. Per dirne alcuni:

• unit test
• controllo della versione
• sviluppo agile

Mi sembra che trascorrano una notevole quantità di tempo a insegnare altre cose come strutture dati e algoritmi in anticipo. Anche se penso ancora che siano molto importanti da imparare presto, perché non insegnano più di questi tre prima di loro? O è solo la mia scuola che non insegna molto di queste cose?

Non fraintendetemi, non credo sia auspicabile che le università insegnino sempre le mode di programmazione più alla moda, ma i miei professori non dovrebbero insegnarmi qualcosa di diverso dal "disegnare un diagramma prima di iniziare a programmare?"

La risposta più semplice alla tua domanda è che i campi dell'informatica e dello sviluppo del software sono entrambi molto nuovi e non molto ben compresi. Sebbene tutte le discipline scientifiche e ingegneristiche stiano avanzando più rapidamente nei tempi moderni, altri campi hanno molta più esperienza a cui attingere e c'è una comprensione condivisa molto più ampia di come funzionano.

Ad esempio, nonostante i recenti progressi nella scienza dei materiali, gli ingegneri civili sanno da circa 2000 anni come costruire un arco che non cada, e questo è qualcosa che può essere insegnato e appreso all'università con relativamente poche controversie. Sebbene sia completamente d'accordo con te sulle tecniche che gli sviluppatori di software dovrebbero apprendere, questo accordo si basa sull'esperienza personale e sul ragionamento informale. Per essere una "best practice" socialmente accettata, abbiamo bisogno di dati quantitativi che possono essere molto costosi da raccogliere: quanto aiuta il controllo della versione? Come aiuta? Test unitario? Possiamo ragionare sull'efficacia di varie tecniche, ma in realtà dimostrarne l'efficacia in modo definitivo sarebbe molto costoso. Avremmo bisogno di eseguire un progetto software completo e realistico dall'inizio alla fine, numerose volte, con gruppi di programmatori che hanno competenze equivalenti, utilizzando tecniche diverse. Per lo meno avremmo bisogno di molti dati sui progetti esistenti che quei progetti non sarebbero disposti a rilasciare.

Gli ingegneri civili hanno migliaia di anni di ponti da guardare, con molte informazioni. Gli sviluppatori di software, d'altra parte, hanno solo pochi decenni di informazioni, la maggior parte delle quali è tenuta segreta, poiché c'è poca motivazione per le organizzazioni a raccogliere e pubblicare informazioni sull'efficacia dei loro sviluppatori, anche se le stanno raccogliendo (che la maggior parte non lo sono 't).

C'è anche una certa confusione di campi. Lo sviluppo del software, o "ingegneria" del software, è davvero una cosa diversa dall'informatica. Gli sviluppatori di software hanno bisogno di una conoscenza pratica dell'informatica, ma lavorare ai confini della complessità algoritmica o ragionare sul parallelismo non è qualcosa che un programmatore funzionante farà ogni giorno; allo stesso modo, un vero "scienziato informatico" scriverà tonnellate di codice usa e getta che semplicemente non funziona o non fa nulla di interessante, e non trarrà beneficio dal tipo di rigore che un prodotto software reale avrebbe.

L'emergere di Internet e della comunità open source potrebbe fornire dati sufficienti per iniziare a rispondere a queste domande in modo definitivo, ma anche se le risposte fossero disponibili domani, ci vorranno probabilmente 100 anni per permeare la società internazionale al punto in cui tutti concordano su cosa dovrebbe essere insegnato nelle scuole.

Infine ci sono alcune considerazioni economiche. È passato un tempo relativamente breve da quando quasi tutte le persone coinvolte nello sviluppo di software avevano un accesso facile e conveniente a macchine dedicate per eseguire qualsiasi strumento di sviluppo desiderassero. Qualche decennio fa, dedicare completamente una macchina solo all'esecuzione dei propri test, o addirittura ospitare una storia infinita di codice sorgente, sarebbe sembrato frivolo costoso a molte persone.

Perché i nostri insegnanti:

1. Mai provato unit test,
2. Non so come usare il controllo della versione e
3. Non ho nemmeno sentito parlare di "sviluppo agile".

Gli studenti dovrebbero prendere in mano la situazione. L'abbiamo fatto ed è andato tutto bene, no?

Leonardo da Vinci ha scritto,

Chi è innamorato della pratica senza scienza è come un pilota che sale su una nave senza timone né bussola e non ha mai la certezza di dove stia andando. La pratica dovrebbe sempre essere basata su una solida conoscenza della teoria.

Le buone scuole insegnano sia teoria (strutture dati, algoritmi, ecc.) Sia pratica (test di unità, controllo di versione, ecc.). Ciò richiede una miscela appropriata di facoltà in modo che entrambe le facce di questa moneta possano essere insegnate correttamente. Una facoltà composta interamente da tipi teorici senza esperienza reale non va bene. Allo stesso modo, una facoltà composta interamente da professionisti non andrà bene. Hai bisogno di un mix, e le buone scuole ce l'hanno.

L'informatica è sempre stata alquanto contraddittoria; La parte che riguarda i computer non è una scienza e la parte che è scienza non riguarda i computer.

Le università tendono ad appoggiarsi maggiormente alla "scienza" (algoritmi, dati, compilatori, ecc.) Perché queste cose sono molto più "senza tempo" delle attuali migliori pratiche del settore, che tendono ad evolversi e cambiare di anno in anno. Il controllo della versione, ad esempio, ha subito cambiamenti sorprendenti negli ultimi 5 o 10 anni, ma big-O è ancora big-O e hashing, btrees e recursion sono ancora utili come lo erano 40 anni fa. La loro idea è generalmente quella di darti abbastanza basi da poter poi prendere strumenti come git e capire cosa significa quando ti viene detto che la struttura dati sottostante è un grafo diretto aciclico di hash SHA-1 e che gli sviluppatori hanno lavorato sodo per ottimizzare il numero di chiamate di sistema in modo che sia associato a io.

Ora, pensa a dove hai imparato tutte le cose che dovevi sapere per capire l'ultima frase: se la risposta è "università", stanno facendo un lavoro a posto.

Tutto è una moda passeggera. Imparerai di più nel tuo primo anno di università che in tutti i tuoi anni al college. L'informatica non ha nulla a che fare con i computer.

Il college ti offre una cassetta degli attrezzi piena di strumenti. Questo è un cacciavite, che è una chiave a mezzaluna. Potresti usare ogni strumento una volta al college. È quando entri nel mondo reale è quando scopri davvero quello che hai. Separerai dal resto quelli utili, quelli che vuoi lasciare a casa sul banco da lavoro, per ogni evenienza, e quelli che tieni in tasca ogni giorno.

Tqm, Iso, Cmm, Agile, ecc. Queste sono tutte mode che arriveranno e se ne andranno, nessuna di quelle di successo è più che semplice buon senso. Tutti gli ingegneri e le aziende di successo usano un po 'di buon senso, questo è ciò che li ha resi vincenti, pochi avevano bisogno di un nome. Il problema è che non puoi vendere il buon senso, un manager non può dimostrare il proprio valore all'azienda formando e acquistando il buon senso senza un nome accattivante. Mettici sopra un nome che i loro superiori hanno letto in qualche articolo o rivista e il manager manterrà il loro lavoro e tu manterrai il tuo. Pochissime delle aziende che affermano di seguire queste pratiche lo fanno effettivamente. La maggior parte scrive un assegno a un consulente e ottiene il certificato annuale e / o a vita a qualche club in modo che possa mettere una grafica sul proprio sito web o un'etichetta sulla scatola in cui viene fornito il prodotto. Molti sosterranno che questo è raro ... stato lì, visto, succede. Tutto questo fa parte degli affari, a volte devi tagliare gli angoli per rimanere redditizio e tenere le porte aperte e le luci accese. I seguaci più accaniti di tutte queste pratiche hanno tutti sostenuto che l'ultima era una moda e questa non lo è, l'ultima era davvero troppo costosa da seguire, questa non lo è. L'ultimo era falso, hai appena assunto un consulente, questo è vero. Come i linguaggi di programmazione, anche questi si evolveranno. L'ultimo era falso, hai appena assunto un consulente, questo è vero. Come i linguaggi di programmazione, anche questi si evolveranno. L'ultimo era falso, hai appena assunto un consulente, questo è vero. Come i linguaggi di programmazione, anche questi si evolveranno.

La tua capacità di comprendere la realtà del business, il sistema universitario e il tuo ruolo in esso è la chiave. Come qualsiasi cosa nella vita, scegli le tue battaglie. Non è l'università o gli affari o il governo o il lavoro di qualcun altro per insegnare ciò che vuoi che hai bisogno o vuoi sapere. Il tuo lavoro è cercare il numero uno. Allo stesso modo non puoi incolpare nessun altro per averti fornito il tempo per farlo, devi farlo. Cadrai da cavallo, non sei una vittima, ti alzi e ti rimetti in sella, niente scuse, la vita non è giusta. Approfitta delle dispense, non fingere di essere indipendente. E certamente paga i tuoi debiti, non succhiare una compagnia a secco di sussidi, senza dare loro qualcosa (il tuo meglio in quel momento?) In cambio.

Perché le persone pensano che cmm o agile o qualcun altro sia una moda passeggera? Perché pensano di non esserlo? Perché il professore ti ha insegnato a programmare in quel modo? Per evitare gotos o per evitare costanti o per evitare questo e quello? È perché produce codice più affidabile? Codice con prestazioni migliori? Riduce l'errore umano? O è perché è più facile valutare documenti / programmi dando loro più tempo per fare ricerca? È perché non sanno programmare e stanno solo seguendo il libro di qualcun altro sull'argomento? Ti hanno insegnato che non puoi avere un codice manutenibile, affidabile e ad alte prestazioni? Non puoi nemmeno "sceglierne due" manutenibili interferisce sia con prestazioni affidabili che elevate? A volte sacrifichi l'affidabilità per le prestazioni. A volte non ti interessa l'affidabilità o le prestazioni, vuoi solo ottenere dalla versione 117.34. 2 di un altro programma software di contabilità alla versione 118.0.0. Il tuo modello di business deriva dalla vendita di aggiornamenti di versione e supporto tecnico e, per quanto riguarda gli sviluppatori di software, qualsiasi vecchio robot può scrivere lo stesso codice nello stesso modo. Sostituisci quello bruciato con quello appena uscito dal college e continua a vendere aggiornamenti.

Non ci sono risposte universali a queste domande, devi scoprire qual è la tua opinione, conviverci e difenderla. Cambia idea, vivi con essa e difendila.

Metti in dubbio tutto ... mi brucio davvero se tocco la pentola calda sul fornello? Gli effetti psicologici della paura causeranno più danni del semplice bruciarsi? C'è un modo sicuro per testare la risposta senza farsi male?

Quando potevo permettermelo, compravo e alla fine fondevo transistor, cappucci, resistori, ecc. Nella mia stanza del dormitorio, che hanno tutti un caratteristico cattivo odore. È molto più economico e più facile acquistare un amplificatore per il tuo stereo che provare a costruirne uno il giorno dopo la tua prima lezione di transistor. Linus è l'eccezione, ovviamente è più facile acquistare un sistema operativo che scriverne uno ... Puoi fare di più anche se ciò che impari in quel periodo è diverso da quello che ha imparato Linus.

Il mondo dentro e fuori l'università adotterà queste formule (cmm, agile, ecc.) Per risolvere i problemi e quando uscirà il prossimo li abbandoneranno altrettanto velocemente. Non è necessario utilizzare il controllo della versione per avere successo, ci sono altrettanti successi con e senza (beh, in realtà a causa dell'età del settore ci sono molti più successi senza controllo della versione finora). Allo stesso modo puoi avere successo con test minimi (guarda i grandi nomi dell'industria dei computer come esempi). Puoi avere successo testando il tuo codice, oltre ad avere successo seguendo la regola che non dovresti mai testare il tuo codice. Puoi avere successo usando emacs e puoi avere successo usando vi. Devi decidere quale mix funziona per te e se sei fortunato trova un posto di lavoro che sia d'accordo con te.

Quando esci dal college e entri nel mondo reale, ascolta, lavora con e discuti con i "veterani". Hanno decenni o secoli di esperienza combinata, trappole in cui sono caduti che potresti evitare e / o testare da solo (forse ti rendi conto che non devi toccare la pentola calda per scoprire che ti brucerà). La maggior parte avrà visto almeno una o due di queste mode andare e venire, e in particolare quanto sono state bruciate e cosa hanno fatto per riprendersi. Conoscono molti modi diversi per testare le cose e anche i nomi degli stili di test che sono andati e venuti. Cosa funziona, cosa no. Dove c'è il rischio e come evitare di perdere tempo in tangente. Man mano che maturi e diventi il ​​vecchio timer, passalo avanti. Paga ciò che hai imparato cercando di insegnare a coloro che ti seguono. Ricordati di insegnare loro a pescare, non dare loro un pesce. E a volte devi lasciarli fallire prima che abbiano successo, evitare che si brucino troppo gravemente.

Quello che volevo davvero dire qui è che in questo momento siamo in una rara situazione in cui possiamo assistere a un'evoluzione di un universo parallelo (e forse influenzarlo). Sì, l'informatica è una scienza giovane rispetto alla fisica. Ma allo stesso tempo si è evoluto molte volte. A seconda di dove lavori e con chi lavori, potresti essere in grado di osservare gli ingegneri hardware. I linguaggi di programmazione nel mondo dell'hardware non sono certo nuovi, ma non si sono evoluti rapidamente come il mondo del software. Il software ha avuto un vantaggio di alcuni decenni. L'hardware ha sempre pensato agli ingegneri del software come cittadini di seconda classe. Il nostro lavoro è facile, il loro lavoro è difficile. (Nota che in realtà sono sia un ingegnere hardware che software). Ciò che è interessante è che in questo momento hanno ancora a che fare con quelli che considereremmo problemi elementari o infantili. Perché dovrei usare il controllo della versione, sono l'unico a lavorare su questo chip. La tua esperienza con gcc o altri compilatori economici o IDE gratuiti non può essere paragonata ai costosi strumenti che uso, se la società pensasse che fossi abbastanza degno di usarlo o addirittura di sapere come usarlo ti comprerebbe una copia. E una lunga lista di altre scuse. Ho avuto il piacere di imparare sia vhdl che verilog e di diventare produttivo in entrambi in una settimana da quella che era quasi una sfida da parte di un simile ingegnere hardware (nonostante il mio diploma affermasse ingegnere elettrico il mio titolo di lavoro è ingegnere software). Volevo imparare queste lingue, quando gli strumenti erano a mia disposizione sono rimasto in ufficio fino a tarda notte e ho imparato da solo. Da quel momento in poi quell'ingegnere in particolare si rese conto che quello che stavo dicendo era vero, le lingue sono solo sintassi, i fondamenti della programmazione sono gli stessi, gli strumenti fanno tutti la stessa cosa. Le sue mele e mele non mele e arance.

In generale, tuttavia, è ancora difficile inviare il messaggio che una di queste due industrie parallele ha molta più esperienza in linguaggi, abitudini di programmazione, controllo del codice sorgente, test, strumenti, ambienti di programmazione, ecc. Rispetto all'altra. Il problema che sto cercando di risolvere è prendere i progetti hardware mentre vengono sviluppati, creare simulatori funzionali convenienti che possiamo collegare con una simulazione (macchina virtuale) del processore in modo da poter iniziare a testare l'hardware e sviluppare il test e software consegnabile molto prima di passare al silicio. No, non c'è nulla di "nuovo" in questo, ma non abbiamo alcun meccanismo per ottenere il codice più recente, tenere traccia delle modifiche nel codice per vedere dove dobbiamo concentrare il nostro tempo. Nessun meccanismo per tenere traccia della documentazione che definisce l'interfaccia utente (programmazione) sull'hardware. L'unica copia d'oro è nella casella di posta in arrivo di qualcuno in forma binaria e cambia solo quando, beh, non è necessario leggere il verilog per scoprire cosa sta succedendo. Aspetta, quanti anni ha quel verilog? Quel bug su cui ho passato tutta la settimana è stato individuato tre settimane fa e corretto? Quindi voliamo in qualche luogo di vacanza e festeggiamo per sei mesi in attesa che gli addetti all'hardware finiscano il loro compito e ce lo gettino oltre il muro, o cogliamo l'occasione per cercare di essere pazienti e ottimisti e insegnargli che loro ci sono metodi di buon senso che non sono così invadenti che consentono loro di svolgere il proprio lavoro, eseguire il backup del proprio lavoro e condividere le proprie cose per la revisione tra pari ... che verilog ha quanti anni? Quel bug su cui ho passato tutta la settimana è stato individuato tre settimane fa e risolto? Quindi voliamo in qualche luogo di vacanza e festeggiamo per sei mesi in attesa che gli addetti all'hardware finiscano il loro compito e ce lo gettino oltre il muro, oppure cogliamo l'occasione per cercare di essere pazienti e ottimisti e insegnargli che loro ci sono metodi di buon senso che non sono così invadenti che consentono loro di svolgere il proprio lavoro, eseguire il backup del proprio lavoro e condividere le proprie cose per la revisione tra pari ... che verilog ha quanti anni? Quel bug su cui ho passato tutta la settimana è stato individuato tre settimane fa e corretto? Quindi voliamo in qualche luogo di vacanza e festeggiamo per sei mesi in attesa che gli addetti all'hardware finiscano il loro compito e ce lo gettino oltre il muro, o cogliamo l'occasione per cercare di essere pazienti e ottimisti e insegnargli che loro ci sono metodi di buon senso che non sono così invadenti che consentono loro di svolgere il proprio lavoro, eseguire il backup del proprio lavoro e condividere le proprie cose per la revisione tra pari ...

Ricorda che gli ingegneri hardware hanno lasciato il college con una scatola di nuovi strumenti brillanti proprio come hai fatto tu. Hai imparato 17 diversi linguaggi di programmazione di cui puoi usarne solo uno, il resto dei linguaggi che hai nella tua carriera saranno inventati dopo aver lasciato l'università. Quando hanno lasciato il college possono dirti quello che sanno del calcolo e della teoria della relatività quanti elettroni ci sono in ciascuno degli elementi e calcolare la carica attorno a una superficie gaussiana. Ma la maggior parte della loro carriera è uno, zero e, o e no (ehi, abbiamo quelli in comune, tutto quello che devi sapere sui computer, uno, zero e, o e non, ingegnere hardware o software). Ammesse le leggi fondamentali della fisica, il calcolo, gli elettroni non cambieranno alla stessa velocità dei linguaggi di programmazione. Ma i fondamenti della programmazione sono gli stessi in tutte le lingue e continueranno ad esserlo in futuro. Hai lasciato il college sapendo che o hai lasciato pensando che Java è diverso e migliore di C ++ perché questo e quello e l'altro?

Come qualsiasi altra attività, il lavoro dell'università deve rimanere redditizio. Devono assumere gli accademici giusti per portare sia gli studenti giusti che i giusti dollari di ricerca e i giusti tipi di ricerca per rendere redditizia l'università. Devono offrire le classi giuste per portare gli studenti giusti e produrre i laureati giusti in modo che con il passare dei decenni i datori di lavoro sia vicini all'università che, si spera, lontani riconoscano che questa università produce dipendenti produttivi e redditizi. (sì, a volte devi attirare gli atleti giusti nello sport giusto per ottenere la giusta quantità di tempo televisivo e la giusta quantità di riconoscimento del nome e entrate sportive). Alcune università insegneranno C ++ e Java, altre non lo faranno mai. Alcuni inventeranno CMM e alcuni insegneranno Agile, altri non faranno nessuno dei due. Se l'università ha un valore, c'è qualcosa da imparare. Non ti insegneranno tutto quello che c'è da imparare, ma avranno qualcosa di utile. Impara quel qualcosa mentre sei lì, raccogli un numero ragionevole di varie forme di strumenti nella tua cassetta degli attrezzi. Lascia l'università e trova un lavoro. Se la tua cassetta degli attrezzi fa schifo forse trova un'altra università e non menzionare mai la prima. Se è una cassetta degli attrezzi ok, usa questi strumenti e creane di nuovi nel tuo tempo libero. Se è una cassetta degli attrezzi piuttosto buona, di 'cose positive su quell'università e sui bravi accademici da cui hai imparato questo e quello e ripaga la scuola per quello che ti hanno dato. Anche se non hai ottenuto tutti gli strumenti possibili nel catalogo universale degli strumenti universitari, uscirai con un certo sottoinsieme. Anche se non ti laurei ...

Ho insegnato queste cose quando ero aggiunto presso l'Oregon Institute of Technology. Vengono insegnati, solo scarsamente.

La risposta più semplice è che stai studiando informatica e le cose che hai elencato non sono realmente legate al campo accademico dell'informatica. Lo sviluppo del software potrebbe essere qualcosa che fai con l'informatica, qualcosa che si basa sui blocchi di ciò che hai imparato ... ma l'informatica e lo sviluppo del software non sono la stessa cosa.

Lezioni che ti hanno insegnato il controllo della versione o come scrivere test unitari efficaci ... ti insegnerebbero un mestiere , vale a dire, lo sviluppo (buono) del software.

oh dio non farmi iniziare

Una volta ho chiesto al preside del CS di un'università rispettabile che mi dicesse che la programmazione orientata agli oggetti era solo una `` moda passeggera '', quindi non offrivano lezioni di passaggio come il C ++

sul motivo per cui non insegnano queste cose, beh, il college è lì per insegnarti i fondamenti della disciplina, non necessariamente le migliori pratiche del settore

Ebbene, la cosa con le università è che hanno bisogno di insegnare cose che siano davvero universali. Qualcosa come lo sviluppo agile è ancora piuttosto nuovo e nonostante quanto si parli su Internet non viene utilizzato ovunque, quindi insegnarlo a un'intera classe di studenti potrebbe potenzialmente avvantaggiare solo poche persone che sono atterrate nei negozi agili.

Il controllo della versione, tuttavia, è qualcosa che in questi giorni è imperdonabile. È qualcosa che tutti devono capire che è uno strumento utile quasi quanto un compilatore e CVS è in circolazione da circa 20 anni. I concetti devono almeno essere compresi da qualsiasi programmatore che lascia un'università. Fortunatamente se svolgi un lavoro di gruppo all'università potresti essere abbastanza fortunato da atterrare con qualcuno che già conosce il controllo della versione e convince il tuo gruppo a usarlo. So di essere contento che quella persona fosse nel mio gruppo.

Anche il test unitario è praticamente imperdonabile. L'unica cosa che direi è che il libro è ancora in fase di sviluppo guidato da test e cercare sempre una copertura del codice al 100% a volte può essere più un problema di quanto valga la pena. Ma i test unitari sono estremamente preziosi e dovrebbero essere coperti in un corso di ingegneria del software. Immagino che alcune di queste cose stiano arrivando in alcune università, ma non sono ancora arrivate a tutte.

Perché no, davvero? La mia esperienza nel conseguire la laurea in scienze informatiche è stata praticamente la stessa. Il motivo è che le persone che insegnano programmazione non programmano, per quanto ne so. Non è necessario insegnare quella roba per l'accreditamento, gli insegnanti non la conoscono e gli studenti non sviluppano mai progetti di alcun significato come parte dei loro corsi. Non c'è alcuna motivazione per insegnare effettivamente la programmazione, al contrario di insegnare la teoria CS o la sintassi Java.

Gli informatici pensano di essere matematici non ingegneri e quindi preferiscono insegnare le parti di matematica piuttosto che le parti di ingegneria. Test, controllo delle versioni e documentazione non stanno passando le mode passeggere più di quanto non lo siano in qualsiasi altra disciplina ingegneristica.

Dipende dall'università. Mi sono laureato nel 2003, da un'università australiana. In quel periodo abbiamo imparato UML, Unit Testing, XP (e altre metodologie Agile), insieme a tutte le cose formali come Z, algoritmi e strutture dati, sistemi operativi, ecc.

Tuttavia, non hanno trattato i test di unità in modo molto dettagliato, più semplicemente hanno pagato il servizio di passaggio per una lezione. Sarebbe stato fantastico aver imparato a scrivere test unitari efficaci, piuttosto che semplicemente "Che cos'è un test unitario".

Per quanto riguarda il controllo della versione, lo stavamo utilizzando (CVS) nei nostri progetti di programmazione dal 2 ° anno in poi.

Anch'io sono assolutamente d'accordo con quanto ha detto Glyph. Il CS è un campo così immaturo, in realtà solo negli ultimi 50 anni, che non sappiamo cosa dovremmo imparare e cosa è solo una moda passeggera. Dagli 150 anni, allora le cose potrebbero sistemarsi di più. Il numero di progetti del mondo reale falliti rende ovvio che questo è un settore immaturo. Immagina se l'80% dei progetti di costruzione fallisse!

Tutto ciò può essere facilmente trattato (superficialmente) in una singola classe sulle pratiche di sviluppo software. Non fa parte della maggior parte dei corsi di informatica, perché non è di questo che si tratta, anche se penso che una certa copertura di queste cose sia utile. La mia scuola aveva una classe del genere; non copriva il controllo della versione, ma copriva UML, raccolta di requisiti, metodologie di sviluppo (vari agili e a cascata), test di unità, test di integrazione, ecc. e ci ha richiesto di lavorare in team di 4-5 persone per sviluppare un progetto (un indizio piuttosto semplice imbroglio in Java). Se sentivi la necessità di ulteriori corsi di ingegneria del software, erano disponibili come elettivi.

Nonostante non sia mai stato menzionato il controllo della versione una volta in nessuna classe che ho seguito, la maggior parte dei miei amici lo utilizzava per progetti personali, compiti in classe e così via, quindi non è come se non fossimo esposti a esso. Le persone che non lo hanno raccolto da sole sono state costrette a usarlo da un compagno di classe nel corso di un incarico di squadra.

L'università ha lo scopo di insegnare concetti e teorie, perché quelle sono le cose che sono difficili da imparare da soli. Il controllo della versione è uno strumento e abbastanza facile da imparare. Usalo un po ', leggi alcuni tutorial sul web e sei pronto. Se hai bisogno di lezioni e compiti a casa per capire come controllare qualcosa da SVN, avrai molti problemi con le cose che in realtà SONO difficili.

Ricorda che ci sono molti modi per imparare cose al college al di fuori delle lezioni; approfittane. Stai pagando molto per frequentare le lezioni e utilizzare le strutture, quindi mungilo per tutto ciò che vale e vai alle riunioni LUG e ACM, partecipa ai team di progetto (ci sono sempre alcuni ME che costruiscono un robot che hanno bisogno di un programmatore) o ottieni un lavoro che gestisce il server del dipartimento di scienze umane. Scegli un computer dal dock di caricamento dell'edificio di ingegneria dei materiali, scarica una ISO di Linux con la tua connessione Internet veloce nel dormitorio e divertiti.

Penso che il problema sia che le università non sentono di dover insegnarti a essere un professionista, ma si concentrano invece sul lato accademico della programmazione. Avrei pensato che ci dovrebbe almeno essere un riferimento ai metodi e alle tecniche più recenti utilizzati nel settore, poiché anche queste cose sono di interesse accademico.

Nel nostro corso, ci è stato insegnato Processo software personale, che copriva cose come il tempo di registrazione dedicato ai progetti, buoni commenti ecc., Ma nessuna menzione di fondamenti professionali come il controllo della versione.

Ne hai nominati 3, alcuni dei quali non credo siano altrettanto importanti per la comprensione dei sistemi informatici (ad esempio il controllo della versione). Queste cose fanno parte di un lavoro e puoi diventare un buon programmatore / informatico senza bisogno di saperlo.

allo stesso modo per i test unitari: perché scegliere i test unitari? Sicuramente il test di usabilità, il test di sistema, il test di accettazione dell'utente e il test di accettazione in fabbrica sono più importanti? Bene, lo sono a meno che tu non consideri il tuo lavoro completo una volta che il codice è stato spedito al reparto manutenzione :)

Pensa agli altri concetti che utilizzo quotidianamente, che sarebbero di scarsa utilità per uno studente che viene a patti con i fondamenti del software e dei sistemi informatici:

• buone pratiche di commento
• conformità agli standard (non solo internazionali, ma standard di codifica del team)
• documentazione
• controllo delle modifiche (non necessariamente lo stesso del controllo della versione che riguarda la memorizzazione delle differenze, questo riguarda più cosa e perché hai cambiato qualcosa)
• sviluppo dell'usabilità

Quelle precedenti sono tutte "competenze trasversali" che non servono per scrivere un buon codice.

Tuttavia, se ti mancano le abilità "difficili", come le strutture dei dati e gli algoritmi, la tua possibilità di scrivere un buon codice è quasi impossibile.

Ho imparato tutto all'università. Forse dipende dai corsi che scegli? I miei corsi erano molto diversi (Software Design, UI Design, eCommerce, AI, Functional programming, ecc.). Software Design è stato esposto a modelli di progettazione e test unitari (un grande progetto che ha coinvolto varie cose). UI Design ... eravamo un gruppo di tre persone che lavorava su un progetto. Non potevamo fare nulla senza il controllo della versione, quindi lo abbiamo ottenuto. E lo sviluppo agile era qualcosa di cui i nostri professori ci parlavano continuamente, ma lo lasciavano a ciascun gruppo per usarlo.

Trovo che molti studenti universitari abbiano frequentato corsi "facili" o corsi che avrebbero dato loro un GPA elevato. Altri si concentrano su ciò che vogliono imparare e stanno in gran parte esplorando per trovare quale campo li interesserebbe. E poi ci sono quelli che sanno esattamente a cosa sono interessati ... il che è positivo, tranne per il fatto che tendono a non diversificare i loro corsi.

Per rispondere al motivo per cui queste cose non sono le prime cose che vengono insegnate: i programmi universitari in genere ti insegnano a diventare uno studente di master. Solo una volta che inizi a scegliere i tuoi corsi (cosa che di solito accade negli anni successivi) puoi scegliere di imparare cose usate al di fuori del mondo accademico. Questo è il motivo per cui si concentrano su algoritmi, strutture dati, presentandoti problemi irrisolti, ecc.

Personalmente penso che vada bene che lo stiano facendo. La programmazione non è così facile come molti di noi fanno sembrare; molte persone lottano con esso. Preferirei che queste persone capissero prima come funziona un ciclo for prima di capire il mostro che è Perforce.

Non insegnano questi argomenti perché la maggior parte delle scuole è accademica, non commerciale. Cioè, sono progettati per insegnare idee e teorie, non per allenarti in una carriera. L'intero concetto di QA non ha nulla a che fare con l'informatica oltre al superamento di una dimostrazione matematica. Inoltre, le pratiche di controllo qualità ei flussi di lavoro di sviluppo differiscono notevolmente da una casa di sviluppo all'altra, quindi insegnarli a scuola è uno spreco di tempo e denaro.

Ho imparato tutte quelle cose da matricola, con l'eccezione dello sviluppo agile.

Si tratta di scegliere la scuola giusta, IMHO. Se vai nella top 10, imparerai rapidamente tutte quelle cose.

Per quanto riguarda CS Education in generale, in pratica chiediamo ai professori di insegnare così tanto (lingue di ogni gusto, strutture dati, efficienze di runtime, come funzionano effettivamente le cose a livello di bit). Vorrei sollevare la domanda: perché i ragazzi non si impegnano a saperne di più sull'ingegneria del software?

Proprio come gli studenti, ogni college è diverso. Alcuni college, o più precisamente, alcuni professori sono resistenti al cambiamento o sono pigri. Fortunatamente la maggior parte non lo è. Teorie, concetti, storia ecc. Sono importanti e vitali per qualsiasi curriculum CS. Ma così sta preparando lo studente per il suo ambiente di lavoro. Non sorprende che i college della mia zona offrano corsi CS molto attuali e applicabili. Non tanto con università grandi, affermate e prestigiose.

È semplicemente perché le strutture dati e gli algoritmi costituiscono il nucleo del calcolo e quindi sono molto più importanti. I test di unità, il controllo della versione e la metodologia agile non sono che strumenti del mestiere (e se necessario, ci si aspetta che li prenda sul lavoro).

Penso che buoni programmi CS dovrebbero insegnare i fondamenti che serviranno come base per tutta la futura educazione alla programmazione. Le metodologie di sviluppo come Agile e gli strumenti di controllo della versione sono come le mode passeggere; vanno e vengono. Inoltre, tendono ad essere utilizzati in contesti industriali e non accademici, quindi penso che sia raro che le università coprano cose come quelle che probabilmente imparerai sul lavoro. Non sto dicendo che sia giusto, ma questa è probabilmente la mentalità accademica.

Sono d'accordo con quello che stai dicendo. Ho appena iniziato a lavorare nel mondo dello sviluppo software e ho già iniziato a conoscere lo sviluppo agile, qualcosa che non mi è mai stato insegnato all'università.

Il nocciolo della questione potrebbe essere che i professori universitari non tengono il passo con le nuove tecniche di sviluppo tanto quanto dovrebbero. Possono anche sentire che ci sono altre cose più importanti nel loro curriculum.

I docenti universitari non sanno come scrivere software, si limitano a ricercarlo, insegnarlo e, occasionalmente, estrarre del codice che deve funzionare solo fino alla pubblicazione dell'articolo.

È solo grazie a persone come Titus che stiamo ottenendo accademici che si divertono davvero a programmare - Leggi i suoi commenti su questo argomento qui

Quando ero studente leggevo libri nella libreria su Extreme Programming, e ne discutevamo brevemente in classi - le stesse classi che richiedevano che ci conformassimo al "modello a cascata" dello sviluppo del software, dove la "compilazione" è un passo del suo proprio.

Ti auguro il meglio per la tua carriera, spero che tu ti sia laureato, è bello avere lettere dopo il tuo nome. :)

Tutte e tre le cose che menzioni (test di unità, controllo della versione, sviluppo agile) vengono insegnate in una certa misura nel programma di informatica dell'Università di Groningen. Se questa sia o meno una buona cosa, lascerò una questione aperta; ma non è vero che nessuna università ti insegna la "roba pratica".

Questi si basano sulla mia esperienza limitata in un programma CS prima di cambiare major e sulla mia esperienza come stagista presso una grande azienda di software. I test unitari non vengono insegnati perché la maggior parte dei programmi che devi creare non sono abbastanza grandi da richiedere test automatici, hai garantito un set specifico di input in modo da poter testare tutto manualmente. Insegnarti come automatizzare i test può anche interferire con la valutazione del tuo progetto poiché la maggior parte dei progetti viene valutata con script che eseguono test automatizzati, con una rapida occhiata al codice per assicurarti di non avere int foo1; int foo2; e usi il rientro corretto.

Non so perché il controllo della versione non sarebbe stato insegnato, ma parte di esso è probabilmente la dimensione dei progetti. Non ho mai avuto un progetto abbastanza grande per il controllo della versione, e per grande intendo oltre 1000 righe di codice e ho impiegato un intero semestre per scrivere. Immagino che pensino che lo insegnerai a te stesso se ne avrai bisogno. Tutti i progetti di gruppo che avevo dovevano essere progetti di programmazione in coppia, e perché usare il controllo della versione se siete entrambi sullo stesso computer?

Non so perché lo sviluppo agile non sarebbe stato insegnato, ma probabilmente torna alla stessa cosa con le dimensioni del programma. Sebbene lo sviluppo adgile sia comune con il nuovo software che gira su personal computer e piccoli server, non è generalmente utilizzato su sistemi come i mainframe IBM o in domini problematici come banche o medici, dove la documentazione è re. Probabilmente ha anche a che fare con il fatto che lo sviluppo dell'adgile non è avvenuto circa 20 anni fa, quando venivano formati molti professori.

Il motivo principale è che molte (la maggior parte?) Università ritiene di avere un obiettivo diverso da una scuola professionale. In quanto tali, vogliono insegnare agli studenti come imparare e i principi fondamentali della disciplina. Inoltre, gli algoritmi e le strutture dati si applicheranno a qualsiasi linguaggio di programmazione e non dipenderanno da strumenti specifici (che potrebbero essere o meno ancora in uso alla laurea).

In Informatica, ciò significa algoritmi, strutture dati, teoria informatica, teoria del compilatore, ecc. Le cose che stai elencando riguardano meno la comprensione di come programmare, come risolvere i problemi, ecc. Riguarda la pratica della programmazione (che, per inciso, è un libro fantastico per chiunque sia al college con l'intenzione di lavorare come programmatore). Ora, gran parte di questo non verrà utilizzato in una posizione di scimmia del codice di livello iniziale, portando alcune persone a pensare che non sia utile. Non sono d'accordo. Penso che possa essere estremamente utile. Tuttavia, ciò non significa che dopo aver conseguito la laurea in CS, sai tutto ciò di cui avrai bisogno per lavorare come programmatore.

Anche questo non vuol dire che le cose che dici non siano utili. Loro sono. Avrai problemi a lavorare come programmatore se non li impari, e penso che dovrebbero essere insegnati al college, almeno in una certa misura. Guarderei all'insegnamento del controllo della versione, dei test di unità, ecc., Allo stesso modo in cui guarderei una programmazione universitaria in arte e l'insegnamento di cosa sono i pennelli e quali dovrebbero essere usati per vari casi.

Penso che dipenda dal tipo di programma di informatica in cui ti trovi, ci sono quelli che mirano al lato della ricerca e della scienza e ci sono quelli che si orientano verso il lato dell'implementazione. Ho rifiutato in particolare nei confronti di alcune scuole che avevano solo professori rimasti nel mondo accademico. Se non hai professori che non hanno "usato" ciò che insegnano, è tutto nella loro testa, letteralmente.

Spina: avendo conseguito la laurea in informatica e la laurea specialistica in soft eng alla DePaul University, sono stato principalmente insegnato da istruttori / professori che insegnavano part time, il che per me andava bene perché avrei preferito che arrivassero con un aneddoto del giorno precedente e collegalo alla classe. Inoltre, essendo una scuola per lo più pendolare / part-time, la maggior parte degli studenti ha un lavoro nell'usare ciò che sta imparando.

Il processo di apprendimento inizia ancora con tutta la teoria, ma poi di solito ci viene chiesto "quanti di voi lo usano effettivamente nel proprio lavoro?" e la risposta tipica è "lo usiamo ma in un modo ridotto o più semplice" e poi entriamo negli scenari pratici del mondo reale.

Durante il mio periodo scolastico i test di unità erano sempre presenti. Anche se ti hanno iniziato con Java, ci hanno fatto usare ANT e JUnit per tutti i progetti. Che è stato un buon inizio per la configurazione della build e il test delle unità.

Ed Extreme Programing è stato incluso in circa 3 o 4 dei corsi che ho seguito. Ricordo che tutti hanno iniziato con i 12 diversi aspetti, dalla programmazione in coppia allo unit test (vedi sopra). E ora sembra che l'attenzione sia concentrata su Agile.

Quindi la risposta rapida è sì, ci sono scuole là fuori che hanno un approccio più pragmatico di altre.

Il test unitario e il controllo della versione sono stati entrambi insegnati nei corsi di informatica del 2 ° anno in cui sono andato all'università. Il test unitario rientrava nella parte del test che includeva anche differenze tra scatola bianca e nera e una buona parte dei voti negli incarichi di programmazione del 3 ° anno è stata utilizzata per una buona gestione degli errori che può facilmente derivare dai test unitari.

Lo sviluppo agile può essere piuttosto difficile da insegnare in un contesto accademico, penserei. Mentre ho imparato a conoscere il metodo Waterfall in teoria, non sono riuscito a vederlo sul campo fino a dopo essermi laureato e essermi trasferito nel mondo reale che può essere molto diverso dal mondo accademico, ad esempio nel 3 ° anno faccio tutti gli errori dispari casi e quasi superare un incarico in cui non ho mai toccato il cuore di ciò che il compito ha cercato di insegnarmi sui semafori.

Inoltre, da quanto tempo esiste agile e quale forma di agile intendevi? Ci sono molte diverse implementazioni da quello che ho visto.

Non penso che la programmazione agile sia una moda passeggera, ma allo stesso tempo sarebbe difficile pensare a un modo in cui un insegnante potrebbe darti progetti per permetterti di impararlo .. A meno che non ti abbiano dato il progetto A build a, progetto B si espande su a. Il problema è il tempo e la portata. In un corso di 4 mesi sarebbe difficile.

I metodi di controllo della versione e di unit test cambiano continuamente e dipendono dalla lingua o dalla persona che li definisce.

Le strutture dati e gli algoritmi sono qualcosa su cui si può lavorare in un contesto di classe. Onestamente, ci vuole un po 'più di sforzo per capire quindi i test di unità e il controllo delle versioni. Cerca di ricordare che parte dell'università è insegnarti a insegnare da solo. Il collage non ha lo stesso mandato. O almeno non nella stessa misura. A PARER MIO.