分类： 项目管理
2009-01-06 11:06:11
【IT168技术文档】
本文节录温昱先生《软件架构设计》第8章 软件架构要做到什么程度，并将自己的理解在节录后做出描述。希望节录部分能给大家带来收获和感悟。并对我的理解部分提出建议和想法。
OK,让我们开始吧.解决软件架构到底要设计到什么程度?
* 首先，对软件架构的设计程度问题展开探讨，得出基本结论。从对“分而治之”的讨论入手，说明软件架构是团队开发的基础，从而，软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度;
* 之后，从问题入手，认识高来高去式架构设计的“症状”。主要分析实际工作中常见的架构设计不足的几种表现，找到要解决的问题;
* 然后，说明如何解决架构设计高来高去、指导不足的问题;
* 最后，结合案例，说明如何一步步地将架构设计落实到实处。
-------------------------------------------------------------------------------------
8.1 软件架构要设计到什么程度
软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度。
8.1.1 分而治之的两种方式
为什么要分而治之?简单说，就是问题太复杂了，超出了人们能够“一蹴而就”的范围。
面对一个复杂的问题，我们如何进行分而治之呢?策略有二：
一、先不把问题研究得那么深，那么细，浅尝辄止，见好就收。这种分而治之的方式称为“按问题深度分而治之”。
二、先不研究整个问题，而是研究问题的一部分，分割问题，各个击破。这种分而治之的方式称为“按问题广度分而治之”。
例如：
接口和实现分离，就是“按问题深度分而治之”的一个例子。在架构设计之时，我们往往无需深入到一个子系统的实现细节中去，而是分而治之，先确定该子系统的接口。接口的设计在整个架构设计中占有重要地位，它定义了一个子系统为其他子系统所提供服务的契约。软件架构通过明确每个子系统所要实现的接口及所要调用的接口，为我们展现了一个软件系统如何分割为多个相互协作的子系统。
“按问题广度分而治之”的例子也很常见，比如展现层、业务层和数据层的开发往往需要不同的技术,可以分派给不同的小组承担等,不一而足。
8.1.2 架构设计与详细设计
随着软件设计工作越来越复杂，将架构设计和详细设计分离已成为普遍的做法。Garlan就曾指出：“随着软件的规模和复杂度增加，算法和数据结构以外的设计问题就会出现：设计和制定系统整体结构将成为新的一类问题......这是软件架构层次的设计。”
将设计分为架构设计和详细设计，是对“按问题深度分而治之”思想的运用。
* 所谓架构设计，就是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕将系统分为哪些部分，各部分之间如何交互展开的;
* 而详细设计针对每个部分的内部进行设计。
可以这么说，软件架构设计应当解决的是全局性的、涉及不同“局部”之间交互的设计问题，而不同“局部”的设计由后续的详细设计负责。于是，在软件架构所提供的“合作契约”的指导之下，众多局部问题被很好地“按问题广度分而治之”了----对局部的设计完全可以并行进行。
总之，这种先确定软件架构，而后基于软件架构进行并行开发的做法，综合利用了两种分而治之的方法，利于控制复杂性，提高开发效率。这是一种值得推崇的开发方式，常被称为“以架构为中心的开发方法”。
8.1.3 软件架构是团队开发的基础
正如大家所看到的，因为软件变得越来越复杂了，所以单兵作战不再是普遍的软件开发方式，取而代之的是团队开发：而团队开发又反过来使软件开发更加复杂，因为现在不仅仅有技术复杂性的问题，还有管理复杂性的问题。
面对“技术复杂性”和“管理复杂性”这样的双重困难，以架构为中心的开发方法是有效的途径：
* 一方面，软件架构从大局着手，就技术方面的重大问题作出决策，构造一个具有一定抽象层次的解决方案，而不是将所有细节统统展开，从而有效地控制了“技术复杂性”。可以看出，软件架构这一步没有“把问题研究那么深、那么细”，属于“按问题深度分而治之”。对此，Ivar Jacobson给我们提供了非常形象的说法，“软件系统的架构涵盖了整个系统，尽管架构的有些部分可能只有'一寸深'”;
* 另一方面，有了软件架构设计方案之后呢?因为“架构中包含了关于各元素应如何彼此相关的信息”，从而可以把不同模块分配给不同小组分头开发，而软件架构设计方案在这些小组中间扮演“桥梁”和“合作契约”的作用。每个小组的工作覆盖了“整个问题的一部分”，各小组之间可以互相独立地进行并行工作，这种“分割问题，各个击破”的策略，属于“按问题广度分而治之”。
这两方面是相辅相成的关系。具体而言，正因为软件架构是大规模开发的基础，所以架构中应包含软件系统的各元素如何彼此相关的设计决策;也正是因为软件架构中包含了软件系统如何组织等关键决策，才使得它能够成为大规模开发的基础。
这样一来，模块的技术细节被局部化到了小组内部，内部的细节不会成为小组间协作沟通的主要内容，理顺了沟通的层次。另外，对“人尽其才”也有好处，不同小组的成员需要精通的技术各不相同。例如，用户界面层的开发小组需要了解将使用的用户界面工具包;数据管理层的并发小组需要熟悉相关的数据库、持久工具或者使用的文件系统;系统交互层的开发小组需要了解通讯和用到的中间件产品等。
由此可见，软件架构为开展系统化的团队开发奠定了基础，为解决“管理复杂性”提供了有力的支持。对此Barry Boehm曾经明确指出，“如果一个项目的系统架构(包括理论基础)尚未确定，就不应该进行此系统的全面开发。”
8.1.4 架构要进行到什么程度
既然软件架构是团队开发的基础，那么它就应该比较明确地规定后期分头开发所必须的公共性的设计约定，从而为分头开发提供足够的指导和限制。
另一方面，具体的架构设计程度还会因软件项目的不同而不同，例如航空航天领域中的软件系统对系统可靠性要求非常高，这种情况下对架构设计详细程度的要求也会比较高;同时，架构设计的程度也会受团队具体情况的影响，有类似项目经验的团队可以适当放宽标准，而分布团队或者涉及外包的情况则应更强调架构的明确性。
架构设计对软件的不同部分的设计程度并不是整齐划一的。例如，通信机制、持久化机制和消息机制等对应的公共模块，在架构设计时会设计得比较深入，因为它们较多地涉及软件的不同部分之间的交互;而具体的业务功能模块在架构设计中往往设计程度不深。
总之，关于软件架构到底要设计到什么程度，可以归纳为两句话：
* 由于项目的不同、开发团队情况的不同，软件架构的设计程度会有不同;
* 软件架构应当为开发人员提供足够的指导和限制。
8.5 总结与强调
本篇讨论了一个对软件开发和管理都有深刻影响的问题，软件架构要设计到什么程度？如果说前面讨论的架构视图关注了软件架构的横向宽度，那么本章就是关注软件架构的纵向深度。
----------------------------------------------------------------------------------
个人理解部分：
看了本章后，有一种茅塞顿开的感觉。对以下一些问题有了更清晰的理解：
1. 在架构方面，有可能是售前人员在做概要性架构，也可能是软件需求人员在做，作为众开发程序员技术掌控者的软件架构师，他需要对概要性架构进行细化。站在一个较高的地方，对整个系统不仅在业务逻辑上有清晰的理解和表述，而且要站在开发、测试、部署等人员的角度上去进行综合设计,很多时候团队部分成员在技能和专业知识上不是很成熟,在项目中,可以通过培训或者知识点的补充让成员更快的融入项目中,并很好的领会架构,使架构能真正的成为指导,能用起来。让项目组成员真正的以架构为核心,不要走出这个圈圈。并且配合项目经理做好对投资人、上级领导的沟通工作。在第5章的5视图法这个工具在此处可以发挥较大的作用。架构师给出的5视图。对概要性架构是一种补充和完善。
2. 本文也对分层架构和各分层和模块，在交互接口和交互机制提出了强调。不仅懂原理，而且要在实践中用起来。我甚至觉得，在各角色人员的分工和合作方面。也可以更加紧密的和项目经理合作，将各工种的合作方式、接口、机制进行定义。以更有效的提高工作效率。减少沟通上的时间和资源损失。并且架构师是站在整体的角度来考虑问题，所以可以将共同的部分抽象出来，并建立一套调用机制。在细节上，可以和技术员们共同讨论，以完善和优化调用机制。
3. 在对一个系统的分析方法上，提出的按广度和按深度的不同考虑角度是很有益的。其实，我个人感觉，在实际操作中，其实是在不断的交互。不断的螺旋上升的过程。结合5视图法,只有这种,才能更加清晰,更加快速的将系统的蓝图展现在众人面前。设计也是需要效率的。
4.团队开发的方式和作用。文中不仅对大团队合作开发的方式提出了有益的指导。而且我觉得稍加改变，也可以运用到小团队、小项目的合作开发中。比如和快速抛弃原型法结合。一二个开发和美工就可以利用.net快速的开发。如果在小团队中，有高明的架构做为指导，再结合较成熟的企业框架的应用。这几杆枪也可以发挥出小炮的威力的。
5.在架构设计和详细设计间的关系及应用。结合需求分析的方法。可以指导开发人员制作详细设计。减少架构师的工作量和培训提升开发人员在设计方面的能力。
6.带领团队一起进步。一起把项目做细做好。怎么把团队成员的思想往一处带是很重要的。团队中，有可能有初程、中程、高程。大家的经历、特长也不尽相同。那么怎么培训就显示尤为重要了。对一些基础性的常识、或者专业的术语在团队内进行普及。不同的岗位在项目的不同阶段，能给出指导性的纲领计划、执行方法、相关知识获取、学习方法也可以使项目组成员更好的执行架构思想和团结在架构师周围。更有利于架构的推广。当然，能带出架构师的人。更是牛人。
