赞
踩
架构师在团队里的角色很独特,他们不是Master却决定着何时以及如何交付软件;他们不是PO却确保软件能够满足业务目标;他们也编程但做的更多的是架构层面的Coding而不仅仅是写算法,更多的在于设计层面,包含了管理、技术和交付的职能,或者说整个产研线的工作都与这个角色有关,它不单单需要会编程,懂设计,会测试,通部署,这些只是架构师必备技能
软件的架构设计以人为本,软件所有利益相关方都有着对项目的预期,而架构师需要的便是与利益相关方多方协作共同定义软件项目的需求和目标,PO定义功能特性,而架构师需要挖掘功能特性后的质量属性,除此之外更要关注那些影响架构设计方向的约束和特性
架构师只有把软件系统进行分解,才能制定出满足质量属性和其他系统性需求的策略,而这其中你要做的便是定义模块、分配模块到开发者;指定读写分离策略解决数据同步延迟,为系统的可靠性、可用性、伸缩性提供保障
从全局角度考虑整体系统,意味着架构师需要处理的不仅仅是技术问题,人员、过程、业务需求以及其他技术和非技术因素都将影响最后的软件系统,即便是一个小小的设计决策也可能产生深远的影响,架构师必须高瞻远瞩纵观全局而不能陷入局部细节的设计
然而很多时候是个挣扎的过程,在想要达到的目标和必须接受的现实之间寻找平衡,这意味着一个优秀的架构师必须善于寻找平衡做出取舍
所有的软件都有技术债务,架构师知道系统是如何分解的,知道各个模块是如何协作的,在此基础上再将业务需求和技术决策通观考虑才能管理好技术债务,技术债务是软件系统的副产品,出色的软件团队会有意的引入技术债务来实现更快的交付,后续在逐步进行偿还,从而持续的创造价值
因此识别技术债务管理技术债务便成为架构师多线程工作的其中一个线程
架构师是整个团队的导师和顾问,设计炫酷却无人理解的架构毫无意义,作为团队的架构专家,向团队分享知识,帮助团队提升架构思维同样是架构师多线程工作中的其中一个线程,因此组队设计、文档授业解惑,代码Review便成为架构师完成此项职能的“方法”
软件架构是从零开始组织软件的一系列重大设计决策的集合,集合的目的便是实现期望的质量属性和其他软件特性,设计得当的架构能够提升利益相关方需要的质量属性,抑制或消除利益相关方不需要的质量属性,同时还可以提升其他属性,例如好的架构势必能够提升开发效率,多快好省
软件应该有主体结构,这个结构定义的是软件系统的组织和协作方式,它体现在你编写的代码和运行的软件中,甚至体现在开发者之间的写作中;将两个元素以某种关系链接在一起就形成了结构,而元素是软件的基本组成部分,关系则描述了元素如何协作完成任务
基本结构的设计切忌空想
通常情况下可以使用三种类型的元素和关系来构建架构,这三种类型分别为模块、组件连接器和分配
类型 | 元素 | 关系 |
---|---|---|
Module | 类、包、层、存储过程、模块、配置文件、数据库表等 | 使用、允许使用、依赖等 |
Component&Connector | 对象、连接、线程、进程、层、过滤器等 | 调用、订阅、管道、发布、返回等 |
Allocation | 服务器、传感器、台式机、负载均衡器、团队、用户、Docker容器等 | 运行于、负责、开发、存储、支付等 |
- Module: 存在于设计阶段,编写代码的过程也是与模块进行交互的过程,软件没有运行,模块结构仍然存在于文件系统中
- 组件连接器: 在软件运行时出现,组件可以创建与其他组件的链接、产生新进程以及实例化新对象,与Module不同的是它在系统不运行是便不复存在,只能从其运行留下的日志或数据库条目中看到其身影
- Allocation:展示了模块与组件连接器之间以及这些元素与现实的物理元素之间的协同与响应关系,它也被称为映射,因为它显示了元素之间的相互映射关系,例如某个元素运行在客户端还是服务器、A团队负责构建系统的哪个部分等等
架构使软件成功的基础
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。