2011-01-30
1、软件架构要设计到什么程度
软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度。
2、分而治之的两种方式
按深度分而治之：先不把问题研究得那么深，那么细，浅尝辄止，见好就收。
按广度分而治之：先不研究整个问题，而是研究问题的一部分，分割问题，各个击破。
例如：
接口和实现分离，就是“按问题深度分而治之”的一个例子。在架构设计之时，我们往往无需 深入到一个子系统的实现细节中去，而是分而治之，先确定该子系统的接口。接口的设计在整个架构设计中占有重要地位，它定义了一个子系统为其他子系统所提供服务的契约。软件架构通过明确每个子系统所要实现的接口及所要调用的接口，为我们展现了一个软件系统如何分割为多个相互协作的子系统。
“按问题广度分而治之”的例子也很常见，比如展现层、业务层和数据层的开发往往需要不同的技术,可以分派给不同的小组承担等,不一而足。
3、软件架构是团队开发的基础
因为软件变得越来越复杂了，所以单兵作战不再是普遍的软件开发方式，取而代之的是团队开发，而团队开发又反过来使软件开发更加复杂。现在不仅仅有技术复杂性的问题，还有管理复杂性的问题。面对“技术复杂性”和“管理复杂性”这样的双重困难，以架构为中心的开发方法是有效的途径。
软件架构从大局着手，就技术方面的重大问题作出决策，构造一个具有一定抽象层次的解决方案，而不是将所有细节统统展开，从而有效地控制了“技术复杂性”。可以看出，软件架构这一步没有“把问题研究那么深、那么细”，属于“按问题深度分而治之”。对此，Ivar Jacobson给我们提供了非常形象的说法，“软件系统的架构涵盖了整个系统，尽管架构的有些部分可能只有'一寸深'”;
有了软件架构设计方案之后呢?因为“架构中包含了关于各元素应如何彼此相关的信息”，从而可以把不同模块分配给不同小组分头开发，而软件架构设 计方案在这些小组中间扮演“桥梁”和“合作契约”的作用。每个小组的工作覆盖了“整个问题的一部分”，各小组之间可以互相独立地进行并行工作，这种“分割 问题，各个击破”的策略，属于“按问题广度分而治之”。
这两方面是相辅相成的关系。具体而言，正因为软件架构是大规模开发的基础，所以架构中应包含软件系统的各元素如何彼此相关的设计决策;也正是因为软件架构中包含了软件系统如何组织等关键决策，才使得它能够成为大规模开发的基础。
这样一来，模块的技术细节被局部化到了小组内部，内部的细节不会成为小组间协作沟通的主要内容，理顺了沟通的层次。另外，对“人尽其才”也有好处，不同小组的成员需要精通的技术各不相同。例如，用户界面层的开发小组需要了解将使用的用户界面工具 包;数据管理层的并发小组需要熟悉相关的数据库、持久工具或者使用的文件系统;系统交互层的开发小组需要了解通讯和用到的中间件产品等。
由此可见，软件架构为开展系统化的团队开发奠定了基础，为解决“管理复杂性”提供了有力的支持。对此Barry Boehm曾经明确指出，“如果一个项目的系统架构(包括理论基础)尚未确定，就不应该进行此系统的全面开发。”
