architecture是什么意思？用法、例句(软件架构（architecture）究竟是什么？)

大家好，如果您还对architecture是什么意思？用法、例句不太了解，没有关系，今天就由本站为大家分享architecture是什么意思？用法、例句的知识，包括软件架构（architecture）究竟是什么？的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！

1、不论从哪个角度分析软件系统，都不可能面面俱到。如果从架构学角度来分析，在一定程度上能够做到抓大放小，把握住重点，但是也不可避免地会错失某些重要的细节信息。

2、软件架构学关注的的一个重点是组织结构（structure）。不管是讨论组件（Component）、类（Class）、函数（Function）、模块（Module），还是层级（Layer）、服务（Service）以及微观与宏观的软件开发过程，软件的组织结构都是我们的主要关注点。但是真实世界中的许多软件项目并不完全按照我们的信念和愿望生长——它们就像超大型国企那样，层层嵌套，缠绕成一团乱麻[1]。有的时候真的很难相信，软件项目的组织结构性也能像物理建筑那样一目了然，层次清晰。

3、物理建筑，不管其地基是石头还是水泥，形状是高大还是宽阔，风格是气势恢宏还是小巧玲珑，其组织结构都一目了然。物理建筑的组织结构必须遵守“受重力”这一自然规律，同时还要符合建筑材料自身的物理特性。软件项目则没有定律可以遵循。另外，物理建筑是用砖头、水泥、木头、钢铁或者玻璃等标准材料建成的，而大型软件项目往往是由小的软件组件构成的，这些软件组件又是由更小的软件组件构成的，层层堆叠，无穷无尽。

4、所以，当讨论软件架构时，要特别注意软件项目是具有递归（recursive）和分形（fractal）特点的，最终都要由一行行的代码组成。脱离了一行行的代码，脱离了具体的细节设计，架构设计就无从谈起。大型物理建筑通常可以用比例模型分层描述细节信息，但是软件项目内部结构是很难用模型分层描述的。软件项目也具有内部结构，但是其结构无论从数量上还是多样性上来说，都远远超过了物理建筑的结构。

5、可以不夸张地说，软件开发比修建物理建筑需要更长、更专注的设计过程，软件架构师应该比建筑架构师更懂架构！

6、比例模型是深入人心的展示方式，但是不管某个PowerPoint图表中的彩色方块多么好看，多么简单易懂，它也无法完全代表一个软件的架构。它只能是该软件的架构的一个视图，而非全部。软件的架构并没有固定的展现形式，你所看到的每一个视图的背后都是架构师所做的层层抉择。一个视图包含了哪些部分，排除了哪些部分；用特殊形状和颜色强调了哪些部分，又有哪些部分被泛泛地一笔带过，甚至直接忽略，这些都是这个视图本身的特性。然而，每个视图都是对的，它们往往并没有优劣之分。

7、虽然软件无法很好地用比例模型展示，但它还是要在现实世界中运行的。在设计软件架构的过程中，我们必须理解和遵守现实的约束条件。CPU速度和网络带宽往往在很大程度上决定了系统的性能，而内存和存储空间的大小也会大幅影响代码的设计野心。

8、女士，这就是爱情的穷凶极恶之处，人的意愿是无穷的，而实际行动却处处受限。人的欲望是无止境的，行为却不得不遵从现实的限制。

9、人类的整个经济活动都是存在于现实世界中的，所以我们可以利用现实世界的一些准则来衡量和推理软件开发过程中那些不好量化和物化的因素。

10、软件架构是系统设计过程中的重要设计决定的集合，可以通过变更成本来衡量每个设计决定的重要程度。

11、需要付出的时间、金钱和人力成本是区分软件架构规模大小的衡量标准，也可以用来区分架构设计和细节设计。同时，我们还可以依据这个信息来判断某个特定架构设计是好还是坏：一个好的架构，不仅要在某一特定时刻满足软件用户、开发者和所有者的需求，更要在一段时间内持续满足他们的后续需求。

12、如果你觉得好架构的成本太高，那你可以试试选择差的架构加上返工重来的成本。

13、一个系统的常规变更不应该是成本高昂的，也不应该需要难以决策的大型设计调整，更不应该需要单独立项来推进。这些常规变更应该可以融入每日或者每周的日常系统维护中去完成。

14、我们怎么能够预知某个系统未来的变更需求，以便提前做准备呢？我们怎么能在没有水晶球与时光穿梭机的情况下，未卜先知，降低未来的变更成本呢？

15、所谓软件架构，就是你希望在项目一开始就能做对，但是却不一定能够做得对的决策的集合。

16、了解历史已经够难了，我们对现实的认知也不够可靠，预言未来就更难了。

17、这就是不同的软件开发理论的主要分歧点。

18、其中一条比较悲观阴暗的路线认为，只有权威和刚性才能带来强壮与稳定。如果某项变更成本高昂，那么就应该忽视它——变更背后的需求要么应该被抑制，要么就应该被丢到官僚主义的大机器中去绞碎。架构师的决定永远是完整的、彻底的，软件架构就是全体开发人员的敌托邦噩梦（Dystopia），永远是所有人沮丧的源泉。

19、另外一条路线则到处充斥着大量的投机性的通用设计。在这样的软件项目中到处都是硬编码的猜测性代码，到处是无穷无尽的参数，存在着成篇累牍的无效代码。维护这样的项目，肯定会遇到意外情况，而且无论预留多少资源都不够应付。

20、通过实际创造和探索，不停地提出问题和进行实验。优良的软件架构不是一成不变的，只有经过不断打磨和改进才能最终成就。

21、软件架构是一个猜想，只有通过实际实现和测量才能证实。

22、遵循这条路线，我们需要用心，全神贯注，不停观察和思考，在原则指导下不断实践。虽然这可能听起来很麻烦、很慢，但是只要坚持走下去一定能够成功。

好了，文章到这里就结束啦，如果本次分享的architecture是什么意思？用法、例句和软件架构（architecture）究竟是什么？问题对您有所帮助，还望关注下本站哦！