
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
架构图是程序员在学习软件架构开发技术的时候需要重点掌握的一个开发工具,下面我们就通过案例分析来了解一下,架构图更新都有哪些常用方法。
1、在系统和架构发生变化时如何更新架构图?
更新架构图有几种方式,我将会介绍其中的三种。一种,就是直接从代码生成架构图。这样可以保证架构图与代码是一致的。不过目前的工具还不能完全支持这种方式,在没有人工介入的情况下,工具还无法基于代码生成精确且有意义的架构图。
另一种,先用建模工具创建架构图,然后生成代码骨架(比如组件或包、API),随后开发人员可以在骨架上添加代码。每次架构图发生变更,需要从架构图端重新生成代码骨架。
还有一种,在每次加入新特性时手动更新架构图。为了保证代码与架构图的一致性,建议把更新架构图作为开发流程的一部分。不过我们不推荐这种方式,因为这样很容易造成架构图过时或出现不一致(比如开发人员总是忘记或者不想更新架构图)。
我的建议是混合使用现有的工具,结合手动和自动的方式来创建架构图。例如,尝试自动生成架构图,使用工具基于代码渲染出符合基本要求的架构图,不包含混乱无用的信息。架构图可以高度可变(比如可以适应频繁的开发变更,这类架构图一般具有较低层次的抽象),也可以是静态的。这类图表可以是上下文架构图、参考架构图、包图、类图、实体图,等等。不过有时候仅仅基于代码无法生成满足需求的架构图,所以在这种情况下,自动创建架构图不是理想的方式。这个时候需要手动建模作为补充,这类架构图包括时序图、状态图、并发图、部署图、运营图,等等。
2、现代架构(如微服务)对架构图有什么影响?
微服务或其他任何一个现代架构风格(如无服务器、事件驱动)只会影响到系统的结构、组件间的交互方式(比如组件间的关系)和原则。在我看来,我不认为架构风格会改变架构图原先的含义。不过,相比传统的系统(比如单体),我们所说的现代系统架构具有更高层次的复杂性,它们对架构描述和架构图确实会有一些影响,这些是我们需要注意的。我们需要考虑分布式组件(比如分布式微服务)、每种组件的类型、组件间的交互方式(比如边界、API、消息)、他们的生命周期以及从属关系。
综上所述,我们需要在架构图中体现系统的分解、开发、部署和运维。假设有一个包含了大量微服务的系统,它就会有很多的架构图,因为每个微服务都可能有自己的架构图。一致性(例如,改变一个服务的API会影响到其他服务,所有相关的架构图都需要做出修改)、碎片化(例如,一个架构图无法反映分布式服务的高可用性和性能)和横断面(例如,是谁在负责处理系统的监控或安全问题)问题会让人手忙脚乱。我们要面对的挑战是如何进行良好的团队协作,不仅仅是开发,也包括后续的维护。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。