为何说咱们须要软件架构图？

软件架构是一门学科，开始于 20 世纪 70 年代。面对不断增长的复杂性和开发复杂实时系统的压力，做为主流系统工程和软件开发的基本构造，软件架构应运而生。与任何其余久经考验的学科同样，软件架构在诞生之初也面临许多挑战！

为何说咱们须要软件架构图？软件架构图能帮咱们解决什么问题？

• 经过建立和维护架构图来提供准确且有价值的内容并不是易事。大多数状况下，咱们要么建立了太多的文档，要么太少，或者不相关，由于咱们没能准确地定位文档的受益人及其实际的需求。

• 咱们常犯的最大的一个错误是为系统中具备高波动性的部分建立详细的架构图。除非是自动生成的，不然手动维护它们对咱们来讲就是一种负担。

• 在实践中，大多数利益相关者对详细架构图不感兴趣，但会对一两个反映系统模块和边界的高级架构图感兴趣。除此以外，要深刻理解系统，代码才是事实的来源，但在大多数状况下，只有开发人员会对代码感兴趣。

• 架构图的主要目的应该是促进协做、加强沟通、提供愿景和指导。

• 为了建立具有必定质量的架构图，能够进行头脑风暴，并与团队就什么对他们来讲才是真正有用的东西上达成一致。不要尝试为源代码中不言自明的东西或为了迎合架构方法而建立架构图。

• 在墙上绘制一两个高级架构图并在会议（站会等）期间使用它们。做为一名架构师，你应该让它们可见，变得有价值，并做为项目文化的一部分。不要将它们隐藏起来或放在利益相关者不易接触到的地方。

    咱们尝试经过建立架构图（做为技术文档的一部分）来反映应用程序的内部状态，但大多数时候咱们都没能作对。由此产生的架构图可能很是全面，也可能很是模糊。有时，架构图根本就是不相关的。

    即便建立了相关的架构图，咱们也不多更新它们，做为持续开发过程的一部分。实际上，咱们只是时不时地更新文档，多是在某些 sprint 期间（当有时间更新文档时）或在发布特定版本以前。另外一方面，大多数开发人员（参加个人软件架构课程的同事或学生）不同意建立和维护技术文档，他们认为这些任务乏味、耗时，并且价值不如其余任务，他们甚至认为若是源代码写得足够好，文档不是必需的。虽然总会有例外，但我很肯定，在架构图方面，对于大多数项目来讲几乎都是同样的。

那么，咱们用架构图来作什么？

    通常而言，架构图和文档应该主要用于团队内部和团队之间的协做、沟通、愿景和指导。它们还应该包含项目的重要设计决策（在某个特定时刻采起）。

    架构图应该帮助每一个人看到大局，了解周围的环境。在我看来，这应该是建立和维护架构图背后的根本缘由。

例如，上下文架构图彻底知足了这种需求，并提供了关于系统边界的大量细节，从而能够看到全局。它有助于团队在不一样的利益相关者之间达成共识，并简化沟通。我参加了不少会议，当大屏幕上出现这样的上下文架构图时，省去了不少问题，并消除了关于高级系统架构的不肯定性。

    不过，咱们常常会尝试建立综合性的文档来反映系统的内部状态，它们能够是状态图、活动图、类图、实体图、并发图等形式。但这些很快就会过期，除非它们是基于源代码经过一些“神奇”的工具自动生成的。

    所以，建立有意义的小型架构图，并将它们加到技术文档中。对于大多数应用程序，可能须要两三种架构图。最多见的是上下文图、组件图、系统图或部署图。

项目实例在项目中，我主要使用两种类型的架构图

上下文图

应用程序或软件组件图

    

    请将这些图视为简单的示例，主要做为每种图应该提供哪些合理信息的指导。图中的信息应该与相应的抽象级别相关，还必须知足利益相关者的需求。

    在实践中，你可能倾向于向图中添加愈来愈多的细节，可是若是它们对利益相关者没有真正的用处，就会致使额外的噪音，增长维护成本，并且容易过期。这些图中的一些细节，例如协议和数据格式，可能对技术利益相关者来讲比较方便，由于它们是必要的实现细节。然而，正如以前所述，并不存在精确的方法来肯定图中包含多少数量的细节才算是恰当的，这彻底取决于不一样的项目。不过，架构师须要知道对利益相关者来讲真正有用的是什么，并建立和维护架构图来正确地反映这一点。

    除了这些架构图以外的任何额外细节，我能够在源代码中找到，或者经过某些工具自动生成（例如运行时视图、开发视图、系统或基础设施视图等）。

另外，请记住，团队应该是架构图的主要受益者。若是它们没有表现出任何兴趣，那么你应该中止建立它们，由于这多是在浪费时间。咱们不该该只是“为了拥有它们”，或者为了遵循综合性的架构方法，或者纯粹为了证实咱们做为架构师的角色而去建立架构图