A段架构师_隽语集(IT+設計思考_2201)

前言:为什么敏捷开发(Agile)逐渐进入到Android世界呢? 因为Android已经跨越单机开发,迈入多机整合、多屏互动的领域了。尤其是当今兵家必争的智慧家庭,以及新兴的智能城市领域。Android的项目日益扩大、复杂化。于是大型开发项目需要加入新潮的软件工程、新一代的架构设计思维和模式。

    为什么敏捷开发与Android是个很好的搭配呢? 理由之一是:Android有完善的测试框架,有利于建立TDD测试机制来推动迭代过程。理由之二是:Android平台架构是一个多层框架(Layered Framework)体系,框架内涵是代码,满足敏捷原则:”各项架构设计决策都必须迅速落实为代码”;有利于密切配合敏捷迭代过程。大型的Android开发项目和团队,应该如何采用敏捷过程、如何基于创新型的架构设计,让项目经理(PM)有效地组织开发、设计及测试人员,灵活敏捷地面对复杂多变的需求,维持高度的用户体验。

本书缘由:高焕堂于2013年在日本退休之前,基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计,退休闲暇将之写成中文,欢迎大家指教A段架构师大多具备丰富的技术经验,是寻觅战术的高手;一旦透过上述的途径而发现到连线断掉的未知部分,通常很容易瞬间洞悉未知部份的难度。因此能轻易评估出来是否该大胆投入战略资源去取得该事物,让战术顺畅起来。然后,依据其评估报告建议管理人员该如何调整战略资源,或提早准备改变战略。

目录:請看目錄

欢迎访问 ==>A段架构师技术论坛(ADT)

高焕堂:MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练 

ee                                                                                 ee

<<看上一集-------看下一集>>  

  

[#2201] 阿里的“智能TV生态联盟”。阿里将焦点放在OS上,并非是最好策略,因为阿里的强处在于移动互联网,属于OTT层而不是OS层,如果想要两层兼顾,将失去OS层合作和奥援。阿里可以直接将OTT平台接口,穿透Android-based OS而直接做进去TV硬件(主板里),既能得到OS层支持,也能得到硬件厂撑腰。

 

[#2202] 7月下旬,阿里发布阿里智能TV操作系统,并推出搭载该系统的盒子产品。阿里TV操作系统将打通电视、机顶盒、手机等终端,并接入电商、互联网支付等功能。OTT层、OS层和硬件层兼顾,这可能是阿里策略上的陷阱所在。OS就如同轿子,轿子自己做,自己坐,自己抬,这是许多优秀OS英才早逝的主因。

 

[#2203]阿里TV生态联盟的最佳策略应该是:发挥阿里的移动互联网优势,试图主导智能家庭的OTT层(优势空军),主张开放Android-based OS层(结盟陆军),趁机深入硬件层(强化海军),展开三军联合作战。阿里将所向无敌、势如破竹。

 

[#2204] <<第8届中国敏捷软件开发大会>> :软件系统的架构从来都不是一蹴而就的,它需要在不断的演化中改进设计,甚至做出重要的架构迁移。如何运用敏捷技术来保证这种演化,并将软件架构更好地与敏捷实践结合起来,以设计优良的架构?

 

[#2205]为什么敏捷开发(Agile)逐渐进入到Android世界呢? 因为Android已经跨越单机开发,迈入多机整合、多屏互动的领域了。尤其是当今兵家必争的智慧家庭,以及新兴的智能城市领域。Android的项目日益扩大、复杂化。于是大型开发项目需要加入新潮的软件工程、新一代的架构设计思维和模式。

 

[#2206]为什么敏捷开发与Android是个很好的搭配呢? 理由之一是:Android有完善的测试框架,有利于建立TDD测试机制来推动迭代过程。理由之二是:Android平台架构是一个多层框架(Layered Framework)体系,框架内涵是代码,满足敏捷原则:”各项架构设计决策都必须迅速落实为代码”;有利于密切配合敏捷迭代过程

 

[#2207]本讲座阐述一个大型的Android开发项目和团队,应该如何采用敏捷过程、如何基于创新型的架构设计,让项目经理(PM)有效地组织开发、设计及测试人员,灵活敏捷地面对复杂多变的需求,维持高度的用户体验。

 

[#2208] @让您成为杰出架构师#架构师思维练习# 从智能家庭视角看智能电视,可避免陷入"见树不见林"的误区。例如,从客厅看TV/STB可看到"客厅配件市场"的巨大商机;可看到TV/STB与微信平台对接的另一种商业意义和机会。更多思维:http://t.cn/8Fo3z3r

 

[#2209]过去,软件人员大多认为软件架构应该像房子的地基一样,要求它稳定、可靠和不变。因而要求底层平台的稳定不变,来支撑上层App的多变;其实,执着于这种架构设计视角是有缺陷的。架构设计的目的是要保护底层模块的"变动自由度",此视角才是理想的。

 

[#2210]一般而言,底层平台提供系统服务给上层AP;所以相对上,AP是Client,而平台是Server。保护底层模块的"变动自由度"以追求"没钱就改版、改版就有钱"商业机会。这项设计思维也适用于"终端产品/云平台"的移动互联网整体架构设计。

 

[#2211]过去,大多架构师的经济思维是:节省成本,所以强调软件模块的复用性(Reuse);这属于成本思维。其实,架构师可以改为获利思维,强调容纳改变(Change),跨别人的(芯片等)平台,跨Android版本更替。于是包容别人的多变,也创造了自己的复用性。

 

[#2212]在人人都在谈互联网、云计算、大数据之际,人人都在做加法设计之刻;软件架构师应该想想有效的减法设计。例如,Database的N:N复杂网状关系,软件就必须加以Normalization,减化为多个N:1的树状结构,才能支撑数据的未来成长。

 

[#2213]在移动互联网里,许多人基于简朴的架构来面对复杂的实务。例如,在手机终端呈现UI(如网页),然后将各种 "业务逻辑" 的运算都放在云层上;于是,追求UI(HTML)代码的跨平台(如Android等)是目标。然而,也有许多业务逻辑必须摆在终端执行的,则架构该如何重构呢?

 

[#2214]随着感知端的数量急速增加,云端大数据风潮逐渐兴起;端与云都在强力进行系统复杂化的"加法设计",那么软件架构师就必须负起"减法设计"的任务,提供简单的应用;才能让用户享受 "从简单中叫出复杂的满足感",这种满足感就称为"用户体验"。

 

[#2215] <程序员>到<架构师>的快捷方式:类(Class)造形 –> EIT造形 –> 设计模式 –> 框架(Framework) –> 端&云平台(Platform) --> 产品创新

 

[#2216] @让您成为杰出架构师#架构师思维练习# Android的碎片化是大家最担心的事项之一,然而也是Android欣欣向荣、百花齐放的生命力光辉的展现。因此,如何有效运用Android这项特质、水涨船高,抓住机会展现自己产品的独特性和应变能力;更重要的是,确实掌握自己产品主动改版的话语权。更多思维:http://t.cn/8Fo3z3r

 

[#2217]有人认为 "智能TV/STB" 欠缺的简单的互动技术,以及丰富App。其实真正缺少的可能是"商业模式和策略"。例如,有人认为:智能电视机的焦点(和本质)是"电视机",有人认为其焦点在于"内容",有人认为其焦点在"智能"。这些观点或视角都没对没错;唯一错的可能是:坚持单一观点。这样商业模式就陈旧不堪了。

 

[#2218] EIT软件代码造形,就像集装相一般,影响最大的可能不是集装箱的使用者,而是集装箱的管理者,让管理者能从简单中掌握复杂的满足感。例如,我前天在SPI(软件过程&质量改进大会上讲演),大大给了敏捷、CMMI等软件管理者们的惊艳。

 

[#2219]过去,码农思考的焦点在于代码的类(Class),而设计师的思考焦点在于设计模式(Pattern)。在两者之间,高老师发现了一个EIT造形。让码农与架构师两者的思考焦点有了新的交集,能够汇合为一,有了一致的心灵、共同的感觉。对各方都好处连连。

 

[#2220]其实这个 EIT造形是在改变架构师的视角,反而不是针对码农;除非是码农想成为架构师;例如,集装箱的发明,影响最大的是运输业,而不是工厂;因此,虽然EIT是代码造形,影响最大的是架构师、PM和测试者;反而不是码农。

 

[#2221]随着Android的普及,Android的大型应用项目愈来愈多,各企业逐渐企盼建立自己的专业应用平台(Platform)和自己能掌控的API;并由自己的平台管理各种插件,透过迅速抽换插件来满足客户需求的改变、Android的改版,以及底层芯片的频繁更替。让自己的产品或系统能实践”没钱就改版、改版就有钱”。

 

[#2222]一首唐诗,含有两部分:1) 七言绝句之造形(Form); 2)李白的情境内涵(Content)。<对架构的应用关键还是业务>这句话里的"业务" 就是内涵。造形则规范了内涵的呈现结构。 //六_个_轮_子:对架构的应用关键还是业务,老师说的形我的理解是控制即流程中的节点

 

[#2223] @让您成为杰出架构师拿代码造形来赋予分析和设计的内涵,有助于迅速落实为代码,并能进行组合重构,能提升敏捷跌代的流畅性。架构师采取多视角来看待 {基类 / 子类}的代码造形结构。一旦架构师能将分析&设计所得的内涵,赋予到简单的代码造形,就能衔接需求&代码,敏捷跌代就流畅了。欢迎访问:http://t.cn/8Fo3z3r

 

[#2224] #EIT架构设计思考# 将 {基类 / 子类} 结构视为一种 "代码"造形。然后从不同视角,将分析与设计的内涵赋予到此结构上,则这象造形就能有形形色色的内涵了。这摆脱掉传统 {基类 / 子类} 结构只有一种内涵(抽象&继承)的苍白思维世界;更能灵活地配合敏捷的跌代、并顺畅重构与成长了。

 

[#2225]把原来继承关系的 {基类 / 子类} 结构形式抽象出来,成为通用的造形(Form)。然后,再赋予继承、组合、插件等不同的内涵;这种造形,就是我提出的 "EIT代码造形" 了。

 

[#2226]基于代码造形,而将分析和设计内容嵌入于代码造形中,成为造形的内涵;于是,架构师必须采取多视角来看待 {基类 / 子类}的代码造形结构。一旦架构师能将分析&设计所得的内容,赋予到简单的代码造形,成为造形的内涵,就能有效衔接需求&代码了。

 

[#2227]过去,架构师没有考虑到代码造形,不同的分析&设计模式,都对映到不同的代码;一旦需求&架构改变了,代码架构需要改变,自动化单元测试方案也需要改变,大幅增加敏捷跌代的成本。

 

[#2228]从底层驱动(Driver)设计,到上层HTML5/PhoneGap的插件设计等不同的设计内容,对映到相同的{基类 / 子类}基本代码结构(造形),这项基本结构就成为软件世界的 "原子"造形。则敏捷的重构与测试方案就完全改观了。

 

[#2229]华人的独尊抽象思维是有问题的,是创造力的关键因素之一。其实,在1980年代初期,类别(Class)已经让设计师与开发者迈向"一致心灵"的一大步;今天我们又想藉由EIT代码造形来更往前推进一步。

 

[#2230] @让您成为杰出架构师#华人抽象思维的视角# 30多年前,人们抽象出类(Class)来包容Function和Data,类既是程序员熟悉的代码造形,也是设计师熟悉的设计造形,两种人员获得一致的心灵、共同的感觉。30年后的今天,高老师设计了一个较高层的EIT代码造形,又推动软件产业迈向新的一步。欢迎访问:http://t.cn/8Fo3z3r

 

[#2231]华人的抽象思维是的视角的,专注于对用户领域知识进行抽象,得到抽象的领域知识(表达为抽象类),这是一项很大的迷思!!!!

 

[#2232]回复海纳百通: 我的 EIT造形思维,就想下一代新的尝试...http://t.cn/zHAyDVz //海纳百通:这个很早就有大师提过:华人擅长归纳,不擅长演绎

 

[#2233]回复智慧笨蛋: 不仅仅软件,华人创造力普遍非常低落,都值得探讨... //智慧笨蛋:我觉得真相是:华人真正懂面向对象不多,可以把oo实际实现到真正项目的人不多 //高焕堂:根据我的研究,华人的独尊抽象思维是有问题的,是创造力萎缩的关键因素之一。

 

[#2234]华人的抽象思维是专注于对用户领域知识进行抽象,得到抽象的领域知识(表达为抽象类),这是一项很大的迷思! 正确的做法是:抽象而得到的是能包容 "完整而具象的领域知识" 的集装箱,而不是 "抽象的领域知识" !!!!

 

[#2235]华人的抽象思维的视角,正确的做法是:抽象而得到的是能包容 "完整而具象的领域知识" 的集装箱,而不是 "抽象的领域知识" !! 君不见,洋人发明集装箱、计算机主板(装了许多IC)、软件类(Class)结构、数具XML等等;反观华人呢? 不是华人没创意,而是思维习惯问题。

 

[#2236]华人的抽象思维是的视角。例如,华人会使用集装箱、会弄出全球最大的集装相船运公司(台湾的长荣海运公司),但是华人就是不习惯于:从具象的万事万物之中抽象出集装箱,容纳具象的万事万物 !!!

 

[#2237]华人的抽象思维的视角。例如华人会从一堆软件Function中抽象出 "抽象的函数"、也会从一堆软件Data中抽象出 "共同的数据结构",但是华人就是不习惯于:从具象的一堆函数和一堆数据之中,抽象出 "类(Class)结构" 来包容具象或抽象的函数&数据。兹想想面向对象思维不过如此而已。

 

[#2238]架构师是否应该使用代码造形来思考设计呢? 不同的分析&设计模式,都对映到不同的代码;一旦需求&架构改变了,代码架构需要改变,自动化单元测试方案也需要改变,大幅增加敏捷跌代的成本。高老师极力主张以代码造形来思考架构设计,则程序员都能轻易成为架构师了,您相信吗?

 

[#2239]过去许多人的思维习惯是:从一堆软件函数(Function)中抽象出 "抽象的函数"、也会从一堆软件数据(Data)中抽象出 "共同的数据结构",但是常常不习惯于:从具象的一堆函数和一堆数据之中,抽象出 "类(Class)结构" 来包容具象或抽象的函数&数据。Why?

 

[#2240]码农只要思考几个主要议题,就能具有新潮的架构设计能力了。例如,有个Client模块需要调用Server模块时,通常需要先知道Server模块的接口(Interface)才能调用到它。然而,如果现在还无法得知Server模块的接口,但却现在就必须撰写Client模块的代码。设计师(或码农)该如何面对这项限制呢?

 

[#2241]回复用心阁: 但确实能创建一个小线程去执行Task里的run()。 //用心阁:这种方式无法重用线程吧 //高焕堂:码农如果写出Java代码: class Task extends Thread { // function run() { .... } } 有些设计师会认为这是错的; 但在代码层级,这个写法有错吗? 到底何种观点正确呢?

 

[#2242] @让您成为杰出架构师#敏捷开发&设计思考#如何让架构师与开发者双方都来关助于"软件的形的抽像",则形就成为架构师与开发者的共同心灵、一致感觉了。这对于项目开发的流畅性会有极大的影响;尤其是敏捷开发。欢迎访问:http://t.cn/8Fo3z3r

 

[#2243]我的讲题是:<如何紧密结合商业模式与 架构设计来支持产品创新>。商业模式是复杂的,架构师必须设计出简单,才能支撑复杂的产品创新活动。以<硬硬结合销售>商业模式下的<多机整合>创新产品为例,阐述架构师如何设计出简单造形、模式和架构,来支持复杂的产品创新。

 

[#2244]面对复杂,架构师必须设计出简单,让攸关人员皆能享受从简单中叫出复杂的满足感。本讲座阐述有效的架构师如何轻易实现这项目标。

 

[#2245]于是,架构师必须从复杂中设计出简单。然后,基于简单而<容>纳复杂多变(<易>)的内涵。亦即:容易。最后,让用户享受从简单中叫出复杂的满足感。我觉得我们太偏执于抽象思考,忽略了设计思考(Design Thinking)。设计思考正弭补传统独尊抽象思考的不足;让我们能兼具宏观和具象。

 

[#2246]由于科技只会继续变复杂,采取简单策略来突出自己的产品,是很有经济效益的。隐藏复杂功能对人而言就会变成一种享受,而不是讨厌的东西。会给人们掌握主动的力量,从简单中叫出复杂的满足感。

 

[#2247]技术应用与发展,与人类的思考是相关的。例如,如何思考一推复杂的鞋子呢? 记得,人类面对复杂事物时会害怕,就会想找到简单的掌控点。那么,如何取得简单的掌控点呢? 主要途径是:抽象。但抽像有不同视角,结果不同。例如:1)一堆鞋子的抽像,结果还是鞋子。 2) 一堆鞋子的抽象,结果是"集装箱"!!

 

[#2248]基于内涵(Content)的抽象,能从复杂得到简单;基于形(Form)的抽象,也能得到简单。传统上,软件分析师、架构设计师都专注于内涵的抽象,以内涵的架构来充当软件系统的架构。这样的特点是:稳定而难以应变。架构师较不留意替开发者设计出软件之形(集装箱),让开发者将复杂的技术细节装入形里。

 

[#2249]架构师与开发者基于相同的形(集装箱);然后,架构师(含系分员)将领域内涵装入形(集装箱)里;而开发者将技术细节(含通信协议等)装入形里。这样子,获利最大的是PM,因为人员的沟通有了基础概念,软件管理和测试都变得非常简单容易了。因为形(如集装箱之形,物理原子之形)只有一个。

 

[#2250]回复KorukH: 也可以看看java的Thread类,例如:class Task extends Thread{...} //KorukH:图片所示Tire类重写了父类Engine的抽象方法operation_1(),这不是典型的继承么?本来想表达的意思是Engine类里面有Tire的实例?

 

[#2251] #敏捷开发&设计思考# 敏捷开发,就客户或业主而言,代码是目的,而团队的协作&沟通,以及架构设计都是手段。然而,对于团队而言,代码和TDD(拿需求来测试代码)则是手段,借之来调整、促进团队有效协作&沟通,以及促进架构迅速重构,得出有效的架构设计;则是目的。欢迎访问:http://t.cn/8Fo3z3r

 

[#2252]自从1995年之后,在计算机语言上,基类/子类之关系,就逐渐从内涵转向形。例如,在Java里,基类/子类之间的keyword就是用extends了;其可包容组合与继承两种涵意。

 

[#2253]组合与继承都是领域的内涵,再抽像出共通之形,就看出EIT造形了。 //KorukH:通过组合来实现的话,可能更好? //高焕堂: EIT是一种造形,Inherit关系是一种内涵;extend关系是另一种内涵。就像唐诗七言绝句的造形,无论李白或杜甫的诗都能以"七言绝句"的形来呈现。

 

[#2254]大型系统或产品,参与的架构师团队人数也愈多,如何让架构设计活动敏捷起来,是个关键。以代码造形为出发点的架构设计思路,能让架构设计活动敏捷起来。当设计与开发是基于一致的形时,最能够支持Scrum的"设计一点、开发一点"的基本原则。因此,大系统也能顺利采用敏捷了。

 

[#2255]为什么我提出的EIT造形,能化解敏捷开发里,架构师与开发者之间的衔接问题呢? 答案是:因为EIT代码造形,既是代码,又是设计模式。它是架构设计师(建筑师)心中的"砖块";也是开发者(营建商)心中的砖块。前者是设计单元;后者是施工单元。两者同出而异名,是敏捷和谐的基础。玄之又玄、众妙之门。

 

[#2256]架构设计者、代码开发者、TDD测试者,是敏捷开发里的三个重要角色(Role)。小团队里,可以有一个人兼任三种角色。在大团队里,则分别有不同团队担任。如何维持开发项目的顺畅运行,架构设计的角色就非常重要了。

 

[#2257]兹举个例子,就刘备而言,当皇帝的愿景(Vision)是目的,而找到可行的大策略是手段。然而,对于诸葛亮而言,刘备的愿景则是手段,借之来引导找出先三分天下,而后统一天下的大策略;则是诸葛亮的目的。领悟其背后的思维和道理,就能深刻领悟敏捷开发,并让敏捷开发落地。

 

[#2258]#EIT架构设计思考# 虽然敏捷鼓励软件开发要迅速落实为代码(Code),这是合理的(外在)情境。但是,我们心中可以有多种视角(View)去看它。我建议的视角是:将代码看成架构的外貌。因此,架构师如何让 "架构" 搭配敏捷跌代的过程,而逐渐成长,就是焦点谜题了。http://t.cn/8Fo3z3r

 

[#2259] Android基于其开源开放,而主宰了多云融合、多机整合、多屏互动的系统平台(物的层面)。函盖了一动互联网、物联网、移动终端。敏捷则涉及开发团队(人的层面)的合作和讨论。而架构则确保人事物三方的和谐推进和目标的圆满达成。

 

[#2260]回复申导: 例如,小孩想吃鱼,对小孩而言,鱼是目的;而对母亲而言,应该将鱼变成为手段,重构出更优化的钓鱼模式则是目的;因而会钓到更多的鱼,将小孩的目的实现得更好。

 

[#2261]我的EIT软件代码造形的设计,是完全非专利,是社会公共财。能不能将非专利的创作,与专利创作两者进行有机结合呢? 两道菜,一道收钱,另一道不收钱,相辅相成,这样结合有可落地性吗?

 

[#2262] #EIT架构设计思考# 架构师是设计师,其职责是从复杂、不完整、不明确的问题处境中,找出简单的跌代起点。可是如何找出简单呢? 华人非常依赖"抽象"思维,而针对什么而抽象呢? 基于完整的客户具象的需求而抽象。然而,敏捷又从需求尚未完整时就起步,又何来的完整又具象的需求呢? 这是冲突点。

 

[#2263] #EIT架构设计思考# 如果敏捷团队有困难时,如果从团队管理视角去求解,而无效时;很可能是架构设计是问题所在,应该去调整架构设计师的视角。

 

[#2264]回复TriChaos: Java的Thread基类,它的子类(Subclass)角色是Task。还有Java的基类/子类之关系,其keyword是 "extends" 而不是 "inherit"。 //TriChaos:一般来说,组合关系不会表达为继承,第一个图中应该是菱形更合适。另外,组合和继承经常可以结合一起使用,如典型的bridge模式。

 

[#2265] #IT+Design Thinking# 现在主要的议题是:如何培养架构师的思维去设计这种组合架构,来配合敏捷跌代,提升敏捷的流畅性。更多新思维:http://t.cn/8Fo3z3r

 

[#2266] 1986年C++是传统;1996 年java语言的 子类(Sub-class) extends 基类(Super-class),一般称为非原本的 inheritance 类体系 架构师以组合思维,让架构以有机方式,从小而大组合而成大架构,这称为organic growth。 //606Qin:这和敏捷有关系?

 

[#2267]回复KorukH: <类似于Android里的setOnClickListener(),传入的接口实现就是轮胎。> 涵义上是的;但使用 {子类 / 基类} 的extends 关系,而不是 inherit关系而已。 //高焕堂:架构师以组合思维,让架构以有机方式,从小而大组合而成大架构,这称为organic growth。 //606Qin:这和敏捷有关系? 

[#2268]最佳<用户体验>只是赢家的美丽说词;因为<最佳用户体验>是乌托邦,一心一意追求最佳用户体验,很可能成为输家。整个产业的发展,几乎不会走在最佳<用户体验>的路子上。所以孔明的<隆中对>不会去促进<三国融合>。因为三国融合能带给百姓最佳利益,但却是不可实践之路。

[#2269]我个人一直呼吁:终端差异化是硬件创新和活力的出口。就像黄河的善变与活力,是不可藉由简单手段去应付或屏蔽的。<共通平台>是个<简单(而拙劣)手段>。电信和互连网产业,可以效法数千年前的大禹治水,很容易发展精致手段,以爱心去包容和支持硬件的创新,而不是像鲧一样,欲置黄河于死地。

[#2270]<软硬整合 + 设计>,一条美好的教育途径。今年我也去深圳大学工业设计系,与学生座谈时,提到:想一想,如果一个酒店大堂的LED水晶吊灯,内含一颗计算机芯片,学生如何将这IT新元素纳入设计考虑呢? 更新潮的技术:http://t.cn/8FbhmdD

[#2271]#IT架构设计思维#智能电视的整合途径是:1. <软硬整合>,让TV与IT产业汇流,藉由IT产业从底层创造差异化。2. <整合内容>,把具备差异化的内容服务整合到平台软件里,不留在App层,提高整机售价。

[#2272]#IT架构设计思维#在汽车业里,其解决之道非常简单:就是<把轮胎拔掉,留下接口>。在车载等软件相关产业上,也是如此,<从整个应用程序里,将反映终端设备差异化的软件,给予分离,只留下接口。

[#2273]#IT架构设计思维#两种终端设备的差异,就如同<沙滩>与<高山>的差异。软件在两种差异化的终端上跑,就如同汽车在沙滩及高山上跑。人们不会期待一辆完整汽车既能在沙滩上跑又能在高山上跑。但是,许多人却想从沙滩到高山铺设一条柏油路(即通用平台),让完整的应用软件能在两种不同设备上跑。

[#2274]有许多人心中有一项假设(Assumption):<终端类型的多样化也会加大开发者创新新业务的难度>。这很容易让人把该<假设>误认为<真理> 。综观汽车业,其车种多样化,商业规则也多样化,随之商业模式创新并无难度。同理,终端多样化,软件也多样化,随之商业创新也不增加难度。

[#2275]#IT架构设计思维#全世界最著名的企管顾问公司麦肯锡(McKinsey)也有个MECE原则,其中的一部份就是:对现实妥协(Fact-based)。

[#2276]#IT架构设计思维#孔明很可能找出多个目标,例如:1)统一天下;2)二分天下; 3) 三分天下;....。然后,逐一去找出其可行之路。发现前两项都找不到可行之路,就放弃该目标。接着,发现"3) 三分天下" 有可行之路,再加以仔细推敲,得出精致的"隆中对"。更新潮的技术:http://t.cn/8FGlU1n

[#2277]"求实求是"像红花,"求虚"像绿叶,红花配绿叶。中国古哲人思想:虚实相依。从虚看实、实依于虚,而非虚依于实。例如,万里长城的关口是虚(空),长城是实;古人从山海关看长城,今人则从长城看山海关。洋人喜欢从街道看建筑物;华人则习惯从建筑物看街道。 


欢迎访问 ==>A段架构师技术论坛(ADT)

高焕堂:MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练 

ee                                                                                 ee

<<看上一集-------看下一集>>

  

你可能感兴趣的:(android平台,架构师,架构设计,設計思考,高焕堂)