眼下比较常用的软件知识归类法是以关键字为导向的，但感觉这种分类法挺误人子弟的。
比如：
· 编程语言与程序设计
· 软件工程及软件方法学
· 软件项目管理
· 软件需求
· UML
· 建模
· 极限编程
· 软件方法/软件工程
· 面向对象
· 软件质量、软件测试及维护
· 软件过程
· CMM(软件能力成熟度模型)
· 设计模式
· ... ...
“设计模式”，“极限编程”和“面向对象”之所以成为不同的类别主要的原因应该是他们使用了不同的关键字，而并非两者间本质上有什么区别。
这么分类的好处是，找书比较方便，坏处是对学习帮助较小，有点误人子弟。
因此，我们需要一种新的软件知识归类法：
软件的直接知识可以被分为三大类：
①用于打造概念边界并且优化概念间逻辑关系的知识。比如，面向对象分析和设计。
②用于实现概念和逻辑的通用领域知识。比如编程语言。
③用于解决指定领域问题的专业的领域知识。比如图形算法。
在很多场合③并不是必须的，但①和②则是不可分割的，并不存在孰轻孰重的问题。没有概念无法形成逻辑，没有逻辑，概念的彻底定义更是无从谈起。而没有载体（比如编程语言或UML）概念和逻辑根本就无法表达。事实上编程语言的演化很大程度上是想把这种表达变的更容易。
而与软件有关联的间接知识则有4大类：
①需求开发和描述。比如规格说明的编写。※1
②估算。比如功能点方法等。
③测试。比如验收测试等。
④软件工程和方法论。比如CMMI和敏捷。
※1 把需求开发算作软件的直接知识也可以。
根据，上面的分类，我们可以重新制作一份分类的表单。
关于软件的直接知识：
· 通用的领域知识
· 编程语言（C/C++，Java，C#，Python，Perl等）
· 框架和类库(MFC，Boost，Struts,，Hibernate等)
· 平台(Windows API，POSIX，.Net Framework※2，Java API，C/C++ Runtime Library
· 计算机体系结构(CPU指令，虚拟存储等)
· 实用技巧(调试方法，代码生成器等 )
· ... ...
※2 有的时候子类别间的界限并不是很容易界定，其中一个主要原因就是存在着像.Net Framework这样涵盖了过多内容的概念。
· 概念和逻辑创建和优化
· 面向对象分析和设计/结构化分析和设计
· 设计模式
· 重构
· 契约式编程
· UML ※3
· ... ...
※3 从形式上来看UML更近似于一种编程语言，但从其目的上来看也许归在这里是更合适的一种选择。
· 专业领域知识
· 图形图像算法
· 网络协议
· 人工智能
· 数值/非数值类算法
· ... ...
关于软件的间接知识：
· 需求开发和描述
· ... ...
· 估算
· 估算法。比如，COCOMO, FP等。
· 估算术。比如，使用计数等原始办法。
· 测试
· 软件工程和方法论
· 轻量型方法论。比如敏捷。
· 大方法论。比如CMMI
· 综合分析。比如，《人月神话》，《人件》所做的工作。
在这份表单里面，诸如管理相关的内容并未被列入，主要关注的是软件开发以及和软件开发直接关联的领域。而管理等会在综合能力归类法一章做进一步的分析。
有了上述分类之后，我们可以回到一个非常古老的话题：
究竟应该如何学习程序设计？
根据软件的本质，我们可以说，由于程序设计主要解决概念与逻辑的问题，而概念与逻辑问题与现实紧密相关，因此不存在一种记住某些定理，接下来有选择的进行应用，最终就会产出好的产品（作品）这样的因果。只能是学一点，实践一点，总结一点这样的不断循环。
根据上面的分类，一种具体的可能的学习方法是：
Step1: 选择一种通用的领域知识。
比如： C# + .Net Framework,Java
Step2:
在实践过程中，逐步提高概念和逻辑创建和优化的能力
比如： 面向对象方法
Step3:
如果有机会：深入研究选定的专业领域知识，并且扩展自己的通用领域知识。
对大多数开发人员而言，直接接触某些专业领域知识的机会比较少，更多的时候是集中于前两个步骤，这个时候有一个误区需要避免。
掌握的语言，平台和类库越多越好这样一种倾向，虽然有时候有其现实合理性，但从学习的角度看，却是一种误区。频繁切换语言，平台和类库的同时，往往就浪费了一些去思考软件的本质问题的机会，最终对个人成长不利。
现实中有些企业中生存压力过大，对有些事情是没有选择权利的，那也没辙。
但考虑到公司和个人间本质上更倾向于价值交换（你干活，我付钱）。你干的事情蕴含的价值没上来（比如说：新毕业生也能干），那你想收入太高也不太可能，或者说可能了也危险。