智能＆大数据时代，架构师思维的十个学习步骤&演练

最新推荐文章于 2024-09-17 14:01:21 发布

weixin_34378969

最新推荐文章于 2024-09-17 14:01:21 发布

阅读量282

点赞数 1

文章标签：大数据移动开发系统架构

本文链接：https://blog.csdn.net/weixin_34378969/article/details/85104037

版权

高老师的先进课程(请点击此图)…

EE EE

智能＆大数据时代，

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

By 高煥堂　2013/11/24

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

第一种抽象视角：架构师基于<变与不变分离>的视角，寻找<万变不离其宗>的宗，其宗(架构)的不变性带来简单性；让人们能透过掌握简单来驾驭复杂(多变)，落实了架构师的职责。
第二种抽象视角：架构师基于<形与内涵分离>的视角，由于不同内涵之间的<变与不变分离>已经由第一种视角所抽象了。这个视角可从内涵中抽像出共同之形，也可以(无中生有地)创造一种造形(Form)来容纳内涵(包括变与不变部分)。由于我们常常拿船运业的集装箱(Container)来比喻<造形>；而拿形形***的货品来比喻其(集装箱)内涵(Content)。所以上述的第二种视角，又称为<集装箱式>抽象视角。

实战演练==>架构师“集装箱式”抽象视角

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

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

架构像房子的地基(第1种比喻)：由于地基要稳定，上层房子才不会倒塌；因此这项比喻让架构师认为架构要稳定，上层的业务应用才会稳定可靠。这种比喻偏于寻找不变，而不是追求创新。
架构像一棵树的树干(第2种比喻)：由于树根必须不断成长，拥有随环境而变动的自由度和活力；才能有效吸收更多水分和养分。这项比喻让架构师关心底层模块(Module)的变动自由度。具有活力的树根和树干，才能有效之撑上层业务应用的蓬勃发展。

实战演练==> 维护底层模块的变动自由度(第2种比喻)

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

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

架构师的职责就是要在一个系统架构体系中，替自己公司的软件系统(或模块)在架构体系中，取得制高点、取得控制力。
一个企业，如果在系统架构体系中，处于弱势地位的话；我们就很容易看出，它在商业竞争中，就难以取得话语权。
例如，曹操留给后代极高的政治智慧：挟天子以令诸侯。系统架构师也能运用这项智能，来取得系统架构体系中的控制力或主导权，来支撑该公司商业竞争的话语权或强龙地位。再如，Android架构师运用HAL驱动框架，来争取众多硬件厂商的支持，让Android取得系统控制力，支撑Google的商业强势地位。

实战演练==> 掌以握<系统控制点>支撑<商业话语权>

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

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

<用户体验是是让用户享受从简单中叫出复杂的满足感>这是苹果公司乔帮主(Jobs)的名言。因为智能化设备的功能内涵愈来愈复杂，如果缺乏有效的架构师来设计出简单，而让用户直接面对复杂，用户会感到害怕；就欠缺满足感。
在科学上也是如此。例如，牛顿从很复杂的力学中总结出了f=ma公式，大家就能从这简单公式而去掌握复杂的力学了。爱因斯坦也一样，他从复杂的规律中找出简单的E=mc^2质能互换公式，大家就能从这简单公式而去了解复杂的质能世界了。
为什么说它简单呢? 理由之一是：公式的元素不超过三个，比如说，牛顿力学公式里只有F、m和a三个元素；爱因斯坦的公式也一样，只有E、m和c三个元素。簡單的元素和公式(造形)卻蘊含極為複雜的內涵。
同样地，EIT造形的要素，也刚好就是三个。简单的元素和造形却蕴含极为复杂的内涵，简单而优雅的接口带给开发者和用户享受掌握复杂的满足感。

实战演练==> 从复杂设计出简单，从简单来掌握复杂

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

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

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

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

观点1：架构来自需求。其意味着，基于需求而设计。也就是传统的Rewquirement-based架构设计。
观点2：架构基于愿景(Vision)的引导，来自架构师的创意。其意味着，基于愿景而设计，需求用来检验架构。一旦创意设计<爱上>了需求的限制，架构(设计)自然心甘情愿地满足需求(限制)了。

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

实战演练==> 创意爱上限制，需求检验设计

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

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

由于数据量的庞大和异型化(Different Fomat)，如迷雾一般，欲取的市场竞争优势，如同想从大迷宫里找到出口，最有效的途径是：基于(假设性)想象多个最可能的出口，然后逆向推理，倒过来寻找出有效的路径(连线)。
苹果公司乔帮主(Jobs)的名言：“你不可能在眺望未来时把生活中的每个点连接起来，只有回顾时能才连点成线。”许多人并不知道，他所提的就是架构师的关键任务：找到愿景(Vision)与现实(Reality)间的连线。这是有效架构师必备修练。

实战演练==> 练习<假设性思维>和 Mapping from vision to reality

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

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

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

Play---没有主词和受词，动词<play>就显得意义不够清晰。
猫玩(play) 绣球---有了主词和受词，动词<play>就显得意义很清晰。
老师弹(play) 钢琴---有了主词和受词，动词<play>就显得意义很清晰。

----搭配了两个配角(主词和受词)，主角(动词)的涵意就显得更完整而清晰了。同理，架构师只要采用EIT造形，就能将接口表述得完整而清晰了。[歡迎光臨高煥堂的博客首頁：http://www.cnblogs.com/myEIT/ ]。

实战演练==> 清晰而明确表述接口(Interface)

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

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

EIT造形的是主角，架构师必须清晰而明确定义之。至于<E>和<T>都是配角，开发者可以做<假模块(Mock)>来实现<E>或<T>配角，进行对的模拟测试。就如同飞机架构师会设计<风洞>来模拟测试飞机的机翼一般。
目前市场上，有许多测试环境提供了Mock-based的整合测试工具，能迅速开发出 Mock<E>和Mock<T>来测试，非常有助于落实这个步骤的任务了。
例如，想测试Client与Server模块之间的真实接口。就能设计Mock<E>与 Client衔接；并且设计Mock<T>来与Server衔接；于是既使Cleint和Server两个模块都还没开发，也能迅速开发出 Mock<E>和Mock<T>来测试真实接口。

实战演练==> 尽快对接口进行检验和测试

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

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

容纳买主需求(或选择)的未来变化，或容纳新买主的新选择。兹拿汽车来做比喻，当买主买了车子之后，未来随时可以改变选择(沙滩、公路或高山)。例如，买主未来决定将车子要到沙滩上跑时，只要更换新轮胎就行了；这展现出架构师目前决策的未来性。
限制买主的选择范围。买主抉择的改变，表现于应用软件(App)上，架构师设计通用性接口来＜框住＞各种App，限制买主的抉择空间，才不会失控。这些通用性接口的有机整合体，就称为软件框架(用来框住App的架构)。

实战演练==> 演練_设计通用性接口

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

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

秦朝时代唯有书同文、车同轨的有效减法设计，才能开放加法，整并六国成唯一个大国。
唐朝的诗叫做七言绝句，如“姑苏城外寒山寺，夜半钟声到客船”，一首诗四个句子，每一个句子七个字，它的韵律有两个“平平仄仄平平仄，仄仄平平仄仄平”，这是唐诗的主要造形(Form)。
秦朝的＜书同文、车同轨＞，加上唐朝的＜诗同形＞，有效的减法设计，创造了大一统(加法)的辉煌国度。
君不见，在前面各步骤里，诸如：从复杂中设计出简单、以需求检验设计等都是基于有效的减法设计，一方面给设备供货商一个开放的加法设计空间；另一方面则让用户享受从简单(来自减法设计)中叫出复杂的满足感。
此外，在前面各步骤里，诸如：EIT造形、通用性接口和软件框架(框住某些东西)等，则是减法设计的实践技术；基于这些有效的减法设计途径，才能大幅开放加法设计；因而落实了：从简单中掌握复杂。[歡迎光臨高煥堂的博客首頁：http://www.cnblogs.com/myEIT/ ]。