Quanto è grande il divario tra ciò che impari nei curricula CS e ciò di cui hai bisogno nei progetti di vita reale? [chiuso]

7

Sono nel mio ultimo anno in un curriculum CS di 4 anni e mi piacerebbe molto contribuire a un progetto FOSS. Sfortunatamente, sento che non c'è modo di poter fare codice utile, sia che si tratti di bug fixing o di sviluppo di feature. I progetti C / C ++ / Java che intraprendiamo a scuola sono banali rispetto alla codifica per progetti seri e quando leggo il codice sorgente di un progetto FOSS sono completamente in perdita. Sei d'accordo che c'è un divario tra l'educazione CS e in realtà la programmazione per un progetto di vita reale? Quanto pensi sia grande questa lacuna e come la si supera?

    
posta attikiouzel 23.04.2011 - 09:58
fonte

5 risposte

23

C'è un buco. Il divario si riduce a due fattori: certezza e dimensioni.

  • Il professore sa cosa vuole. Il cliente non sa cosa vuole. Questo è spesso il tuo più grande mal di testa.

  • Il professore sa che puoi farlo. Nel mondo reale nessuno sa se può essere fatto. Devi lavorare con il cliente per limitare l'attività a essere fattibile.

  • Il compito scolastico è fisso; il compito del mondo reale deve essere modificato per adattarsi al budget e ai vincoli tecnici, ma solo se parli rapidamente.

  • Il progetto di piccola scuola significa che non hai controllo di versione, riunioni di progettazione, cooperazione con programmatori, problemi di interfaccia, ecc. Non ti perderai mai in un progetto di codifica in classe; sicuramente ti perderai nel mondo reale e avrai bisogno del computer per tenere traccia dei pezzi per te.

risposta data 23.04.2011 - 12:16
fonte
5

Sono un principiante anch'io. Mi sono appena laureato circa 6 mesi fa.

Gli spazi vuoti:

Limiti di tempo: in uni, i nostri docenti di solito progettano i nostri incarichi in modo tale che sia possibile per noi finirlo in tempo e un po 'più di tempo per "lucidare" le cose. Tuttavia al lavoro, questo non è il caso. Ci sono molti più limiti di tempo al lavoro. Alcuni di questi sono probabilmente la firma da parte dei clienti dei risultati precedenti, o un improvviso problema tecnico imprevisto che è stato preso in considerazione più tempo del previsto o semplicemente gestione che ha svolto un lavoro errato assegnando il tempo stimato / le ore di lavoro richieste per le attività .

SOFT skills: Da junior, ci sono sempre gli anziani che ti aiutano nelle difficoltà tecniche, ma nessuno ti aiuta nelle tue abilità soft!

In uni raramente lavoriamo in team di progetto con dimensioni superiori a 6 ppl al massimo. Al lavoro, collaboriamo con molto di più, e quindi il significato di un sacco di problemi. Uno dei più importanti è sicuramente la COMUNICAZIONE. In qualche modo, in qualche modo, ho scoperto che non stavamo comunicando con gerghi tecnici appropriati in uni. Alcuni lottano quindi quando comunicano con sviluppatori più esperti al lavoro.

Al lavoro, dovremmo anche essere più assertivi, sostenere le nostre affermazioni con fatti appropriati e, inoltre, diffidare degli anziani che cercano di sfruttare la tua ingenuità (altrimenti potresti ottenere un carico di lavoro non necessario extra)

Tuttavia, le dichiarazioni di cui sopra varierebbero ampiamente, a seconda del livello di istruzione dell'università dato (sento che alcuni unis danno ai loro studenti molte maniere, imitando scenari di progetti di vita reale), alcuni sono strongmente inclini alla teoria. E, naturalmente, anche la cultura del posto di lavoro ha un ruolo in questa domanda.

    
risposta data 23.04.2011 - 18:13
fonte
4

C'è anche un grande gap di ingegneria del software. Spesso ai laureati non sono state insegnate alcune pratiche chiave come:

  • Controllo origine / Controllo versione
  • IDE (e in particolare refactoring)
  • TDD e amici (ATDD, BDD)
  • Creazione e integrazione continua / distribuzione / consegna
  • Strumenti e debug di analisi del codice statico
  • Tecniche agili come le schede kanban, il monitoraggio dei problemi moderato ecc.

A Londra la Graduate Developers Community sta lavorando con le università per affrontare queste lacune, cercando di introdurre tecniche di ingegneria del software a basso impatto per gli studenti da utilizzare con il loro lavoro corso.

Voglio dire, perché non costruire quell'albero B * ma inserire il codice nel controllo del codice sorgente, tenere traccia dei bug in un tracker dei problemi e persino scrivere prima alcuni test? :)

    
risposta data 23.04.2011 - 14:28
fonte
3

Sono d'accordo sul fatto che il divario sia abbastanza grande. Un po 'più grande o più piccolo a seconda di quale sia il tuo progetto di vita reale e sul tuo specifico programma CS, ma abbastanza grande da far pensare che ogni azienda dovrebbe investire in un serio programma di mentoring per i neolaureati che iniziano con loro.

Lo hai superato lavorando a progetti reali dal vivo. Che si tratti di uno stagista in un'azienda che prende in seria considerazione gli stage, lavora a un progetto FOSS, crea il tuo progetto o inizia il tuo primo lavoro.

Sono d'accordo sul fatto che iniziare su un progetto FOSS può essere scoraggiante, specialmente se si tenta di entrare in un progetto in cui il mentoring di nuove persone è limitato al consiglio "basta leggere il codice sorgente". La mia raccomandazione è di iniziare il tuo progetto, qualcosa che farà un uso pesante di un progetto FOSS che trovi interessante, prima o poi ti imbatterai in qualcosa di strano e / o bug o mal documentato. Inizia da qui a tuffarti nel codice del progetto FOSS. Scrivi un test case che documenta il comportamento strano / buggy, scrivi della documentazione e guarda come la comunità risponde a una cortese richiesta di esaminarlo.

    
risposta data 23.04.2011 - 10:54
fonte
1

Molti programmatori che conosco, me incluso, hanno insegnato elettronica, non informatica, all'università. Ok, lavoriamo su software embedded.

    
risposta data 23.04.2011 - 10:40
fonte

Leggi altre domande sui tag