架构师的第一步： 学习两种抽象视角 (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
7万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
