软件知识分类法（兼谈收入这事儿）

#好久没来，以此文章清清杂草吧！

眼下比较常用的软件知识归类法是以关键字为导向的，但感觉这种分类法挺误人子弟的。

比如：

·编程语言与程序设计

·软件工程及软件方法学

·软件项目管理

·软件需求

·UML

·建模

·极限编程

·软件方法/软件工程

·面向对象

·软件质量、软件测试及维护

·软件过程

·CMM(软件能力成熟度模型)

·设计模式

·......

“设计模式”，“极限编程”和“面向对象”之所以成为不同的类别主要的原因应该是他们使用了不同的关键字，而并非两者间本质上有什么区别。

这么分类的好处是，找书比较方便，坏处是对学习帮助较小，有点误人子弟。

因此，我们需要一种新的软件知识归类法：

软件的直接知识可以被分为三大类：

①用于打造概念边界并且优化概念间逻辑关系的知识。比如，面向对象分析和设计。

②用于实现概念和逻辑的通用领域知识。比如编程语言。

③用于解决指定领域问题的专业的领域知识。比如图形算法。

在很多场合③并不是必须的，但①和②则是不可分割的，并不存在孰轻孰重的问题。没有概念无法形成逻辑，没有逻辑，概念的彻底定义更是无从谈起。而没有载体（比如编程语言或UML）概念和逻辑根本就无法表达。事实上编程语言的演化很大程度上是想把这种表达变的更容易。

而与软件有关联的间接知识则有4大类：

①需求开发和描述。比如规格说明的编写。※1

②估算。比如功能点方法等。

③测试。比如验收测试等。

④软件工程和方法论。比如CMMI和敏捷。

※1 把需求开发算作软件的直接知识也可以。

根据，上面的分类，我们可以重新制作一份分类的表单。

关于软件的直接知识：

·通用的领域知识

·编程语言（C/C++，Java，C#，Python，Perl等）

·框架和类库(MFC，Boost，Struts,，Hibernate等)

·平台(WindowsAPI，POSIX，.NetFramework※2，JavaAPI，C/C++RuntimeLibrary

·计算机体系结构(CPU指令，虚拟存储等)

·实用技巧(调试方法，代码生成器等)

·......

※2有的时候子类别间的界限并不是很容易界定，其中一个主要原因就是存在着像.NetFramework这样涵盖了过多内容的概念。

·概念和逻辑创建和优化

·面向对象分析和设计/结构化分析和设计

·设计模式

·重构

·契约式编程

·UML※3

·......

※3从形式上来看UML更近似于一种编程语言，但从其目的上来看也许归在这里是更合适的一种选择。

·专业领域知识

·图形图像算法

·网络协议

·人工智能

·数值/非数值类算法

·......

关于软件的间接知识：

·需求开发和描述

·......

·估算

·估算法。比如，COCOMO,FP等。

·估算术。比如，使用计数等原始办法。

·测试

·软件工程和方法论

·轻量型方法论。比如敏捷。

·大方法论。比如CMMI

·综合分析。比如，《人月神话》，《人件》所做的工作。

在这份表单里面，诸如管理相关的内容并未被列入，主要关注的是软件开发以及和软件开发直接关联的领域。而管理等会在综合能力归类法一章做进一步的分析。

有了上述分类之后，我们可以回到一个非常古老的话题：

究竟应该如何学习程序设计？

根据软件的本质，我们可以说，由于程序设计主要解决概念与逻辑的问题，而概念与逻辑问题与现实紧密相关，因此不存在一种记住某些定理，接下来有选择的进行应用，最终就会产出好的产品（作品）这样的因果。只能是学一点，实践一点，总结一点这样的不断循环。

根据上面的分类，一种具体的可能的学习方法是：

Step1: 选择一种通用的领域知识。

比如：C#+.NetFramework,Java

Step2:

在实践过程中，逐步提高概念和逻辑创建和优化的能力

比如：面向对象方法

Step3:

如果有机会：深入研究选定的专业领域知识，并且扩展自己的通用领域知识。

对大多数开发人员而言，直接接触某些专业领域知识的机会比较少，更多的时候是集中于前两个步骤，这个时候有一个误区需要避免。

掌握的语言，平台和类库越多越好这样一种倾向，虽然有时候有其现实合理性，但从学习的角度看，却是一种误区。频繁切换语言，平台和类库的同时，往往就浪费了一些去思考软件的本质问题的机会，最终对个人成长不利。

现实中有些企业中生存压力过大，对有些事情是没有选择权利的，那也没辙。

但考虑到公司和个人间本质上更倾向于价值交换（你干活，我付钱）。你干的事情蕴含的价值没上来（比如说：新毕业生也能干），那你想收入太高也不太可能，或者说可能了也危险。