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

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

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

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

目录：請看目錄

欢迎访问 ==>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:这和敏捷有关系？

 

 

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

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