热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

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

前言:"设计"就是从假「设」(Hypothesis)而推演出来的可实现的「计」画(AchievablePlan)。这个假设我们对未来的设想,也就是还不知道如何实现的空中楼阁。美国

前言:"设计"就是从假「设」(Hypothesis)而推演出来的可实现的「计」画(Achievable Plan)。这个假设我们对未来的设想,也就是还不知道如何实现的空中楼阁。美国大文豪 梭罗 (即<<湖滨散记>>作者)就说过,空中楼阁本来就应该在空中,只要有计划从地基将它支撑起来,它就不再是「空中楼阁」了。岛设计学院的校长约翰.梅达在他的一书中说道:最好的简化是在添加的同时懂得减少。由于减法(精简)设计是当今产业主流,减法设计需要深度软硬产品整合来支撑,而软硬产品整合又需要软硬产业垂直整合来支撑。

   

本书缘由:高焕堂于2013年在日本退休之前,基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计,退休闲暇将之写成中文,欢迎大家指教 A段與B段的區別是:A段获利思维,B段成本思维;A段算计敌人,B段设计自己;A段预见失败,B段势如破竹。

目录:請看目錄  

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

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

ee                                                                                 ee

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

 

[#2001孙子兵法:不战而屈人之兵。<屈人之兵>是目的;而<作战>是手段。同理,<框住>塞外、保护关内自由度则是目的;而<建长城>是手段。也同理,<框住>上层APP行为、保护下层变动是目的;而<设计架构>是手段。所以,不建长城而能框住塞外、保护关内自由度,是上策。

 

[#2002]在软件产业里,架构设计师是一种设计师,所以架构师对软硬两种元素,应该是<感觉(feeling)>重于<理解(understanding)>。许多架构师来自IT开发者,似乎很习惯左脑的理解,而不是右脑的感觉;这样很容易失去架构师与开发者的职责互补性,模糊了架构师的设计角色。

 

[#2003]虽然有些人并不同意我的观点,但我喜欢拿<万里长城>来比喻<应用框架>,应用(APP)就是塞外居民,万里长城的原意不是给塞外使用的,而是用来框住塞外的行为,来实现保护关内的。框住塞外才能保护关内。

 

[#2004]@让您成为杰出架构师#架构师思维练习# 洋人创造的<集装箱(container)>,就是典型的中间造型;华人对于中间造型的创意不感兴趣,只想做电视机、冰箱装入集装箱;或者经营长荣海运来运输集装箱。致力于中间造型创意(如集装箱概念和规格制定)的国度,掌握了世界经济主导权。更多新思维:http://t.cn/8Fo3HIo

 

[#2005]在mpd讲座里,学员提到Java的父类(super class)与子类(subclass)之间是<继承(Inheritance)关系。亦即,父类是从一群具象子类进行抽像(Abstraction)而来。其实不尽然,在1996年Java诞生时,就使用<扩充(extends)>来代替继承。例如,是合语法的,但锅子并没有继承桌子的特性。

 

[#2006]对此,我有一些不同的观点。若用“长城”比喻框架,“关外”的人是APP用户,框架设计者和APP开发者同在关内。框架是游戏规则,框架作者设计了这个游戏规则,联合开发者,来对抗(赚钱)用户。

 

[#2007]一个建筑物的栋梁、骨架是要限制房子(和住户)的弹性发展,以免伤害建筑物的整体安全。如果一味强调栋梁骨架去支撑房子或住户欲望无限发展,难免酿成巨大灾难。

 

[#2008] <<框架设计>> 也许大家太宠爱用户了,一切以用户利益为依归,导致一切软件设计都是要服务APP、提升用户体验。这个假设(Assumption)可能该深刻反思一下,否则会反过来要求框架或平台(如TV或广电系统的中间件)稳定不变,而放纵APP弹性发展,将是一场大灾难!!

 

[#2009]<想在一个应用与日俱新的行业里抽象出一个稳定的结构> ,框架设计的目的只是为了得到一个稳定架构吗?

 

[#2010]#架构师思维练习# 虽然有些人并不同意我的观点,但我喜欢将<买主>与<用户>区分开来。例如,2006年时我在西班牙工作时,设计赌场的游戏机软件框架,赌场老板是买主,而赌客才是用户。我秉持买主体验第一、用户体验第二。更多新思维:http://t.cn/8FGlU1n

 

[#2011]<<架构师思维练习>> 架构设计目标主要有二:1)创造通用性(共通性), 2)创造独特性(与众不同)。前者偏于成本思维,着眼于降低特殊应用的开发成本。后者偏于获利思维,着眼于提升产品的竞争力和获利性。

 

[#2012]架构设计有其目的性,并非通用性的单纯抽像而已。例如我2006年在西班牙的工作是设计赌场游戏机软件框架,其中<游戏机公司CEO是我的老板,赌场CEO是买主>决定了我的框架造形。反之,如果<赌场CEO是我的老板,游戏机公司是供货商>就会得出不同框架设计造形了。

 

[#2013]杰出的工业设计师Richard W. Pew说:设计是一个不断运用各种限制因素的过程,一直到产出一项独特的产品为止。我个人也极力主张:软件架构设计是一个不断<运用>各项需求限制因素的过程,而不是<迎合>需求因素的过程;也不是以产出通用性的稳定结构为目标。

 

[#2014]洋人喜欢创造看不见摸不着的中间造型(Form)来掌控全局。例如,在软件产业里,洋人创造"Class"中间造型,华人乐于撰写Class内部的<小>代码,以及撰写由Class所迭出来的<大>应用软件。华人做看得见摸得着的,洋人则默默地主导了全局。

 

[#2015]作文(含作诗)的英文是:composition。就是<组合>的意思,意味着,其关键在于<合>,而不在于<分> ,所以中间造型的创意就显得极为重要。物联网也是把物联<合>起来,那个国度致力于创造中间造型,就拥有话语权当员外,其它人就成为长工;例如台湾的云端服务器产业乐于当代工(世世代代当洋人的长工)。

 

[#2016]#架构师思维练习# 洋人创造的<集装箱(container)>,就是典型的中间造型;华人对于中间造型的创意不感兴趣,只想做电视机、冰箱装入集装箱;或者经营长荣海运来运输集装箱。致力于中间造型创意(如集装箱概念和规格制定)的国度,掌握了世界经济主导权。更多新思维:http://t.cn/8Fo3HIo

 

[#2017]洋人创造的,就是典型的互联网信息的中间造型;华人对于中间造型的创意不感兴趣,只想拿HTML5来做网页、画图;或者经营HTML5-based的网游服务。致力于中间造型创意(如HTML5)的国度,掌握了世界网络云端服务的主导权。

 

[#2018]洋人创造的,就是典型的互联网信息的中间造型;华人对于中间造型的创意不感兴趣。

 

[#2019]做物联网为啥只见做系统和传感,没有中间的呢,因为前者看的见摸得着,有人付钱,中间呢,看不见。其实现在系统也没多热,因为没有成熟的应用,要说热也就是RFID热,买芯片和硬件还是现实的。

 

[#2020]#架构师思维练习# 古代华人创造了众多的、共享的中间造型,例如四合院等。这些中间造型具有<内涵不同、造型简单、无限组合>的特色,由于简单规律,促进整体社会的创造力、形成强势文化。期待今天华人IT相关产业也能鼓励创造更多中间造型,来激发创意,掌握话语权。更多新思维:http://t.cn/8Fo3HIo

 

[#2021]由于物联网的大型而复杂结构是本质性(essential)的,所以只依赖人类的抽象(abstraction)动作,无法有效获得简化架构,难以有效驾驭,只能建构小小系统。面对这种本质性复杂系统,人们常需创造<中间>造形,去包装隐藏复杂,提升人们管理能力,得出简化架构。例如集装箱就是好例子。

 

[#2022]@让您成为杰出架构师#架构师思维练习# 借镜于海运(船运)行业,其物流之网是一个大型复杂结构;当人们创造出集装箱<中间>造形,把原来船运的一切服务体系全部摧毁了,从码头、船体、陆运到仓储都全部翻新。我想,偏执于传感器小终端的物联网产业思维,有必要反思一下,也该重视一下思维上的误区,才能建立永续商业模式。

 

[#2023]华人的创意缺板。纵观大会的议题,偏重于<小的>传感器和<大的>应用系统或云端。由于不关心看不见摸不着的<中间>造型的创造与设计,很可能白忙一场,投入大量资源,却是替洋人作嫁罢了。数千年前华人辉煌的创意,如唐诗七言绝句的<4句7字+韵律>的中间造型,激发高度文明;如今创意安在哉?

 

[#2024]@让您成为杰出架构师#架构师思维练习# 关于物联网。例如医院的物联网架构里,其终端有二:传感器端和IP端。常见的不良架构设计:将终端<直接>连结到云端;这如同直接将货品摆入轮船或仓库里一般,没有<集装箱>中间造型概念,人类无法驾驭大型的物联网体系。更多新思维:http://t.cn/8FGlU1n

 

[#2025]看不见摸不着的造型是虚的;看得见摸得着的传感器和系统是实的。致力于务虚而能实践者是员外,汲汲于务实者是长工。

 

[#2026]洋人擅长于创造中间层,只要中间层具备了<提升人类驾驭复杂>的能力,掌握中间层者就变成老大,逼迫掌握<大、小>两端者成为他的小弟。也由于中间层并非来自用户需求,而是由架构师所无中生有创造出的,大投资高风险的洋人兵家必争之地,非华人保守个性所乐意为之的。

 

[#2027]洋人擅长于创造中间层,只要中间层具备了<提升人类驾驭复杂>的能力,掌握中间层者就变成老大,逼迫掌握<大、小>两端者成为他的小弟。也由于中间层并非来自用户需求,而是由架构师所无中生有创造出的,大投资高风险的洋人兵家必争之地,...

 

[#2028]中间造型概念有两层作用:1)规范<小>元素组合规律;人们容易组合出<中>间模块。2)规范中间模块组合规律;人们容易组合出<大>系统。主要目的是:驾驭复杂的欲望-->中间造型概念-->创造组合规律-->中间模块架构设计-->架空小元素和大系统的直接联系-->掌控全局当老大。

 

[#2029]洋人重视游戏规则,善于设计游戏规则,偏于务虚;华人重视产品用户,善于运用成熟技术,偏于务实。

 

[#2030]集装箱的空,才有货物的实。软件设计与此同理,有抽象才有各种不同的变化。

 

[#2031]例如,玫瑰花就是一个中间造型,规范了花瓣、花蕊、花衬叶等有限<小>元素的组合规律。同时它无限重复也大大影响(和简化)了整体<大>树系统的组合规律。这项造物法则,提升了掌握自然界复杂多变的能力,唯有熟谙此道,才能在物联网产业里找到有利于自己的商业模式。

 

[#2032]简洁造形,内涵深意,直觉(重复)组合;有如美丽的枫叶林。简单里面蕴育丰富,透过简单包罗万象。

 

[#2033]@让您成为杰出架构师#先进架构设计思维# <软硬产品整合>需要优越的产品设计师;<软硬产业整合>需要杰出的产业设计师;两者背后还需要能提出创新商业模式的设计师。设计师扮演关键角色。更多新思维:http://t.cn/8Fo3HIo

 

[#2034]<软硬产品整合>的背后需要有<软硬产业(垂直)整合>来支撑,才能竟其功。海峡两岸的IT硬件业是全球最完整的,台湾主导供应链,大陆主导生线线,虽然互补,但却是PC时代的分工体系。如果两岸能实践软硬产业垂直整合,将是全球最具胜算的产业。

 

[#2035]智能电视软硬结合策略方程式为:{硬件+(驱动软件+平台软件+框架API)+(APP软件+内容)}+通信={(硬件+应用商城)+(AP应用开发者+内容)}+通信。软件中框架API是衔接产业各方的桥梁。

 

[#2036]CSDN软硬结合沙龙,我将要讲演的内容包括:1. 产品亲密感来自触觉,好摸、好玩、好抱;2. 透过减法设计来创造亲密感;3. 以深度软硬结合来实践减法设计;4. 产品整合是会赢的战术,而产业整合则是战略资源;5. 软硬产品整合的设计思维之例;6. 软硬产业整合的设计思维之例。

 

[#2037]@让您成为杰出架构师<<架构师思维练习>>树林。上帝为什么要先造树,然后造林呢? 树是一个单一造形(Form),含叶、枝、干、根等共同元素,也有元素之间的简单组合规律。然后依循将树这种造形依循简单规律,无限重复和组合就成为林。如果上帝是杰出的架构师,则凡间的架构师也师法自然,发挥上帝造物法则,创造非凡产品。

 

[#2038]软硬结合的常见迷思是:一味追求加法设计来提供更多功能,试图藉之来替产品增值。其实,软硬结合的有效途径反而是透过减法设计,以简单设计来隐藏复杂功能,提升产品的亲密感,激发人们的爱怜之心,也让人们获得从简单叫出复杂的主动感和满足感。更多新思维:http://t.cn/8Fo3HIo

 

[#2039]手段、目的和愿景总是有意无意被人混淆起来对待。于是面对客户需求的时候,要考虑这是客户的目的还是客户的手段。在听某些专家忽悠的时候,要留心他是在谈手段还是在谈愿景。有效地手段可以实施,最终达到明确的目标,目标的有机结合才是通向愿景之路。更多新思维:http://t.cn/8Fo3HIo

 

[#2040]<一棵树>相当于<一首唐诗>;<一座树林>相当于<一本诗集>。上帝创造树之形;中国先贤创造唐诗之形。近代的中国人创造什么之形呢?

 

[#2041]@让您成为杰出架构师#先进架构设计思维# <设计+IT>意谓着:把文化做成科技。意谓着:把科技做成文化。更多新思维:http://t.cn/8Fo3HIo

 

[#2042]<软硬结合+设计>意谓着,在IT相关产业里,欲迈向成功之路时,深度<软硬结合>是必要条件,而优越的<精致设计>则是充分条件。所以,我到艺术设计系去寻找充分条件。

 

[#2043]<软硬结合+设计>意谓着,硬件是战术;软件和设计都是战略。善于运用战略资源来极大化会赢的战术效益,是赢家之路。也就是,<软硬结合+设计>的目标是要创造出好摸、好玩、好抱的智能终端硬设备,提升触觉和亲密感。设计不能仅仅促进人、软件的特殊性,而是要创造硬件的优雅、简洁、楚楚动人。

 

[#2044]从商业模式到架构。商业模式是可获利策略(profitable strategy),包括合作伙伴、客户在内的生态链可获利策略。架构是可实现的计划(achievable plan),架构师基于商业模式寻找多条可实现计划,在选择最好的。其中值得留意的是:要尽量<找事实来否定>计划;如果都被否定了,就放弃该商业模式,另寻它图。

 

[#2045]更像东方不败,孤独求败。商业模式来自愿景(Vision),从一个愿景可以找到许多商业模式,透过现实的检验来去芜存菁,避免抱着不现实的模式而不自知。

 

[#2046]@让您成为杰出架构师#先进架构设计思维# 减法设计。<消费者付出更多钱,得到的东西却更少,这似乎违反了经济原则>。 <但是,尽管违反需求逻辑,"减单能卖钱(simplicity sells)" 却确实不假。> ~摘自"The Laws of Simplicity"一书。更多新思维:http://t.cn/8FbhmdD

 

[#2047]<找事实否定,不找事实支持> 才能看到<缺板>、反思<假设>、激发<假想>、酝酿<愿景>。

 

[#2048]从架构(Architecture)到框架(Framework)。架构是支持商业模式的可实现计划(achievable plan),是整个生态链的共荣互利,但是谁拥有该生态链里的最大话语权呢? 就看谁拥有较强势的软件框架了,强势软件框架才能确保最大获利,信不信由你!

 

[#2049]<加法与减法> 思维框架。先加法:反思假设(Assumption)-->开放发想(Hypothesis)-->激发愿景(Vision)。然后减法(基于事实(Based on facts)):寻找商业模式(并删除不获利愿景)-->规划架构(并删除不可实现商业模式)-->设计软件框架(并删除不能主控的架构)。更多新思维:http://t.cn/8FbhmdD

 

[#2050]@让您成为杰出架构师<<减法与加法>>。把复杂多变的内涵封装于一个简单的造形(form),这是减法。例如,面向对象的"类(Class)",内部只有两个元素:函数(function)和数据项(data item)。基于这减法后之造形,人们掌握能力增强了,不再畏惧了,就敢大胆去尝试各项组合,成为形形色色的应用软件(applications),这是加法。

 

[#2051]在软件架构设计上,许多团队采requirement-based,受限于需求而无法扩展,失去许多商业好机会;求证又受限于从需求导出的test-cases,反面检验力道不足;可说先天不良、后天失调!! 更多新思维:http://t.cn/8FbhmdD

 

[#2052]业务架构是实的;软件架构是虚的;两者的型(Form)要分离,两者只是<虚支撑实>的关系,各自的型要loosely-coupled才是上策。业务架构是业主的目的;却是架构师的手段,架构师的职责和目的是设计软件架构。更多新思维:http://t.cn/8FbhmdD

 

[#2053]#先进架构设计思维# 商业模式、架构与框架之关系。商业模式必需具有可获利性;架构必须具有可实现性;(软件)框架必须具有主控性(话语权)。如果一个Dream能兼具这三项特性,就能梦想成真了。更多新思维:http://t.cn/8FbhmdD

 

[#2054]任何设计(Design)者都会重视<发想>,它是愿景(Vision)和梦想(Dream)的源头;然而,发想的源头又是什么呢? 最简单易见的就是<假设>(Assumption)。人人心中都有无限多个假设,局限了自己的发想空间而不自知。<反思>是发掘假设的途径;反思是<悟>与<舍>,而不是<学>与<得>;可是大多数人执迷于<学习>。

 

[#2055]@我Hold不住了 : 老板对老婆说:吃饭!睡觉! 对情人说:吃个饭,睡个觉。对二奶说:吃饭吧,睡觉吧。 对美女说:吃吃饭,睡睡觉。 对小蜜说:吃饭饭,睡觉觉。 对员工说:吃什么饭!睡什么觉!统统加班。

 

[#2056]谈到<软硬产品整合和软硬产业结合>商业模式;其中重要话题是:产品<减法设计>与设计师角色的重要性。减法设计是当今产业竞争力的关键性源头,唯有此途才能做出用户想摸、想玩、想抱的亲密产品。此时,设计师位居关键性角色了。多新思维:http://t.cn/8FbhmdD

 

[#2057]#架构师思维练习# 我与设计系学生交流时,学生很容易接受<设计品>是假的,而脑海里那个完美想象但却无法实现的才是真的。但是,信息系学生似乎就不太容易接受上述观点,大多相信做得出来、可执行、可用的才是真的;这样可能会大大局限了自己的创意。更多新思维:http://t.cn/8FbhmdD

 

[#2058]设计系偏想象力,信息系偏逻辑,想象与逻辑的混搭则有可实现富有想象力突破性的产品,如IPhone。

 

[#2059]<<好文章推荐>> <怎样像乔布斯一样有创造力?> 乔布斯有句名言是,“创造无非就是把事物联系起来”。尽管我们认为发明家取得的突破性成果是凭空想象出来的,但乔布斯指出,即便是最不可思议的创意通常也不过是对已有事物进行的新组合。

 

[#2060]我就建议在IT生产(production)段的女生三件事:1)继续写代码;2)学习麦肯锡公司的产业分析思维;3)多学一种小语言(如日语、西语等)。如此,可以逐渐从产品生产段逐渐转移到产品规划段,文武双全才是正途。

 

[#2061]即使是电视产品,一位有效架构师也能摆脱过去电<视>的内容视觉观点;而透过减法设计,提升硬件与用户的亲密感,创造用户想摸、想抱、想玩的美好触觉。有了<视觉+触觉 = 极亲密感>的硬件创意,支撑高价高质高获利商业模式,卖向高端品牌之路。更多新思维:http://t.cn/8FbhmdD

 

[#2062]@让您成为杰出架构师“设计”就是从假「设」(Hypothesis)而推演出来的可实现的「计」画(Achievable Plan)。这个假设我们对未来的设想,也就是还不知道如何实现的空中楼阁。美国大文豪 梭罗 (即<<湖滨散记>>作者)就说过,空中楼阁本来就应该在空中,只要有计划从地基将它支撑起来,它就不再是「空中楼阁」了。

 

[#2063]罗得岛设计学院的校长约翰.梅达在他的一书中说道:最好的简化是在添加的同时懂得减少。由于减法(精简)设计是当今产业主流,减法设计需要深度软硬产品整合来支撑,而软硬产品整合又需要软硬产业垂直整合来支撑。

 

[#2064]一书http://t.cn/zOalqTk //@Jimmy_on_the_road:原来是有理论可依的,有时间拜读下这本书

 

[#2065]<<大胆假设,小心求证?>> 不需<大胆>或<冒险>,只是把心中的假设(Assumption)去除,自然发想出无限多的假想(Hypothesis)。只是大多数人懒得去分辨Assumption和Hypothesis的微妙差异。

 

[#2066] “设计”就是从假「设」(Hypothesis)而推演出来的可实现的「计」画(Achievable Plan)。这个假设我们对未来的设想,也就是还不知道如何实现的空中楼阁。美国大文豪 梭罗 (即<<湖滨散记>>作者)就说过,空中楼阁本来就应该在空中,只要有计划从地基将它支撑起来,它就不再是「空中楼阁」了。

 

[#2067]例如三星把手机厚度减少一半,其简法设计很多人喜爱,只是连小零件的生产线都要改,很花钱的...。

 

[#2068]对需求视而不见。我多年前在<<程序员>>杂志上写文章鼓吹应该对需求视而不见,却招来不少批评。因为IT产业氛围里太多<分析>而少了<设计>的缘故吧。设计师约翰.梅达在其"The Laws of Simplicity"书里写道:<全世界最优秀的设计师在看东西的时候都会瞇着眼睛。..... 看的东西少一点,你就可以看到更多。>

 

[#2069]<<减法与加法>>。把复杂多变的内涵封装于一个简单的造形(form),这是减法。例如,面向对象的"类(Class)",内部只有两个元素:函数(function)和数据项(data item)。基于这减法后之造形,人们掌握能力增强了,不再畏惧了,就敢大胆去尝试各项组合,成为形形色色的应用软件(applications),这是加法。

 

[#2070]软硬结合架构师的角色。架构师介于工程师与设计师之间:软硬工程师<-->架构师<-->设计师。架构师需要兼具两种思维:工程思维<-->架构思维<-->设计思维。世界顶级IDEO总裁Tim Brown说:<设计思维依赖于人的能力:直觉、辨识模式、体现感情意义、运用各种媒体而非文字或符号的表达自己的能力。>

 

[#2071]<<顶层设计是指甚么?>>关于顶层设计的涵义一直见仁见智,然而基于我曾经从事DoDAF架构设计实务经验来看,我认为在智慧城市领域的顶层设计,应该是指:Top-level Design 或 High-level Design。然而许多人误解为:Top-layer Design,或Top-tier Design。

 

[#2072]@让您成为杰出架构师#智慧终端行业型软件Framework设计思维练习# Framework又称为框架,典型的框架就是应用框架(Application Framework)。顾名思义,应用框架就是:用来"框住"应用程序的架构。应用框架主要不是用来服务App;而是用来框住App;这样才是正确认识应用框架。http://t.cn/8Fo3HIo

 

[#2073]过去,架构师的设计注重于表达(业务)领域知识的结构,其设计出来的架构,需要再进行细部设计,才能对映到代码结构。这项细部设计,由谁来做呢? 试想,如果架构师直接以代码造型来思考其设计,让架构师与开发者具有一致的心灵、共同的感觉,您觉得会有建设性吗?

 

[#2074]拿代码造形来赋予分析和设计的内涵,有助于迅速落实为代码,并能进行组合重构,能提升敏捷迭代的流畅性。于是,架构师必须采取多视角来看待 {基类 / 子类}的代码造形结构。一旦架构师能将分析&设计所得的内涵,赋予到简单的代码造形,就能衔接需求&代码,敏捷就流畅了。

 

[#2075]智慧终端的OS平台有Android、iOS和Win-8等,App框架的接口(Interface)用来"框住"特定平台的插件(Plug-in),只要符合接口的插件就能加以抽换,换了平台插件,等于让App跨平台了。

 

[#2076]像Android、iOS等都含有多层框架,一个框架可以迭在另一个框架之上,愈上层的框架含有愈丰富的行业领域知识(Domain Knowledge)。就行业视角而言,愈上层的框架,愈是行业专用性;而愈下层,则愈是各行业通用的。

 

[#2077]框架就像一张桌子,将整个系统架构分为三部分:桌脚、桌面(含卡榫,用来衔接桌脚)和桌上。从<桌上>而观之,桌面(与卡榫)和桌脚都属于框架的内涵。从桌脚而观之,桌面(与卡榫) 才算是框架,而桌脚则是框架的插件,随时都能抽换、汰旧换新的;以便维持整体系统的旺盛生命力。

 

[#2078]为什么,应用框架要去"框住"应用程序(App)呢? 兹做个比喻,一棵树的树干,表面上它是用来支撑树枝和树叶的;然而,却也限制树枝、树叶的成长范围,以免伤害树根(负荷过重)。因此,树干的存在是为了保护树根的健康成长。万里长城的存在是为了保护关内居民的安居乐业。

 

[#2079]Android是开源开放的平台和系统,就像一棵大树;当您想要了解它、爬它、养它、喂它、安慰它、疼它、在它树下乘凉抓萤火虫;您完全可以就树干(架构)、树根(底层驱动)、树梢(App)兼顾;而不是当瓢虫在外围看树叶(App)。这是许多Android初学者的陷阱,高老师给您一条轻松之路。

 

[#2080]从代码解析软件,和从结构理解软件;它们本来就是两个必备的学习途径。在Android开源开放平台上的正确学习途径则是<代码+架构>兼具。<从结构理解软件>需要以图形来表达软件里的类(class)和接口(interface),以及其间的关系(relationship),此时像UML class diagram就很有用处了。

 

[#2081]@让您成为杰出架构师#智慧家庭#<<阿里TV生态联盟与Android>> 即使,非Android-based OS能在TV/STB主件设备上有立足点,但是众多以TV/STB为中心的相关配件,还是Android的天下,使得其立足点难以扩展出一片天空。http://t.cn/8Fo3HIo

 

[#2082]UML用在系统建模是OK的,但是Android开发者和书籍作者都不用它;因为UML几乎都被用来表达业务逻辑、企业对象和用例分析,而不是给<码农>来表述其代码架构,这是UML成长的瓶颈,也是Android开发者的损失。我希望UML不仅能表达大象的知识,也能完美表述小虾米(码农)思路。

 

[#2083]将Android与iOS采相同的初学教育方式,很可能是错误的。因为iOS封闭,学员看不到树干,只好看树叶,各自想象树干长相。Android可以直接看树干,对树叶的来龙去脉轻易撩若指掌,何苦只知其然(树叶)不知所以然(树干)呢? 换个有效的新观点!!

 

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

 

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

 

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

 

[#2087]<<阿里TV生态联盟 与 Android>> 智慧家庭的OS层级,可说是Android-based OS天下了,而且家家大同小异。唯有从OTT(Over the top of OS)视角去看它们,才能看出以"移动互联网" 整合 "家庭物联网"的新架构,巧好包容了各家TV平台(OS)的小异;因而非Anddroid-based OS在智慧家庭里,空间将愈来愈狭窄。

 

[#2088]智慧家居厂商大多促销自己的total solution,让一个家庭含有多个信息孤岛。我认为藉由微博、微信等<移动互联网>来整合智能家居众多<物联网>信息孤岛,是一项可行之路。

 

[#2089]其中,Android是操作系统层(如同微软的Windows),我们还需要建立一个行业平台层(如同微软的Office);来与智能城市的其它区块(如医疗、公交车等)对接,也与移动互联网(如微信、微博等)对接。

 

[#2090]@让您成为杰出架构师#业务逻辑&插件# 插件通常分为三种:1. UI插件; 2. 业务逻辑插件;3. 平台插件。 三者视环境的变化而弹性组合,例如,东方航空公司的系统应用端涵盖三种平台,于是抽换平台插件,就能让业务逻辑跨平台,因此只需要设计一分业务逻辑即可。省了成本!! 更多思维: http://t.cn/8FGlU1n

 

[#2091]OFA的"Open"包括4个主要途径:1. 对客厅的主、配件厂商开放API;2. 对智能城市的其它业务区块(如交通)开放API;3. 对移动互联网开放API;4. 对非IT产业开放,例如结合设计产业(如高校设计系师生)及企业。

 

[#2092]自从去年来,行业别应用框架(AF)平台建置,已经愈来愈热门;其主要原因是移动应用跃居应用主流,但是Android、iOS和Win-8分为三个不同团队,团队又逐渐扩大,相同的业务逻辑却因平台不同的不同版本,成本负荷愈来愈重。因此三个团队依赖<同一个应用框架,弹性抽换插件> 是唯一解决之道。

 

[#2093]基于什么平台,可保持弹性或客户选择,因为这是手段&成本;一起合作来满足这个新兴市场,解决大企业重复投入的难题,比较重要,因为这是目的&收益。

 

[#2094]关于跨Android、iOS和Win-8平台的面向有很多,但是许多人都偏向于HTML5-based的跨平台。殊不知,PhoneGap不一定要与HTML5绑在一起,例如传统的Android App或iOS App也能搭配PhoneGap来做为业务逻辑插件和平台插件的管理者。

 

[#2095]大家都知道,HTML是UI画面的布局(Layout)而已,JS也只是UI事件的简单分派逻辑而已。现在的移动终端应用开发,最大的难题&需求是业务逻辑(Business Logic)的跨平台,尤其是业务逻辑必需以插件形是执行终端时,只依赖HTML5提升UI插件的跨平台,其意义和经济价值是不大的。

 

[#2096]HTML是UI画面的布局(Layout)而已,JS也只是UI事件的简单分派逻辑而已。HTML5-based团队大多将业务逻辑(Business Logic)放到后端的云平台上,但是,当业务逻辑必需执行于终端时,又该如何处理呢?

 

[#2097]"本地计算能力" 存在形式就是:业务逻辑插件。这种业务逻辑插件,也能给Native App使用才合理。

 

[#2098]无论是js + html5 或 Native App都应该复用相同的业务逻辑插件,以及平台插件;否则如何有效维护业务逻辑的版本更替呢?

 

[#2099]只要使用"框架的插件管理器" 管理好业务逻辑插件,包括:插件定义、插件创建、插件配对、插件Callback(含同步与异步)等等。然后,让 HTML5幕后的WebView事件能传递给管理器,同时也能让Android一般的View的事件也能传递给管理器,就行了。

 

[#2100]@让您成为杰出架构师#行业别框架&API# 基于行业别框架&API,独立出业务插件,并由框架管理之,基于这些共享插件,和一致性API,而发展的跨平台App,可称为<行业级别app>。 更多思维: http://t.cn/8FGlU1n

 

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

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

我們都很欣賞孔明的空城計和千古文章"隆中對",可是孔明沒有寫出他"如何思考"空城計,也沒有寫下他"如何構思"隆中對裡的三分天下大策略,只留下大策略,卻沒有留下"策略思考技術"。今天高老師以傳承"策略思考技術"為職志,盼望大家的支持&鼓勵。

ee                                                                                 ee

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

   


推荐阅读
  • H5技术实现经典游戏《贪吃蛇》
    本文将分享一个使用HTML5技术实现的经典小游戏——《贪吃蛇》。通过H5技术,我们将探讨如何构建这款游戏的两种主要玩法:积分闯关和无尽模式。 ... [详细]
  • 实践指南:使用Express、Create React App与MongoDB搭建React开发环境
    本文详细介绍了如何利用Express、Create React App和MongoDB构建一个高效的React应用开发环境,旨在为开发者提供一套完整的解决方案,包括环境搭建、数据模拟及前后端交互。 ... [详细]
  • 流处理中的计数挑战与解决方案
    本文探讨了在流处理中进行计数的各种技术和挑战,并基于作者在2016年圣何塞举行的Hadoop World大会上的演讲进行了深入分析。文章不仅介绍了传统批处理和Lambda架构的局限性,还详细探讨了流处理架构的优势及其在现代大数据应用中的重要作用。 ... [详细]
  • 本文探讨了如何高效地计算数组中和为2的幂的偶对数量,提供了从基础到优化的方法。 ... [详细]
  • 协程作为一种并发设计模式,能有效简化Android平台上的异步代码处理。自Kotlin 1.3版本引入协程以来,这一特性基于其他语言的成熟理念,为开发者提供了新的工具,以增强应用的响应性和效率。 ... [详细]
  • Asynchronous JavaScript and XML (AJAX) 的流行很大程度上得益于 Google 在其产品如 Google Suggest 和 Google Maps 中的应用。本文将深入探讨 AJAX 在 .NET 环境下的工作原理及其实现方法。 ... [详细]
  • 本文详细探讨了在Java TCP编程中,如何理解和测量并发连接数、请求数及并发用户数,并提供了实际应用中的测试方法和优化建议。 ... [详细]
  • 本文探讨了如何在PHP与MySQL环境中实现高效的分页查询,包括基本的分页实现、性能优化技巧以及高级的分页策略。 ... [详细]
  • 本文探讨了如何通过优化 DOM 操作来提升 JavaScript 的性能,包括使用 `createElement` 函数、动画元素、理解重绘事件及处理鼠标滚动事件等关键主题。 ... [详细]
  • 2023年,Android开发前景如何?25岁还能转行吗?
    近期,关于Android开发行业的讨论在多个平台上热度不减,许多人担忧其未来发展。本文将探讨当前Android开发市场的现状、薪资水平及职业选择建议。 ... [详细]
  • 本文介绍了SIP(Session Initiation Protocol,会话发起协议)的基本概念、功能、消息格式及其实现机制。SIP是一种在IP网络上用于建立、管理和终止多媒体通信会话的应用层协议。 ... [详细]
  • 我的读书清单(持续更新)201705311.《一千零一夜》2006(四五年级)2.《中华上下五千年》2008(初一)3.《鲁滨孙漂流记》2008(初二)4.《钢铁是怎样炼成的》20 ... [详细]
  • 2017年软件开发领域的七大变革
    随着技术的不断进步,2017年对软件开发人员而言将充满挑战与机遇。本文探讨了开发人员需要适应的七个关键变化,包括人工智能、聊天机器人、容器技术、应用程序版本控制、云测试环境、大众开发者崛起以及系统管理的云迁移。 ... [详细]
  • 深入探讨:Actor模型如何解决并发与分布式计算难题
    在现代软件开发中,高并发和分布式系统的设计面临着诸多挑战。本文基于Akka最新文档,详细探讨了Actor模型如何有效地解决这些挑战,并提供了对并发和分布式计算的新视角。 ... [详细]
  • 本文旨在探讨设计模式在Visual FoxPro (VFP) 中的应用可能性。虽然VFP作为一种支持面向对象编程(xbase语言)的工具,其OO特性相对简明,缺乏高级语言如Java、C++等提供的复杂特性,但设计模式作为一种通用的解决方案框架,是否能有效应用于VFP,值得深入研究。 ... [详细]
author-avatar
mk艾草_180
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有