有关架构设计

对于“架构”这个词，我是有爱有恨，主要是因为目前来说，这个概念被滥用了，所以就恨起来了，但是到目前为止还没有哪个词汇能描述有关软件设计话题全部的词汇，还是架构比较贴近，就像一个建筑师设计自己的房子一样，所以爱！什么是架构？我认为架构无处不在，很多人认为架构就是设计软件的结构，就和建筑师做的事情一样，我认为错误的观念害死人，无可否认我们这个行业中很多管理方式和术语都来之于其他行业，比如建筑行业，但是软件行业毕竟有自己的特殊性，毕竟是创意产业！那么架构这个词，是战略词汇，我的理解，在商务阶段就有架构！

在商务阶段，也就是谈生意的阶段，比如谈一个软件项目，那么我们这一方必须知道这个项目的前景，有没有发展，有没有钱赚，能不能做！那么必须建立在高层或者这个人的远见和日积月累的知识和经验上面，才能发现这个项目的价值，比如Bill看重了.Net,微软对这个.Net投下最大的力量来作，就是这个问题，也是战略问题，必须有全局观念的问题，也是属于架构问题的！

在需求阶段，如果没有对需求各个方面的准确理解，或者不知道各个方面的关系，或者不知道如何引导客户以便丰富和准确表达需求，如何做一个软件？这是全局的问题，又必须建立在长期的实践当中去总结，并且能将业务问题进行提炼和抽象，这也是架构问题。

在设计阶段，也许这正是人们认为最"架构“的部分罢，但是很多人认为在High level级别就架构，也就是在软件的整体设计和大的设计方向有架构，我认为也是错误的挂念，一个系统，必须从多个视图来设计，多视图的方法才能把事情讲清楚，

比如动态的关系，静态的关系，数据流等等，都是一个系统的不同方面，也就是说不仅仅是大的全局设计，组件设计必须也涉及很多知识和技巧，比如Log,很可能的情况要设计成一个方面，用AOP.不仅仅涉及想象力的问题和经验的问题，还涉及具体技术的问题，需要大量的积累和运用才能做到！每个组件又不是孤立的，相互影响的，不能孤立地看问题，设计类的时候更加接近技术，也必须考虑本身的和关联的，还有与环境的，与其他类的关系，没有大量的实践和全局观念也不成！对于一个方法，也必须有设计上的，思想上的，全局上的考虑，比如这个变量要不要？这段代码效率高不高，简洁不？好维护不？从一个系统的具体设计，抽象，到具体的实现无处不在”设计、思想、全局的“的东西，每一个血管都有架构。很多人只关心如何实现，但是没有一个立体的，系统的对一个事情的看法，如果把自己的那部分做好，不是接口参数错了（没有考虑和其他部分的交互），就是不好维护！

在测试阶段，其实测试的计划，比如CASE在需求就开始了，跟随全过程，比如需求阶段，就必须有产品测试的计划出来，设计阶段就必须有系统测试的计划出来，在详细设计时就必须搞出单体测试的计划出来，需要大量的实践经验，找出可能的问题出来，测试不能找到所有的bug，遍历所有的可能性也不可能，必须寻找一个有效的测试集合，这就需要有对需求、设计和各方面信息的思考和提炼，测试也必须设计，这不是架构吗？

在维护阶段，在运维阶段，都有设计，都有必须对全局的理解，都必须有分析，都必须有大量的实践，都和架构有关。也就是说从战略到战术，从高层到底层，无处不在的架构。

 

所以一个架构师不仅仅在技术上有很高的造诣，还必须兼通商务，需求，人的管理，等等，比较强的沟通能力，等等。

必须有成熟的思想体系支持他能正确分析问题等等。

 

但是全才不可能，抓住根本就是关键，人的思想方式和体系就是关键，因为在这些指导之下，才能获得知识，获得经验，获得各种工具，获得各种你需要的东西!最基本的思想方式就是关注点分离和结合，也就是说对待一个整体概念，先进行关注点的分离和抽象，然后用简单有效的方式在结合起来，让各个部分各司其职，又形成一个整理，也就是一个系统，一个好的架构，从各个侧面来分解关注点，能有效地保持整体的概念完整性，那么这个系统就是协调的。