软件架构需要做到什么程度

软件架构要做到什么程度，这是个仁者见仁,智者见智的问题。博远电子就这个问题结合自己的观点谈一谈,也算发泄一下^_^.最后还会根据自己的理解部分提出两点建议和想法。
　　OK,书归正传.解决软件架构到底要设计到什么程度?
　　* 首先，对软件架构的设计程度问题展开探讨，得出基本结论。从对“分而治之”的讨论入手，说明软件架构是团队开发的基础，从而，软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度;
　　* 之后，从问题入手，认识高来高去式架构设计的“症状”。主要分析实际工作中常见的架构设计不足的几种表现，找到要解决的问题;
　　* 然后，说明如何解决架构设计高来高去、指导不足的问题;
　　* 最后，结合案例，说明如何一步步地将架构设计落实到实处。
　　-------------------------------------------------------------------------------------
　　8.1 软件架构要设计到什么程度
　　软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度。
　　8.1.1 分而治之的两种方式
　　为什么要分而治之?简单说，就是问题太复杂了，超出了人们能够“一蹴而就”的范围。
　　面对一个复杂的问题，我们如何进行分而治之呢?策略有二：
　　一、先不把问题研究得那么深，那么细，浅尝辄止，见好就收。这种分而治之的方式称为“按问题深度分而治之”。
　　二、先不研究整个问题，而是研究问题的一部分，分割问题，各个击破。这种分而治之的方式称为“按问题广度分而治之”。
　　例如：
　　接口和实现分离，就是“按问题深度分而治之”的一个例子。在架构设计之时，我们往往无需深入到一个子系统的实现细节中去，而是分而治之，先确定该子系统的接口。接口的设计在整个架构设计中占有重要地位，它定义了一个子系统为其他子系统所提供服务的契约。软件架构通过明确每个子系统所要实现的接口及所要调用的接口，为我们展现了一个软件系统如何分割为多个相互协作的子系统。
　　“按问题广度分而治之”的例子也很常见，比如展现层、业务层和数据层的开发往往需要不同的技术,可以分派给不同的小组承担等,不一而足。
　　8.1.2 架构设计与详细设计
　　随着软件设计工作越来越复杂，将架构设计和详细设计分离已成为普遍的做法。Garlan就曾指出：“随着软件的规模和复杂度增加，算法和数据结构以外的设计问题就会出现：设计和制定系统整体结构将成为新的一类问题......这是软件架构层次的设计。”
　　将设计分为架构设计和详细设计，是对“按问题深度分而治之”思想的运用。
　　* 所谓架构设计，就是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕将系统分为哪些部分，各部分之间如何交互展开的;
　　* 而详细设计针对每个部分的内部进行设计。
　　可以这么说，软件架构设计应当解决的是全局性的、涉及不同“局部”之间交互的设计问题，而不同“局部”的设计由后续的详细设计负责。于是，在软件架构所提供的“合作契约”的指导之下，众多局部问题被很好地“按问题广度分而治之”了----对局部的设计完全可以并行进行。
　　总之，这种先确定软件架构，而后基于软件架构进行并行开发的做法，综合利用了两种分而治之的方法，利于控制复杂性，提高开发效率。这是一种值得推崇的开发方式，常被称为“以架构为中心的开发方法”。
　　8.1.3 软件架构是团队开发的基础
　　正如大家所看到的，因为软件变得越来越复杂了，所以单兵作战不再是普遍的软件开发方式，取而代之的是团队开发：而团队开发又反过来使软件开发更加复杂，因为现在不仅仅有技术复杂性的问题，还有管理复杂性的问题。
　　面对“技术复杂性”和“管理复杂性”这样的双重困难，以架构为中心的开发方法是有效的途径：
　　* 一方面，软件架构从大局着手，就技术方面的重大问题作出决策，构造一个具有一定抽象层次的解决方案，而不是将所有细节统统展开，从而有效地控制了“技术复杂性”。可以看出，软件架构这一步没有“把问题研究那么深、那么细”，属于“按问题深度分而治之”。对此，Ivar Jacobson给我们提供了非常形象的说法，“软件系统的架构涵盖了整个系统，尽管架构的有些部分可能只有'一寸深'”;
　　* 另一方面，有了软件架构设计方案之后呢?因为“架构中包含了关于各元素应如何彼此相关的信息”，从而可以把不同模块分配给不同小组分头开发，而软件架构设计方案在这些小组中间扮演“桥梁”和“合作契约”的作用。每个小组的工作覆盖了“整个问题的一部分”，各小组之间可以互相独立地进行并行工作，这种“分割问题，各个击破”的策略，属于“按问题广度分而治之”。
　　这两方面是相辅相成的关系。具体而言，正因为软件架构是大规模开发的基础，所以架构中应包含软件系统的各元素如何彼此相关的设计决策;也正是因为软件架构中包含了软件系统如何组织等关键决策，才使得它能够成为大规模开发的基础。
　　这样一来，模块的技术细节被局部化到了小组内部，内部的细节不会成为小组间协作沟通的主要内容，理顺了沟通的层次。另外，对“人尽其才”也有好处，不同小组的成员需要精通的技术各不相同。例如，用户界面层的开发小组需要了解将使用的用户界面工具包;数据管理层的并发小组需要熟悉相关的数据库、持久工具或者使用的文件系统;系统交互层的开发小组需要了解通讯和用到的中间件产品等。
　　由此可见，软件架构为开展系统化的团队开发奠定了基础，为解决“管理复杂性”提供了有力的支持。对此Barry Boehm曾经明确指出，“如果一个项目的系统架构(包括理论基础)尚未确定，就不应该进行此系统的全面开发。”
　　8.1.4 架构要进行到什么程度
　　既然软件架构是团队开发的基础，那么它就应该比较明确地规定后期分头开发所必须的公共性的设计约定，从而为分头开发提供足够的指导和限制。
　　另一方面，具体的架构设计程度还会因软件项目的不同而不同，例如航空航天领域中的软件系统对系统可靠性要求非常高，这种情况下对架构设计详细程度的要求也会比较高;同时，架构设计的程度也会受团队具体情况的影响，有类似项目经验的团队可以适当放宽标准，而分布团队或者涉及外包的情况则应更强调架构的明确性。
　　架构设计对软件的不同部分的设计程度并不是整齐划一的。例如，通信机制、持久化机制和消息机制等对应的公共模块，在架构设计时会设计得比较深入，因为它们较多地涉及软件的不同部分之间的交互;而具体的业务功能模块在架构设计中往往设计程度不深。
　　总之，关于软件架构到底要设计到什么程度，可以归纳为两句话：
　　* 由于项目的不同、开发团队情况的不同，软件架构的设计程度会有不同;
　　* 软件架构应当为开发人员提供足够的指导和限制。