关于构建自己的知识体系架构的一点个人思考 2007年10月08日 22:41
软件观点 软件架构 软件方法论
顶一下
我们都知道，一个好的架构对于企业应用软件来说是非常重要的，灵活的架构可以快速应对多变的业务需求。很多软件只要业务需求的一点小变，就得修改很多地方，牵一发而动全身，导致程序员疲于应付这样的需求变化，经常抱怨客户的需求变化太快了，甚至说客户的需求太变态了。其实，换一个角度想，如果自己是客户的话自己也肯定会提出各种各样的需求，因为市场在变嘛，需求是软件的龙头，肯定是要变的。既然需求是变化的，那就只能向软件本身挖掘空间了，所以才慢慢地发现了软件架构（注意，本文所说的软件架构都是指企业应用软件的技术架构而不包括应用架构）的重要性，这几年架构这个概念相当火，架构师也成了职场的香喷喷了。但是要搭建一个灵活的可扩展可维护的架构可以说是非常难的，别说应对百分百的需求变化，就是能应对百分之七八十的需求变化的架构就非常不错了。那么，是什么原因使得搭建一个良好的软件架构会那么难呢？设计一个架构对我们设计人员有什么样的要求呢？需要什么知识呢？其实，仔细想一想，业务需求多变是对软件提出的一个挑战，而由此产生的多变的软件复杂问题何尝又不是对我们的知识的一个挑战呢？软件架构的问题就是我们的知识的业务需求，设计不出良好的软件架构的深层次原因就在于我们的知识太凌乱，不成架构，不成体系，和软件没有良好的架构就不能应对业务需求的变化是一个道理。下面我就把构件自己的知识体系架构的一点想法和思考写出来与大家交流。
研究问题要把它放到动态的运动过程中去把握它，了解它的发展历程，由表及里，去伪存真，这样才能抓住它的本质规律。前面说了知识架构和软件架构类似，而且是里与表的关系，那么我们还是采取由表及里的方法，先了解一下软件架构。
首先还是了解一下软件架构的动态运动过程，软件架构从低级到高级经历了这么几个形态：一，基础工具类库形态，在这一形态，我们发现编程的时候有很多相同的功能可以提取出来，比如字符串的处理，日期转换，数字处理以及一些界面的控件和处理等，把这些功能封装成类，在各个单元程序里面都可以调用它，提高功能复用。二，逻辑层框架形态，在这一形态，我们发现在前一形态的基础上有很多程序的逻辑调用顺序也是相同的，并且对前一形态的基础工具类进行了逻辑层次划分如表示层，业务层，持久层等，对这些逻辑调用进行抽取，形成模板，这就是逻辑层框架，从设计模式角度讲，这一层整个就是一模板方法模式的应用。三，架构形态，在这个形态我们发现程序的逻辑层之间的调用逻辑也是相同的，所以进一步进行抽取，形成整个企业应用软件的模板。四，业务平台形态，前面三个形态可以说都是软件技术上的形态，没有业务逻辑的提取，业务平台形态就是在架构形态的基础上对相同的业务实体和相关逻辑进行提取，供上层应用系统直接调用，大大提高应用系统的生产效率。五，完全业务领域模型驱动形态，这一形态的应用系统可以说都不用程序员的参与了，系统直接由业务领域模型驱动，由系统分析人员对业务领域建模后得到业务领域模型，再由业务平台环境直接编译或解释执行。这一形态在目前来说只能是理想形态了，与现在的现实相去甚远，但我相信这是方向，我们是可以接近这个目标的。而且现在领域建模的理论和相关技术工具都在不断地成熟和完善。目前，大多数软件公司和个人都还只是停留在第一形态，达到第二形态的有自己的框架的比较少，达到第三形态的也大多是用第三方的开源逻辑框架的一个简单的拼装和支撑，能达到第四形态的更是凤毛麟角了，达到第五形态的现在肯定还没有。虽然前面说的软件架构从低级到高级经历了这个几个形态，但是这几个形态不是严格地从时间顺序发展而来的，而是先有能够运行的软件，然后慢慢地衍生出架构，框架，类库来的，是不断地沉淀出来的，只是在类库沉淀的基础上也逐渐地完善出框架，在框架沉淀的基础上也逐渐地完善架构。这些过程在时间上可以说是并行的。
如果把企业应用软件比做一棵树的话，那么架构就是树干，框架就是树枝，类库就是枝节，具体的类就是树叶，直接面向用户的应用系统就是这棵树的果实。读到这里，大家可能也发现了，这棵树还缺少了一个最重要的部分，那就是树根。这棵树的树根就是我要说的知识体系架构。物有本末，事有始终，知其先后，则近道矣！凡事纠出了根才算是抓住了本，扎住根，然后再强干弱枝，从源溯流地去学习、研究，则一切尽在掌握！下面就正式说说知识体系架构。
知识体系架构本身也呈现出树的特征，从这个角度说，企业应用软件也可以说是知识体系架构的一棵子树，或者说是它的一个树枝。我们搞计算机软件的，对于树的概念应该不会陌生，数据结构里面也学过树的概念。我们这里所说的树的概念可以说是植物世界里的树和计算机世界里的树的一个结合，具有双重特征。
知识体系架构树的树根毫无疑问是哲学，包括世界观，价值观，人生观，方法论，在我们做企业应用软件这方面，方法论尤其重要，我在另外的帖子里面也写过方法的重要性，主要是要培养辩证的方法论，科学的思维方法，这里就不多说了。
由树根延伸出来的树干那就是基础学科，树干再衍生出树枝，有自然学科，社会学科，人文艺术学科等。自然学科这个树枝又可以衍生出物理学，化学，数学，生物学等等分枝。社会学科又可以衍生出政治学，历史学，经济学等分枝。人文艺术学科又可以衍生出文学，音乐，绘画等分枝。分枝可以再生分枝，无穷尽也。就像植物树一样，树枝可以交叉，知识体系架构树的树枝也可以交叉，企业应用软件可以说是由物理学衍生出电子学，再分出计算机学科，再分出软件学科，并交叉人文艺术学，企业管理学，经济学等分枝而衍生出来的一枝分枝。知道了这个前提，我们再来看看企业应用软件这个分枝的子树结构。
那么，企业应用软件的树干是什么呢？还是把它放到动态的运动过程即软件的生命周期中去研究它吧，那么这个树干就是软件的生命周期运动。由这棵树干衍生出需求分析，设计，开发，测试，维护等分枝。需求分析又可以衍生出需求分析，需求管理等。设计又可以衍生出架构设计，模块设计，详细设计等。开发又可以衍生出编程语言，脚本语言，数据库语言，开发过程等，而c++、java等只是编程语言这个枝节上的两片树叶。测试可以衍生出单元测试，模块测试，功能测试等。维护可以衍生出重构等。这样的一棵树其实用语言不太好表达，用图形的方式更直观，一目了然。我觉得我们每一个人都应该能画出一颗自己的知识架构树。这样才能真正做到胸有成竹。学习新技术，新知识的时候首先要能迅速把它定位到自己的知识架构树的恰当位置上，然后才是深入地钻研它。所有的具体的技术，技巧都只不过是这棵架构树的一片树叶，只有从上往下看，才能知道它在整体中占的分量，才能真正看清楚它的角色，避免迷失在树叶里面而一叶障目不见泰山。而且，有一句古话说得好，落叶归根，树叶熟了要落掉归根，具体的技术研究过了以后也要回过头来返哺一下树根，那就是我们的哲学，方法论。只有这样我们的大本大源才能源远流长，经久不衰。
世人只知道种植植物树，自己心中的这个知识树又有几个人苦心地种植和栽培呢？要记得经常给这棵树剪剪枝，浇浇水！用一辈子的时间种植一棵树并精心呵护，这棵树必将长成参天大树，雨天可以遮风挡雨，夏天可以乘凉！
上面说的知识架构树并没有具体的说，因为我觉得在每个人的心中这棵树都是不同的，就像世上没有相同的两片树叶一样。我在这里只是提出这个问题而已，目的是与大家交流，共同提高，相互学习。
关于构建自己的知识体系架构的一点个人思考 2007年10月08日 22:41
软件观点 软件架构 软件方法论
顶一下
我们都知道，一个好的架构对于企业应用软件来说是非常重要的，灵活的架构可以快速应对多变的业务需求。很多软件只要业务需求的一点小变，就得修改很多地方，牵一发而动全身，导致程序员疲于应付这样的需求变化，经常抱怨客户的需求变化太快了，甚至说客户的需求太变态了。其实，换一个角度想，如果自己是客户的话自己也肯定会提出各种各样的需求，因为市场在变嘛，需求是软件的龙头，肯定是要变的。既然需求是变化的，那就只能向软件本身挖掘空间了，所以才慢慢地发现了软件架构（注意，本文所说的软件架构都是指企业应用软件的技术架构而不包括应用架构）的重要性，这几年架构这个概念相当火，架构师也成了职场的香喷喷了。但是要搭建一个灵活的可扩展可维护的架构可以说是非常难的，别说应对百分百的需求变化，就是能应对百分之七八十的需求变化的架构就非常不错了。那么，是什么原因使得搭建一个良好的软件架构会那么难呢？设计一个架构对我们设计人员有什么样的要求呢？需要什么知识呢？其实，仔细想一想，业务需求多变是对软件提出的一个挑战，而由此产生的多变的软件复杂问题何尝又不是对我们的知识的一个挑战呢？软件架构的问题就是我们的知识的业务需求，设计不出良好的软件架构的深层次原因就在于我们的知识太凌乱，不成架构，不成体系，和软件没有良好的架构就不能应对业务需求的变化是一个道理。下面我就把构件自己的知识体系架构的一点想法和思考写出来与大家交流。
研究问题要把它放到动态的运动过程中去把握它，了解它的发展历程，由表及里，去伪存真，这样才能抓住它的本质规律。前面说了知识架构和软件架构类似，而且是里与表的关系，那么我们还是采取由表及里的方法，先了解一下软件架构。
首先还是了解一下软件架构的动态运动过程，软件架构从低级到高级经历了这么几个形态：一，基础工具类库形态，在这一形态，我们发现编程的时候有很多相同的功能可以提取出来，比如字符串的处理，日期转换，数字处理以及一些界面的控件和处理等，把这些功能封装成类，在各个单元程序里面都可以调用它，提高功能复用。二，逻辑层框架形态，在这一形态，我们发现在前一形态的基础上有很多程序的逻辑调用顺序也是相同的，并且对前一形态的基础工具类进行了逻辑层次划分如表示层，业务层，持久层等，对这些逻辑调用进行抽取，形成模板，这就是逻辑层框架，从设计模式角度讲，这一层整个就是一模板方法模式的应用。三，架构形态，在这个形态我们发现程序的逻辑层之间的调用逻辑也是相同的，所以进一步进行抽取，形成整个企业应用软件的模板。四，业务平台形态，前面三个形态可以说都是软件技术上的形态，没有业务逻辑的提取，业务平台形态就是在架构形态的基础上对相同的业务实体和相关逻辑进行提取，供上层应用系统直接调用，大大提高应用系统的生产效率。五，完全业务领域模型驱动形态，这一形态的应用系统可以说都不用程序员的参与了，系统直接由业务领域模型驱动，由系统分析人员对业务领域建模后得到业务领域模型，再由业务平台环境直接编译或解释执行。这一形态在目前来说只能是理想形态了，与现在的现实相去甚远，但我相信这是方向，我们是可以接近这个目标的。而且现在领域建模的理论和相关技术工具都在不断地成熟和完善。目前，大多数软件公司和个人都还只是停留在第一形态，达到第二形态的有自己的框架的比较少，达到第三形态的也大多是用第三方的开源逻辑框架的一个简单的拼装和支撑，能达到第四形态的更是凤毛麟角了，达到第五形态的现在肯定还没有。虽然前面说的软件架构从低级到高级经历了这个几个形态，但是这几个形态不是严格地从时间顺序发展而来的，而是先有能够运行的软件，然后慢慢地衍生出架构，框架，类库来的，是不断地沉淀出来的，只是在类库沉淀的基础上也逐渐地完善出框架，在框架沉淀的基础上也逐渐地完善架构。这些过程在时间上可以说是并行的。
如果把企业应用软件比做一棵树的话，那么架构就是树干，框架就是树枝，类库就是枝节，具体的类就是树叶，直接面向用户的应用系统就是这棵树的果实。读到这里，大家可能也发现了，这棵树还缺少了一个最重要的部分，那就是树根。这棵树的树根就是我要说的知识体系架构。物有本末，事有始终，知其先后，则近道矣！凡事纠出了根才算是抓住了本，扎住根，然后再强干弱枝，从源溯流地去学习、研究，则一切尽在掌握！下面就正式说说知识体系架构。
知识体系架构本身也呈现出树的特征，从这个角度说，企业应用软件也可以说是知识体系架构的一棵子树，或者说是它的一个树枝。我们搞计算机软件的，对于树的概念应该不会陌生，数据结构里面也学过树的概念。我们这里所说的树的概念可以说是植物世界里的树和计算机世界里的树的一个结合，具有双重特征。
知识体系架构树的树根毫无疑问是哲学，包括世界观，价值观，人生观，方法论，在我们做企业应用软件这方面，方法论尤其重要，我在另外的帖子里面也写过方法的重要性，主要是要培养辩证的方法论，科学的思维方法，这里就不多说了。
由树根延伸出来的树干那就是基础学科，树干再衍生出树枝，有自然学科，社会学科，人文艺术学科等。自然学科这个树枝又可以衍生出物理学，化学，数学，生物学等等分枝。社会学科又可以衍生出政治学，历史学，经济学等分枝。人文艺术学科又可以衍生出文学，音乐，绘画等分枝。分枝可以再生分枝，无穷尽也。就像植物树一样，树枝可以交叉，知识体系架构树的树枝也可以交叉，企业应用软件可以说是由物理学衍生出电子学，再分出计算机学科，再分出软件学科，并交叉人文艺术学，企业管理学，经济学等分枝而衍生出来的一枝分枝。知道了这个前提，我们再来看看企业应用软件这个分枝的子树结构。
那么，企业应用软件的树干是什么呢？还是把它放到动态的运动过程即软件的生命周期中去研究它吧，那么这个树干就是软件的生命周期运动。由这棵树干衍生出需求分析，设计，开发，测试，维护等分枝。需求分析又可以衍生出需求分析，需求管理等。设计又可以衍生出架构设计，模块设计，详细设计等。开发又可以衍生出编程语言，脚本语言，数据库语言，开发过程等，而c++、java等只是编程语言这个枝节上的两片树叶。测试可以衍生出单元测试，模块测试，功能测试等。维护可以衍生出重构等。这样的一棵树其实用语言不太好表达，用图形的方式更直观，一目了然。我觉得我们每一个人都应该能画出一颗自己的知识架构树。这样才能真正做到胸有成竹。学习新技术，新知识的时候首先要能迅速把它定位到自己的知识架构树的恰当位置上，然后才是深入地钻研它。所有的具体的技术，技巧都只不过是这棵架构树的一片树叶，只有从上往下看，才能知道它在整体中占的分量，才能真正看清楚它的角色，避免迷失在树叶里面而一叶障目不见泰山。而且，有一句古话说得好，落叶归根，树叶熟了要落掉归根，具体的技术研究过了以后也要回过头来返哺一下树根，那就是我们的哲学，方法论。只有这样我们的大本大源才能源远流长，经久不衰。
世人只知道种植植物树，自己心中的这个知识树又有几个人苦心地种植和栽培呢？要记得经常给这棵树剪剪枝，浇浇水！用一辈子的时间种植一棵树并精心呵护，这棵树必将长成参天大树，雨天可以遮风挡雨，夏天可以乘凉！
上面说的知识架构树并没有具体的说，因为我觉得在每个人的心中这棵树都是不同的，就像世上没有相同的两片树叶一样。我在这里只是提出这个问题而已，目的是与大家交流，共同提高，相互学习。