首先我们得知道这问题的答案是个变量，他依赖于你的目标和天资能力，绝不唯一，当然大学的课程设置往往是唯一的，所以会有点矛盾。
这里最关键的东西是目标，大学学习只是达成最终目标高度的一个环节，他应该为最终目标服务。
当然大学生很难清楚的知道自己的目标究竟在那里，但要总归要大致知道自己的方向。
这个之所以关键是因为，这直接决定你应不应该学习某个东西，我是在做了很多年软件后，才发现软件和软件的差别其实比马和牛的差别还要大。
用流行的分类方法比如：前端开发、后端开发、。net开发，Java开发等会让人迷失焦点，所以我一直觉得Barry W Boehm在《软件成本估算：COCOMOII模型方法》里的分类方法对学习更有帮助。
在这个分类方法里软件被分了三层：最底层是基础结构型（平台）软件的开发，中间层次是开发工具、系统集成、中间件，最上层是终端用户编程，也可以理解为一般应用的开发。
同时作者还补充了份数据说：在2005年95%的美国程序员是在做终端用户编程。
这似乎把话题扯开了，但其实不是，关键要大致定位下自己的方向，因为对于目标是基础结构的程序员和目标是一般应用的程序员，他们要学习的东西差别很大。
Donald Knuth的《计算机程序设计艺术》不是没用，但如果你花了2年把他啃了一遍回头专门做应用开发，那它真的用处不大。
至少和一个精通具体语言、框架、设计模式、面向对象、UML的人比只是钻研了《计算机程序设计艺术》的人反倒是在劣势，虽然可能后者更花时间。
反过来讲则是在算法密集型的工作里，那优劣情形就会掉过来。
无疑的什么都精通最好，但人的时间是有限的，而软件相关的知识是无限的，所以把学习聚焦在自己的目标上非常关键。
而目标是什么则要根据自己的实际情形来定，假设说你真的感觉自己的能力挺好，就想做基础结构型的东西，去做MapReduce,去做操作系统等等，那首先要认识到的是干这个的人很少，竞争很激烈。
如果说在2005年美国只有5%的程序员是干这个的，那我估计今天在中国也顶多是这么个比例。
个人感觉，大学的计算机课程还真都是往这个方向培养人的，一旦真的走这个方向，那么大学的计算机课程还真用的上，需要好好学习，天天向上。当然只上课也不行，把课上学的东西实践起来也很关键（比如开源项目），这里麻烦的事情是，干这个的可能只有5%,很多人即使很努力也不一定挤的上去。
那么假设说一个人很现实，说：国内排名靠前的几所学校凑凑也就5%了，竞争太激烈，我不选这个目标方向，我还是95%里做做吧，那这个时候我应该学什么？
我个人认为主要要学好一些比较硬的，需要大块时间学习的东西，而不要在花里胡哨的东西上多费时间。
硬的东西是指：
数据结构和基本算法。
不管是不是做基础结构性软件，基本的数据结构和算法知识还是要有的。
很可能不太会有自己从头写数据结构和算法的机会，但如果复杂度不知道怎么算，链表、红黑树、哈希表的差别都不知道，那就怎么都玄。
精通一门编程语言
具体是那个可以根据实际情形来选，但这里强调的是语言，不是IDE和框架，可以通俗理解为每个关键字背后的含义要整清楚。
1,这里的陷阱是学一堆语言，但那个都不精。
2,精读一个有点规模的开源项目（至少要超过2万行），要找那种规模不太大，又比较有名的项目，一定要精读，争取每行都懂。
3,累积一定的代码量，不算IDE帮助生成的，争取也在2万行之上。
4,面向对象和设计模式，这点最好配合着下一点一起做。
5,从头考察一下某个框架，考察某个框架的内存机制、线程机制等。
整个学习过程中最常见的陷阱是学会操作一堆IDE和框架的使用，但实际上这事儿价值不大，程序员的价值符合反木桶原理，啥都知道一点的，大多时候不如某个上精通的。
同时除非很特别的公司，大一点的公司并不期望毕业生过来就能干活。
