系统架构通俗的说起来就是系统的结构组织方式.原则上说, 架构只有好坏之分,而不存在有无的问题.
软件的体系架构可以直接体现为代码的类结构, 也可以表现为文档性的编码规范和全局约定等. 如果软件架构中能够抽象出一些稳定的元素,
那我们就可能得到一些所谓的框架代码. 一般业务架构是很难重用的, 目前常见的框架代码所描述的多半是与业务无关的技术架构.
良好的系统架构应该体现出应用本身的结构要求. 所谓各个为自己, 架构为大家. 只要各个局部符合规格,
应该由架构负责在合适的时刻按照合适的方式把它们组装在一些. 一个良好的架构中, 应该很少出现结构性的if语句,
不需要应用代码自己通过动态判断来定义某个特殊的触发时刻. 架构是一种规范, 当然也就是一种局限. 架构的可退化性是非常重要的,
否则一旦出现抽象泄露, 需要超出原有架构设计做出编码补充的时候, 往往无法将代码自然的融入原有的框架结构, 则整个框架出现大面积的失效情况.
而有的时候更糟糕的情况是一些关键性的资源处在原有技术架构的私有控制之中, 我们为了克服架构限制不得不采用各种trick来hack原有框架,
造成错误的累加和传播, 而补丁的补丁是最难维护的.
架构问题并不是一成不变的. 在一些情形下无关紧要的问题在另一种情形下可能会成为灾难性的架构问题.
例如在多层B/S架构下, 如果现在要求为每一个表增加一个对应的历史表, 并对其进行查看和维护操作. 为了最大限度的重用代码,
这要求我们的多层结构中的每一层都能够参数化, 这样我们才能用同样的代码处理不同的数据表. 如果我们的money很足, 小弟够多,
有足够的人月砸上去, 那么我们完全可以把业务表和历史表分开处理, 但如果反之,我们就会遇到一个典型的架构问题.
架构师未必有自己的框架, 因为设计不等价于创造,
架构师只要知道如何把系统中的各种元素按照可行的方式组装在一起就可以了. 但是一个架构设计是非常依赖于我们所能采用的技术手段的,
当现有各种可用的技术元素都无法满足我们的需求的时候, 某些架构师可能会选择创造一种技术元素. 当然, 创造是艰难的,
它所要求的甚至是不同的技能. Sun的Green项目创造了java语言, 从而开启了一个伟大的时代,
这绝对不会是大多数架构设计师的选择(有趣的是,Green项目本身失败了). EJB现在还有多少人在真正使用,
想想当年多少架构师在吹嘘这些东西. 他们对于技术的把握真的就那么幼稚吗? 架构设计并不是凭空出现的, 当时可选的东西就是如此,
而spring和hibernate这些都不属于架构设计本身的内容.它们是一种创造.
架构师未必是团队的领导者. 确实,他的工作类似于编剧, 负责执行的一般是导演.
事实上,一个建筑设计师是极少直接领导一个工程队的.架构师也未必比高级程序员要高明, 他们负责的是不同的内容.
至于产品的"商标及商标的相关元素"和"技术市场架构"等也不属于架构师的工作范畴, 他不能去抢产品经理的饭碗. 当然,在国内的现实情况下,
很多所谓的架构师所做的最重要的工作可能是公关工作, 向客户秀出所谓的理念, 与实际开发是不搭嘎的.
理论上说, 架构师可以不是编程的强者, 也可以不决定一些具体数据结构的选择,
但他不能不了解各种技术抉择潜在的影响. 这就如同一个建筑设计师可以不精通工程力学,但是他不能愚蠢到藐视重力, 设计出倒三角式的大厦.
与建筑不同的是, 在软件中我们所面临的不是一种"凝固的艺术", 我们无法以完全静态的方式理解代码,而必须在头脑中把它们运行起来.
架构师应该写下一些实际的代码, 以检验各个接口的可配合性并获得对于代码结构的直接感觉. 实际上, 按照现在软件业的成熟度,
一般我们无法实现建筑中建筑设计师与土木工程师的分工, 很多时候软件架构师都需要直接面对实现的细节. 如果组内缺乏非常强悍的coder,
有编程能力的架构师亲自操刀实现关键性代码的时候也是很多的.
架构师必须有经验, 但他所依赖的不能只是经验. 只要算一算架构师的年纪,
就会知道以他们在这个世界上的存在时间, 并不足以使得他们经历各种技术细节. 架构设计更多的是依赖我们对于系统结构原理的理解,
而经验可以让我们规避那些原理失效的地方(例如系统级bug). 君子非异能也, 善假于物也.
很多时候,我们更应该从有经验的朋友或者技术支持那里搜集技术细节, 以确保它们能够满足我们在架构上的原理性需求. Know
Why而不仅仅是Know How是非常重要的. 一个农民发明家也许可以得到某个巧妙的机械设计, 但是没有系统的掌握工程力学,
他们是无法去开发精密的导弹控制系统的.当然, 软件开发还处在非常原始的阶段, 掌握一些设计原理和设计模式多半也不过是五十步笑百步而已,
经验的地位是无可替代的.
架构师不是预言家. 在多变的业务环境中, 架构师的目标不应该是预测到所有的变化可能,
并把它们表达到系统架构中. 这个世界上不乏一些耗资数十亿,设计三四年,但最终每个谈到它的人都要说一句的产品开发项目.
架构设计所能做到的最好的程度是自然的标注出系统的结构边界,成功的delay各种技术抉择.
架构师不是超人, 他所考虑的东西也许要远一些, 所需要平衡的利益也许要多一些,
但是单独一个人是无法对整个产品或者项目的成败负责的. 如果ThoughtWorks的Martin Follower来处理国内的某些项目,
我估计他会死得很难看.架构师也是人, 也会犯错误,甚至是很低级的错误, 而每个人都会有一些独特的想法. 经历的多了, 你就会回归到终极的认识,
一切都只是浮云, 只有money才是硬道理.
分享到:
相关推荐
高并发架构设计的核心在于如何处理大量的并发请求,确保系统的稳定性和高效性。面对数据量大、访问突增、流量大等问题,通常需要采取一系列的技术手段来解决。 - **数据量大**:可以通过分片、分布式存储等方式来...
#### 一、软件架构设计的核心内容 **1.1 软件架构设计** - **研究内容**:主要包括软件架构描述、设计、风格、评价和形成方法。 - **解决实际问题**:设计、复用、质量和维护等关键问题。 - **复用性**:解决重复...
程序设计经验杂谈涉及到的不仅仅是语法和逻辑,更关乎到代码的可读性、可维护性以及性能优化。这里,我们将深入探讨程序设计的各个方面,包括但不限于设计模式、算法应用、调试技巧、版本控制、代码规范以及项目管理...
顺丰房托作为香港首个物流地产REITs,其上市及架构设计与资产管理情况,对行业研究具有重要的参考价值。本文将围绕顺丰房托上市的背景、特点以及其资产状况进行详细解读。 首先,顺丰房托是顺丰控股旗下组织设立的...
20210512-平安证券-地产行业杂谈系列之二:顺丰房托上市在即,REITs架构与资产如何?.pdf
权限设计是任何复杂系统的核心组成部分,特别是在多用户环境中,如何合理地分配和管理权限,确保数据安全并防止未授权访问,是系统架构师需要考虑的关键问题。 首先,我们要理解权限设计的基本概念。权限设计通常...
"程序设计经验杂谈"这个主题旨在分享程序员们在实践中积累的各种经验和技巧,帮助新手和有经验的开发者更好地理解和优化他们的编程实践。 首先,我们来探讨一下程序设计的基本原则。程序设计的核心是解决问题,这...
"设计模式杂谈"这个主题涵盖了多种设计模式的讨论,这是一篇关于如何理解和应用这些模式的文章。虽然没有提供具体的文章内容,但从标签“源码”和“工具”我们可以推测,本文可能涉及如何在实际编程中使用设计模式来...
地产杂谈系列之二:顺丰房托上市在即,REITs架构与资产如何?(2021)(11页).pdf
顺丰房托的架构设计至关重要,它通常包括发起人、管理人、托管人和投资者四个主要角色。发起人通常是物业的所有者,负责设立并注入资产;管理人则负责日常运营和资产管理,以提高资产价值;托管人则扮演监督者的角色...
"千万级规模高性能、高并发的网络架构经验分享.pdf"则可能深入到大规模系统的架构设计。在千万级用户规模下,除了数据库的分库分表策略,可能还会涉及CDN(Content Delivery Network)来加速静态资源的访问,减少网络...
MOS管电路设计杂谈 MOS管电路设计是一种非常重要的技术,在很多电子产品中都有广泛的应用。在这篇文章中,我们将深入探讨MOS管的种类、结构、导通特性、开关损失、驱动、应用电路等方面的知识点。 一、MOS管种类和...
而进入21世纪,设计师们更加注重设计理念的变革和创新,追求的不仅仅是形态和时尚,而是更深层次的设计思考。 2006年,国际工业设计协会理事会(ICSID)对设计给出了新的定义,强调设计是创造性的活动,旨在建立多...
【文档概述】 本文档《为己杂谈学习精要.doc》...总结起来,《为己杂谈学习精要.doc》提供了融合传统文化智慧和个人发展策略的综合指导,强调在个人成长与企业成功之间寻找平衡,以实现个人价值与社会贡献的和谐统一。
《程序设计经验杂谈》是针对C和C++编程的一份经典资料,以CHM(Microsoft Help Compiler)格式呈现,这种格式通常用于汇集大量的技术文档和教程。CHM文件是微软开发的帮助文件系统,它将多个HTML页面、图像和其他...
总的来说,Service Mesh为现代云原生环境提供了强大的服务治理能力,使得微服务架构更加健壮、灵活和易于管理。随着技术的不断发展和服务网格的成熟,我们可以预见它将在未来的分布式系统中扮演更重要的角色。