首页 > 代码库 > 架构之美随笔一------论架构

架构之美随笔一------论架构

  翻开这本书之前对架构的理解是很模糊的,之前总是听老师再说架构什么的自己其实一直都不理解何为架构。在书本的开头作者就明确的告诉我们架构是什么?架构是架构师洞见一个待开发系统的内在的结构、规律、原则和逻辑的过程,而不是一个已经完整显示出来的,可以画出图纸的结果。优秀的架构师可以将自己放在系统中去的,在清晰地理解了系统之后,简洁地描述出构建好的体统架构。当架构师拿出他所描述的“作品”的时候,事实上架构这一过程就已经结束了。

  好的系统架构展示了架构完整性。也就是说,它来自于一组设计规则,这组规则有助于减少复杂性,并可以用于指导详细设计和系统验证。设计规则可能包含特定的抽象,这些抽象总是以同样的方式使用,诸如虚拟设备等。这些规则可能表现为一种模式,如管道和过滤器。在最理想的情况下,存在一些可以用于验证的规则,如“在设备失效时,所有某一类的虚拟设备都可以用任何其他同类的虚拟设备代替”,或“所有竞争同一资源的进程必须具有相同的调度优先级”。

  当代的架构师可能会说,待构建的对象或系统必须具有以下特征:

  • 具备客户要求的功能。
  • 能够在要求的工期内安全地构建。
  • 性能足够好。
  • 可靠性。
  • 可用的,并且使用时不会造成伤害。
  • 安全的。
  • 成本是可以接受的。
  • 符合法规标准。
  • 将超越前人以及竞争者

  软件开发项目需要一些人在软件构建时扮演架构师的角色,就像构建或修复建筑时传统的建筑师的角色一样。但是,对于软件系统来说,从来就弄不清楚哪些决定属于架构师的职责范围,哪些决定要留给实现者。定义架构师在软件项目中做什么,比建筑时的类似定义更困难,原因有三个因素:缺少传统、产品无形性和系统复杂性。好的架构师通常来自更好的架构师的现场指导。原因之一可能是有一些关注点几乎在所有项目中都会出现。架构师在项目过程中需要考虑的其实有很多诸如:

  • 功能性(产品向它的用户提供哪些功能?)
  • 可变性(软件将来可能需要哪些改变?哪些改变不太可能发生,不需要特别容易进行这些改变?)
  • 性能(产品将达到怎样的性能?)
  • 容量(多少用户将并发使用该系统?该系统将为多少用户保存数据?)
  • 生态系统(在部署的生态环境中,该系统将与其他系统进行哪些交互?)
  • 模块化(如何将编写软件的任务分解为工作指派(模块),特别是这些模块可以独立地开发,并能够准确而容易地满足彼此的需要?)

  因而架构不易,需要我们在实际的实验和项目中不断的总结和理解,软件架构还是需要多看,多学习了解其它的系统是怎么做的,有哪些可用的组件,对各种方法有思考有借鉴,最终形成自己的想法才是干货。工作和学习当中,还是要多花时间进行思考和设计,不要太急于动手了。

 

架构之美随笔一------论架构