近來在CSDN結識了賀利堅老師，並仔細的讀了一下賀老師的博客，感覺賀老師是非常負責的一個大學老師，在他的博客中看到了很多他和大學生的交流。
這就促使我開始思考，如果大學再來一遍，我也還是想做軟件，那我應該在大學裏學點什麼？
最終我決定把想到的東西寫下來，希望能對在校的人有點幫助。
首先我們得知道這問題的答案是個變量，他依賴於你的目標和天資能力，絕不唯一。當然大學的課程設置往往是唯一的，所以會有點矛盾。
這裏最關鍵的東西是目標，大學學習只是達成最終目標高度的一個環節，他應該爲最終目標服務。
當然大學生很難清楚的知道自己的目標究竟在那裏，但要總歸要大致知道自己的方向。
這個之所以關鍵是因爲，這直接決定你應不應該學習某個東西。我是在做了很多年軟件後，才發現軟件和軟件的差別其實比馬和牛的差別還要大。
用流行的分類方法比如：前端開發、後端開發、.net開發，Java開發等會讓人迷失焦點，
所以我一直覺得Barry W Boehm在《軟件成本估算：COCOMOII模型方法》裏的分類方法對學習更有幫助。
在這個分類方法裏軟件被分了三層：最底層是基礎結構型（平臺）軟件的開發；中間層次是開發工具、系統集成、中間件；最上層是終端用戶編程，也可以理解爲一般應用的開發。
同時作者還補充了份數據說：在2005年95%的美國程序員是在做終端用戶編程。
這似乎把話題扯開了，但其實不是，關鍵要大致定位下自己的方向。因爲對於目標是基礎結構的程序員和目標是一般應用的程序員，他們要學習的東西差別很大。
Donald Knuth的《計算機程序設計藝術》不是沒用，但如果你花了2年把他啃了一遍回頭專門做應用開發，那它真的用處不大。
至少和一個精通具體語言、框架、設計模式、面向對象、UML的人比只是鑽研了《計算機程序設計藝術》的人反倒是在劣勢，雖然可能後者更花時間。
反過來講則是在算法密集型的工作裏，那優劣情形就會掉過來。
無疑的什麼都精通最好，但人的時間是有限的，而軟件相關的知識是無限的，所以把學習聚焦在自己的目標上非常關鍵。
而目標是什麼則要根據自己的實際情形來定。
假設說你真的感覺自己的能力挺好，就想做基礎結構型的東西，去做MapReduce，去做操作系統等等，那首先要認識到的是幹這個的人很少，競爭很激烈。
如果說在2005年美國只有5%的程序員是幹這個的，那我估計今天在中國也頂多是這麼個比例。
個人感覺，大學的計算機課程還真都是往這個方向培養人的，一旦真的走這個方向，那麼大學的計算機課程還真用的上。需要好好學習，天天向上。
當然只上課也不行，把課上學的東西實踐起來也很關鍵（比如開源項目)。
這裏麻煩的事情是，幹這個的可能只有5%，很多人即使很努力也不一定擠的上去。
那麼假設說一個人很現實，說：國內排名靠前的幾所學校湊湊也就5%了，競爭太激烈，我不選這個目標方向，我還是95%裏做做吧，那這個時候我應該學什麼？
我個人認爲主要要學好一些比較硬的，需要大塊時間學習的東西，而不要在花裏胡哨的東西上多費時間。
硬的東西是指：
- 數據結構和基本算法。
不管是不是做基礎結構性軟件，基本的數據結構和算法知識還是要有的。
很可能不太會有自己從頭寫數據結構和算法的機會，但如果複雜度不知道怎麼算，鏈表、紅黑樹、哈希表的差別都不知道，那就怎麼都玄。
- 精通一門編程語言
具體是那個可以根據實際情形來選。但這裏強調的是語言，不是IDE和框架。可以通俗理解爲每個關鍵字背後的含義要整清楚。
這裏的陷阱是學一堆語言，但那個都不精。
- 精讀一個有點規模的開源項目（至少要超過2萬行）
要找那種規模不太大，又比較有名的項目，一定要精讀，爭取每行都懂。
- 累積一定的代碼量
不算IDE幫助生成的，爭取也在2萬行之上。
- 面向對象和設計模式
這點最好配合着下一點一起做。
- 從頭考察一下某個框架
考察某個框架的內存機制、線程機制等。
整個學習過程中最常見的陷阱是學會操作一堆IDE和框架的使用，但實際上這事兒價值不大，程序員的價值符合反木桶原理，啥都知道一點的，大多時候不如某個上精通的。
同時除非很特別的公司，大一點的公司並不期望畢業生過來就能幹活。
有上面的基礎後，再突擊下，應該可以面對大部分公司的筆試和麪試。
------------------------------------------------------------------------------------------------------------------------------------
理想流 + 軟件 = 《完美軟件開發：方法與邏輯》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和邏輯推演本質，追求真理。
