架构师思维的十个学习步骤

架构师的第一步: 学习两种抽象视角 (Abstraction View)

l 第一种抽象视角:架构师基于 < 变与不变分离 > 的视角,寻找 < 万变不离其宗 >的宗,其宗 ( 架构 ) 的不变性带来简单性;让人们能透过掌握简单来驾驭复杂 ( 多变 ),落实了架构师的职责。

l 第二种抽象视角:架构师基于 < 形与内涵分离 > 的视角,由于不同内涵之间的 <变与不变分离 > 已经由第一种视角所抽象了。这个视角可从内涵中抽像出共同之形,也可以 ( 无中生有地 ) 创造一种 造 形 ( Form) 来容纳内涵 ( 包括变与不变部分 ) 。 由于我们常常拿船运业的集装箱 (Container) 来比喻 < 造形 > ;而拿形形色色的货品来比喻其 ( 集装箱 ) 内涵 (Content) 。所以上述的第二种视角,又称为 < 集装箱式 > 抽象视角。

架构师的第二步: 关心下层的变动自由度 ( 没钱就改版,改版就有钱 )

   架构像什么 ? 有两种常见的比喻。

l 架构像房子的地基:由于地基要稳定,上层房子才不会倒塌;因此这项比喻让架构师认为架构要稳定,上层的业务应用材会稳定可靠。

l 架构像一棵树的树干:由于树根必须不断成长,拥有随环境而变动的自由度和活力;才能有效吸收更多水分和养分。这项比喻让架构师关心底层模块 (Module) 的变动自由度。具有活力的树根和树干,才能有效之撑上层业务应用的蓬勃发展。

架构师的第三步: < 系统架构控制力 > 支撑 < 商业竞争话语权 >

   软件系统就像一个国家的军队,商业模式就像一个国家的实力。

l 架构师的职责就是要在一个系统架构体系中,替自己公司的软件系统 ( 或模块 ) 在架构体系中,取得制高点、取得控制力。

l 一个企业,如果在系统架构体系中,处于弱势地位的话;我们就很容易看出,它在商业竞争中,就难以取得话语权。

l 例如,曹操留给后代极高的政治智慧:挟天子以令诸侯。系统架构师也能运用这项智能,来取得系统架构体系中的控制力或主导权,来支撑该公司商业竞争的话语权或强龙地位。再如, Android 架构师运用 HAL 驱动框架,来争取众多硬件厂商的支持,让 Android 取得系统控制力,支撑 Google 的商业强势地位。

架构师的第 四 步: < 用户体验 > 是让用户享受从简单中叫出复杂的满足感

   架构设计就是架构师从复杂中找出简单的设计过程。架构师从复杂中得出简单,其目的是要让开发者 (Developer) 能从简单中反过来掌握复杂;或者让用户 (User) 能从简单中叫出复杂,并获得其中的满足感。 茲說明如下:

l < 用户体验是是让用户享受从简单中叫出复杂的满足感 > 这是苹果公司乔帮主(Jobs) 的名言。因为智能化设备的功能内涵愈来愈复杂,如果缺乏有效的架构师来设计出简单,而让用户直接面对复杂,用户会感到害怕;就欠缺满足感。

l 在科学上也是如此。例如,牛顿从很复杂的力学中总结出了 f=ma 公式,大家就能从这简单公式而去掌握复杂的力学了。爱因斯坦也一样,他从复杂的规律中找出简单的 E=mc^2 质能互换公式,大家就能从这简单公式而去了解复杂的质能世界了。

l 为什么说它简单呢 ? 理由之一是:公式的元素不超过三个,比如说,牛顿力学公式里只有 F 、 m 和 a 三个元素;爱因斯坦的公式也一样,只有 E 、 m 和 c 三个元素。簡單的元素和公式(造形)卻蘊含極為複雜的內涵。

l 同样地, EIT 造形的要素,也刚好就是三个 。 简单的元素和造形却蕴含极为复杂的内涵,简单而优雅的接口 <I> 带给开发者和用户享受掌握复杂的满足感。

架构师的第 五 步: 创意爱上限制,即需求检验设计

无论是移动应用、物联网等都涉及愈来愈多的系统组合与创新。而软件开发愈来愈仰赖架构设计,所以架构师们亟需要去学习和领悟创意型的架构设计模式。這種新模式中,最传神的隐喻是, 谷歌公司副总 Marissa Mayer 所 提倡的 :

        “ 创意爱上限制 "(Creativity lovesConstraint) 。

她说: " 创新来自愿景与限制的互动 "(Innovation is born from the interactionbetween constraint and vision) 。限 制迫使架构师重新审视愿景 (Vision) ,从不同观点切入,寻找新事物;同时也让其聚精会神、厘清思路;非常具有创新性。这引导出架构设计的两个观点:

l 观点 1 :架构来自需求 。其意味着,基于需求而设计 。也就是传统的Rewquirement-based 架构设计。

l 观点 2 :架构 基于 愿景 (Vision) 的引导,来自架构师的创意 。 其意味着,基于愿景而设计,需求用来检验架构。一旦创意设计 < 爱上 > 了需求的限制,架构 ( 设计 )自然心甘情愿地满足需求 ( 限制 ) 了 。

既然是观点,本身就没有对错。架构师同时拥有多个观点,常常会带来更多创意的。

架构师的第六步: 练习假设性思维 , 然後 ”Mappingfrom vision to reality”

   愿景是对未来成功情境的想象,含有浓厚的假设性 ( 梦想 ) 。基于假设情境而设计,常常让许多人感到不安。由于,架构师的职责是设计一个有效架构,既能支撑业主的愿景 (Vision) ,又能满足现时环境 (Reality) 的需求限制。也就是,架构师要找出一条从愿景映射到现实的一条连 线 (Mapping from vision to reality) ,让其它团队成员能依循这条线而去实现该假设性愿境 ( 梦想 ) ,于是梦想成真了。 在迈向智能化的大数据时代,熟练假设性思维是很关键的,理由是:

l 由于数据量的庞大和异型化 (Different Fomat) ,如迷雾一般,欲取的市场竞争优势,如同想从大迷宫里找到出口,最有效的途径是:基于 ( 假设性 ) 想象多个最可能的出口,然后逆向推理,倒过来寻找出有效的路径 ( 连 线 ) 。

l 苹果公司乔帮主 (Jobs) 的名言: “ 你不可能在眺望未来时把生活中的每个点连接起来,只有回顾时能才连点成线。 ” 许多人并不知道,他所提的就是架构师的关键任务:找到愿景 (Vision) 与现实 (Reality) 间的连 线。这是有效架构师必备修练。

架构师的第 七 步: 清晰而明确表述接口 (Interface)

   基于前面第一步的两个视角而抽象,都产生了 < 分离 > 的动作。分 ( 离 ) 是手段,而 ( 组 ) 合是目的。分离动作则产生了接口,做为后续组合的依据。分得愈美妙就能组得愈快速。分与合两项动作,往往时间点不同,执行者也不同;属于跨时空、跨团队的分工。因而,主导分 ( 离 ) 的架构师,必须清晰地表述接口,并明确传达给担任( 组 ) 合的人员。那么,又如何清晰表述接口呢 ? 有效的途径是:擅用 < EIT 造形(Form) > 。兹说明如下:

EIT 造形是由 3 个类 (Class) 所构成的。分别以 <E> 、 <I> 和 <T> 来代表之。从架构师角度上, <I> 属于主角,而 <E> 和 <T> 是配角。搭配两个配角,才能将 <I> 表述的完整而清晰。就如同英语,搭配了主词 (Subject) 和受词 (Object) 两个配角,就能够将动词 (Verb) 表述得更完整而清晰。例如,

l Play --- 没有主词和受词,动词 <play> 就显得意义不够清晰。

l 猫 玩 (play) 绣球 --- 有了主词和受词,动词 <play> 就显得意义很清晰。

l 老师 弹 (play) 钢琴 --- 有了主词和受词,动词 <play> 就显得意义很清晰。

搭配了两个配角 ( 主词和受词 ) ,主角 ( 动词 ) 的涵意就显得更完整而清晰了。同理,架构师只要采用 EIT 造形,就能将接口表述得完整而清晰了。

架构师的第 八 步: 尽快对接口进行检验和测试

   基于 EIT 造形属于代码层级的造形,能迅速实现为软件代码,并进行电 脑的实际执行、检验和测试。软件的编程开发是一件费时的事情,等待各层面的细节设计 & 代码开发之后,才进行系统模块之间的检验和整合测试,往往会将检验和测试工作时辰延后,这将大幅升高系统整合的风险与提高项目开发的整体成本。尤其像 Android 平台的终端 < 软硬整合 > 产品开发,硬件需要迅速与软件进行整合设计 (Co-Design) ,才能有效降低软硬整合的风险,缩短开发时程,并提高产品可靠性。擅用 EIT 造形,将很容易落实这个步骤的任务,如下说明:

l EIT 造形的 <I> 是主角,架构师必须清晰而明确定义之。至于 <E> 和 <T> 都是配角,开发者可以做 < 假模块 (Mock)> 来实现 <E> 或 <T> 配角,进行对 <I> 的模拟测试。就如同飞机架构师会设计 < 风洞 > 来模拟测试飞机的机翼一般。

l 目前市场上,有许多测试环境提供了 Mock-based 的整合测试工具,能迅速开发出Mock<E> 和 Mock<T> 来测试 <I> ,非常有助于落实这个步骤的任务了。

l 例如,想测试 Client 与 Server 模块之间的真实接口 <I> 。就能设计 Mock<E> 与Client 衔接;并且设计 Mock<T> 来与 Server 衔接;于是既使 Cleint 和 Server 两个模块都还没开发,也能迅速开发出 Mock<E> 和 Mock<T> 来测试真实接口 <I> 。

架构师的第九步: 设计 < 通用性 > 接口,成为框架 (Framework) 核心要素

   架构师如何给自己创造重构的自由度,以及支持开发者重构的空间,是框架设计的关键议题。这种自由度,决定于架构师是否能仔细分辨出:关注 < 未来的决策 > 与关注 < 今天决策的未来性 > 的微妙差异了。愈是能关注 < 今天决策的未来性 > ,而不是关注 < 未来的决策 > ,就愈能创造未来重构的自由度。例如, EIT 造形和框架的主角都是接口 <I> ,愈是关注 < 目前决策的未来性 > 时,就愈会想去设计通用性(General)<E> 和 <I> 来包容未来 <T> 的多变化。而一群 <E&I> 的巧妙组合,就成为框架了。通用性接口有两层意义:

l 容纳买主需求 ( 或选择 ) 的未来变化,或容纳新买主的新选择。兹拿汽车来做比喻,当买主买了车子之后,未来随时可以改变选择 ( 沙滩、公路或高山 ) 。例如,买主未来决定将车子要到沙滩上跑时,只要更换新轮胎就行了;这展现出架构师目前决策的未来性。

l 限制买主的选择范围。买主抉择的改变,表现于应用软件 (App) 上,架构师设计通用性接口来<框住>各种 App ,限制买主的抉择空间,才不会失控。这些通用性接口的有机整合体,就称为软件框架 ( 用来框住 App 的架构 ) 。

架构师的第十步: 有效减法设计,才能开放加法 ( 设计 )

   幅员愈大的国度、 大数据应用 愈发达的国度,加法 ( 设计 ) 的幅度就愈大。加法设计幅度愈大,系统的复杂性和差异化就愈显着,此时标准化和统一化的呼声就愈高。无论是标准化或统一化,都意味着加法设计的大量推进,导致系统复杂而难以驾驭;因而要求架构师提出有效的减法设计方案,从复杂中设计出简单,让人们能 从 简单 中来掌控 复杂。 就架构师而言,基于有效减法的架构设计,才能开放人人去做加法设计。兹说明如下:

l 秦朝时代唯有书同文、车同轨的有效减法设计,才能开放加法,整并六国成唯一个大国。

l 唐朝的诗叫做七言绝句,如 “ 姑苏城外寒山寺,夜半钟声到客船 ” ,一首诗四个句子,每一个句子七个字,它的韵律有两个 “ 平平仄仄平平仄,仄仄平平仄仄平 ” ,这是唐诗的主要造形 (Form) 。

l 秦朝的<书同文、车同轨>,加上唐朝的<诗同形>,有效的减法设计,创造了大一统 ( 加法 ) 的辉煌国度。

l 君不见,在前面各步骤里,诸如:从复杂中设计出简单、以需求检验设计等都是基于有效的减法设计,一方面给设备供货商一个开放的加法设计空间;另一方面则让用户享受从简单 ( 来自减法设计 ) 中叫出复杂的满足感。

l 此外,在前面各步骤里,诸如: EIT 造形、通用性接口和软件框架 ( 框住某些东西) 等,则是减法设计的实践技术;基于这些有效的减法设计途径,才能大幅开放加法设计;因而落实了:从简单中掌握复杂。

--------------------- 本文来自 kongls08 的CSDN 博客 ,全文地址请点击:https://blog.csdn.net/kongls08/article/details/51316709?utm_source=copy

展开阅读全文

没有更多推荐了,返回首页