首先我們得知道這問題的答案是個變量，他依賴于你的目標和天資能力，絕不唯一。當然大學的課程設置往往是唯一的，所以會有點矛盾。

這里最關鍵的東西是目標，大學學習只是達成最終目標高度的一個環節，他應該為最終目標服務。

當然大學生很難清楚的知道自己的目標究竟在那里，但要總歸要大致知道自己的方向。

這個之所以關鍵是因為，這直接決定你應不應該學習某個東西。我是在做了很多年軟件后，才發現軟件和軟件的差別其實比馬和牛的差別還要大。

用流行的分類方法比如：前端開發、后端開發、.net開發，Java開發等會讓人迷失焦點，

所以我一直覺得Barry W Boehm在《軟件成本估算：COCOMOII模型方法》里的分類方法對學習更有幫助。

在這個分類方法里軟件被分了三層：最底層是基礎結構型（平臺）軟件的開發；中間層次是開發工具、系統集成、中間件；最上層是終端用戶編程，也可以理解為一般應用的開發。

同時作者還補充了份數據說：在2005年95%的美國程序員是在做終端用戶編程。

這似乎把話題扯開了，但其實不是，關鍵要大致定位下自己的方向。因為對于目標是基礎結構的程序員和目標是一般應用的程序員，他們要學習的東西差別很大。

Donald Knuth的《計算機程序設計藝術》不是沒用，但如果你花了2年把他啃了一遍回頭專門做應用開發，那它真的用處不大。

至少和一個精通具體語言、框架、設計模式、面向對象、UML的人比只是鉆研了《計算機程序設計藝術》的人反倒是在劣勢，雖然可能后者更花時間。

反過來講則是在算法密集型的工作里，那優劣情形就會掉過來。

無疑的什么都精通最好，但人的時間是有限的，而軟件相關的知識是無限的，所以把學習聚焦在自己的目標上非常關鍵。

而目標是什么則要根據自己的實際情形來定。

假設說你真的感覺自己的能力挺好，就想做基礎結構型的東西，去做MapReduce，去做操作系統等等，那首先要認識到的是干這個的人很少，競爭很激烈。

如果說在2005年美國只有5%的程序員是干這個的，那我估計今天在中國也頂多是這么個比例。

個人感覺，大學的計算機課程還真都是往這個方向培養人的，一旦真的走這個方向，那么大學的計算機課程還真用的上。需要好好學習，天天向上。

當然只上課也不行，把課上學的東西實踐起來也很關鍵（比如開源項目）。

這里麻煩的事情是，干這個的可能只有5%，很多人即使很努力也不一定擠的上去。

那么假設說一個人很現實，說：國內排名靠前的幾所學校湊湊也就5%了，競爭太激烈，我不選這個目標方向，我還是95%里做做吧，那這個時候我應該學什么？

我個人認為主要要學好一些比較硬的，需要大塊時間學習的東西，而不要在花里胡哨的東西上多費時間。

硬的東西是指：

數據結構和基本算法。

不管是不是做基礎結構性軟件，基本的數據結構和算法知識還是要有的。

很可能不太會有自己從頭寫數據結構和算法的機會，但如果復雜度不知道怎么算，鏈表、紅黑樹、哈希表的差別都不知道，那就怎么都玄。

精通一門編程語言

具體是那個可以根據實際情形來選。但這里強調的是語言，不是IDE和框架。可以通俗理解為每個關鍵字背后的含義要整清楚。

這里的陷阱是學一堆語言，但那個都不精。

精讀一個有點規模的開源項目（至少要超過2萬行）

要找那種規模不太大，又比較有名的項目，一定要精讀，爭取每行都懂。

累積一定的代碼量

不算IDE幫助生成的，爭取也在2萬行之上。

面向對象和設計模式

這點最好配合著下一點一起做。

從頭考察一下某個框架

考察某個框架的內存機制、線程機制等。

整個學習過程中最常見的陷阱是學會操作一堆IDE和框架的使用，但實際上這事兒價值不大，程序員的價值符合反木桶原理，啥都知道一點的，大多時候不如某個上精通的。

同時除非很特別的公司，大一點的公司并不期望畢業生過來就能干活。

有上面的基礎后，再突擊下，應該可以面對大部分公司的筆試和面試。