1、什么是架构?
架构是一种能力,架构角色则是要求你在具体事物中行使某些行为,而架构师则是用来标识这些能力与行为的一个职务。对于不同的人来说,可能意味着什么是不一样的。
模块、连接、依赖和接口;
大局观;
改变成本很高的事情;
难以改变的事情;
更加兼顾全局的设计;
接口而非实现;
审美(比如艺术般的整洁代码);
概念模型;
满足非功能需求/质量属性;
每件事情都有架构;
沟通能力(抽象、语言、词汇);
计划;
一定程度的严格和可靠性;
蓝图;
系统、子系统、交互和接口;
管理;
战略决策的产出;
必要的约束;
结构(组件和交互);
技术方向;
战略和愿景;
结构单元;
实现目标的过程;
标准和准则;
整个系统;
工具和方法;
从需求到最终产品的道路;
指导原则;
技术领导力;
构成产品的元素之间的关系;
对环境约束和限制的意识;
基础;
抽象的观点;
把问题化整为零的过程;
产品的骨架、支柱;
架构作为名词来讲,与结构有关:将产品分解为一系列组件、模块和交互。
架构作为动词来讲,包括了理解需要构建什么、设定愿景以便于进行构建和作出恰当的设计决策。
所有这些都要以需求为基础,因为需求驱动架构。关键在于,架构是关于交流愿景以及引入技术领导力的,这样参与构建产品的每个人都能理解这个愿景,并为产品的成功做出积极贡献。
2、每个开发者都应该知道的五件事。
第一,软件架构不是大型预先设计。
软件架构历来被认为跟大型预先设计和瀑布式项目有关。团队要周全的考虑软件设计的所有细节,然后才开始编码。软件架构就是关于软件系统的高层次架构,以及你如何理解它,它是影响软件系统形态的重要决策,而非理解数据库每个字段应该有多长。
第二,每个软件团队都需要考虑软件架构。
简单的说,尚未发生的坏事往往都会发生,如果软件架构是关于结构和愿景的,不考虑这一点,就可能产出结构糟糕、内部不一致的软件系统。这样的软件系统难以理解和维护,很可能无法满足一些重要的非功能需求,比如性能,可伸缩性或安全性。明确的考虑软件架构,提供了一种引入技术领导的方式,增加成功交付的胜算,也对你有益。
第三,软件架构的角色关乎编码,指导和合作。
现代软件架构更倾向于成为一种有利于编码、指导和协同设计的方法,软件架构的角色不一定要由一个人来承担,而且要了解到的架构是否确实行得通,编码是非常好的方式。
第四,无需使用ml。
实际上,可以说UML并不是一个交流软件架构的好方法,如果要保留一些简单的指导方针,轻量级“框线”风格的草图是一个交流软件架构的有效方式。
第五,好的软件架构是支持敏捷开发的。
好的软件架构是支持敏捷的,可以帮助你拥抱并实现变化,而好的软件架构并非与生俱来,需要你努力争取。
免责声明:本文系网络转载或改编,未找到原创作者,版权归原作者所有。如涉及版权,请联系删