高老師的架構設計_雋語集(DD_2101)

前言：使用"框架的插件管理器" 管理好業務邏輯插件，包括：插件定義、插件建立、插件配對、插件Callback(含同步與異步)等等。而後，讓 HTML5幕後的WebView事件能傳遞給管理器，同時也能讓Android通常的View的事件也能傳遞給管理器，就好了。html

有些業務邏輯須要在終端上執行。例如，有些遊戲的運算、影像處理邏輯、還有，如股票分析師在本身家庭裏的TV/STB上執行。在Android平臺上的同一份業務邏輯插件(Plug-in)設計，能夠提供給HTML5-based App使用；也能給傳統Native Android App使用。你知道如何達成這目標? 你知道這對大型移動終端應用開發有多大的好處嗎? 攸關客戶業務邏輯的分析、設計、維護和複用等等。前端

本書原因：高煥堂於2013年在日本退休以前，基於日本師徒制的要求而傳承給下一代架構師的架構思考技術(俗稱設計心法)。25年來他專精於A段(投資決策前)架構設計，退休閒暇將之寫成中文，歡迎你們指教。java

高煥堂：MISOO(大數據.大思考)聯盟.臺北中心和東京(日本)分社.總教練設計模式

ee ee瀏覽器

[#2101]今年來，我積極推進行業別應用框架(AF)平臺開發技術和實務交流，包括框架API規劃&設計，企業的業務邏輯插件(Plug-in)、平臺插件的開發、複用、改版、測試和管理等。也含敏捷開發&測試框架等。微信

[#2102]即便是身爲 "碼農" 的App開發者，也不該該繼續堅持從 App看軟件世界視角，由於這樣就沒法知彼知己，擴展視野了。更多新思惟：http://t.cn/8Fo3z3r網絡

[#2103]只要使用"框架的插件管理器" 管理好業務邏輯插件，包括：插件定義、插件建立、插件配對、插件Callback(含同步與異步)等等。而後，讓 HTML5幕後的WebView事件能傳遞給管理器，同時也能讓Android通常的View的事件也能傳遞給管理器，就好了

[#2104]有些業務邏輯須要在終端上執行。例如，有些遊戲的運算、影像處理邏輯、還有，如股票分析師在本身家庭裏的TV/STB上執行。 //@Angry_Jimmy:業務邏輯，是否是作成web service比較好？

[#2105]在Android平臺上的同一份業務邏輯插件(Plug-in)設計，能夠提供給HTML5-based App使用；也能給傳統Native Android App使用。你知道如何達成這目標? 你知道這對大型移動終端應用開發有多大的好處嗎? 攸關客戶業務邏輯的分析、設計、維護和複用等等。

[#2106]我百思不解，爲何系統架構都是<移動端/建康雲>兩層架構呢? 若是設計爲<終端/家庭雲/建康雲>三層架構又如何呢?

[#2107] 客廳配件市場是<藉助TV/STB的既有銷售渠道>幫配件廠商創造量產機會。在將TV/STB與微信平臺對接的，微信也將是<3億個移動用戶 + 3億個家庭>的中心平臺。更多思惟： http://t.cn/8FGlU1n

[#2108]許多架構師偏向於將全部 "業務邏輯" 擺在後臺Web Service裏。這可能帶來分工開發上的極大困境。例如，移動端與後臺的分工中，業務邏輯的變更部分該分給誰來作呢? Web Service接口屬於被動型API，將讓後臺開發者成爲前端開發者的小弟，還可能淪爲救火隊!!

[#2109]#行業應用API設計# 行業應用API設計，依賴豐富而紮實的行業領域知識，包括從客戶進行Use Case分析，從企業經理分析Business Rules，從產業資深專家分析領域概念及其信息結構等(如圖)。以後，對映到EIT代碼造形，將其<E&I>部分美妙組合成爲框架和API了。

[#2110]家庭的主人應該有全利決定其家庭建康檢測數據如何受權給醫療機構，而不是使用不一樣檢測儀器而分散於本身都不知道的"雲平臺"!! 惟有尊重家庭人員的權利和隱私，家庭健康產業才能健康成長與茁壯!!

[#2111]@讓您成爲傑出架構師#家庭物聯網 + 微信移動互聯網# 智慧家庭今年熱門議題是："家庭物聯網"與"微信移動互聯網"的對接。當我在推進這項對接的工做時，發現此項對接是雙方有利的完美結合，並且對微信將來發展的"虛實相依"、"軟硬結合"是很是有正面貢獻的。你們可預期這項完美的對接工程。更多思惟：http://t.cn/8Fo3HIo

[#2112]行業型應用框架，能夠擴大成爲應用平臺(即俗稱的中間件)，提供API來支持特定行業的App開發，並將客戶插件交給App開發者，外包出去。這些客戶插件包括因客戶不一樣而有差別的各類邏輯(含UI、業務性、平臺性)，都能外包出去，大幅下降公司的系統開發、管理和維護成本。

[#2113] 在<行業別應用框架開發>潮流下，各終端服務廠商，無不力求在Android、iOS、Win8等平臺之上，創建一個跨平臺的行業別應用框架，並設計行業領域API，有效實踐跨平臺，強力掌握行業別App。更多思惟：http://t.cn/8Fo3HIo

[#2114]行業型應用框架開發的主要效益，必須從"分工"的角度去衡量，不是僅僅從Client/Server 或<移動端/後臺雲端>的實體硬件或網絡架構去看。這也是爲何當今業界那麼重視以框架來提供API的緣由。掌握API的制定權，就擁有產業的話語權!

[#2115]我百思不解，爲何Android開發者都只會用代碼表示想法，而不重視圖形思考；那麼，請問接口(Interface)如IBinder, BnInterface<T>又如何從代碼裏看出來呢? 我從2007年陪着Android產業發展，可是顯而易見的是Android開發者心靈並無同步成長，頗使人憂心的。

[#2116] 敏捷的精神，偏向於UML是代碼的圖形表示。或是堅持1990年代的UML圖形表示呢? 我是偏於前者，代碼就是 {基類 / 子類}的結構，例如Android、iOS的代碼都是如此。這是視角問題，不是真理問題。取決於代碼的 {基類/子類}結構是否須要與UML一致的問題。http://t.cn/8Fo3z3r

[#2117]人人都在談"從開發到設計"，卻沒留意到"從(架構)設計到(代碼)開發"的反向觀點。例如，類(Class)觀念是來自於OOP，是代碼層級的結構改進，卻於是改變了系統分析從結構化(Structured)設計改變爲OOAD設計，也改變了測試單元和方法。所以，讓架構師迴歸到代碼造形也是很關鍵的。

[#2118]特定行業的軟件框架，易於跨OS(和硬件)平臺；反之，特定平臺的框架，則易於跨行業。因之，特定行業的軟件框架，能有效地跨Android、iOS和Win-8平臺，不依賴HTML5也能輕易跨平臺。

[#2119]#行業別框架&API# 基於行業別框架&API，獨立出業務插件，並由框架管理之，基於這些共享插件，和一致性API，而發展的跨平臺App，可稱爲<行業級別app>。

[#2120]在古典的架構思惟裏，」平臺 = (服務)引擎」，App直接使用平臺(引擎)的API，因爲引擎API是被動地被調用(左圖)，每每綁死引擎，業務規則代碼動彈不得，帶給企業惡夢。爲了維護底層<引擎>的變更自由度，就採用新思惟和新架構實踐(右圖)。

[#2121]掌握行業應用API，纔有軟件平臺上的話語權，才能具備商業策略的主導權。行業API來自軟件框架設計與特定行業的領域知識(Domain knowledge)的完美結合。惟有兼具<架構+代碼>的優質架構師，才能設計出優越框架和API，強力支撐商業策略。

[#2122]現在，數字家庭產業的客廳配件市場的全新商業模式裏，平臺軟件幾乎徹底是Android天下了。數字家庭OFA聯盟大力整合產學研之力量，推進<以TV/STB爲中心的數字家庭產業的客廳配件市場>新興產業策略，並有投資基金支撐。

[#2123]<<Why? Android學生的投資效益日益低落?>>Android產業的發展活力，一直以來都在於它的開源開放，紮根於軟硬結合，向多機整合、多屏互動，物聯網+移動互聯網發展出枝葉茂盛的大樹。產業路線與iOS, Win-8封閉平臺不一樣，因此教育途徑也應該不一樣，不然不適當的初學途徑，只會讓學生投資效益更低落!!

[#2124]隨着Android平臺的飛躍成長，各行各業的<行業別應用框架平臺>日益受到關注，<行業別應用框架平臺>意味着：專門的行業知識+軟件框架技術。尤爲是該行業的領頭羊企業，掌握了最完整、最早進的專業領域知識；一旦這些知是歸入軟件框架平臺，並掌握API，則能大幅提高它在整個行業的主導性。

[#2125]在<行業別應用框架開發>潮流下，各終端服務廠商，無不力求在Android、iOS、Win8等平臺之上，創建一個跨平臺的行業別應用框架，並設計行業領域API，有效實踐跨平臺，強力掌握行業別App。

[#2126]行業別應用框架(AF)平臺開發的關鍵部分：業務邏輯插件的接口(API)設計。只須要替客戶(如廣電CRM)一份API，以不一樣平臺的語言(如Android的Java，iOS的Objective-C)實現之。針對一個客戶，只須要一套需求分析、一套架構設計、一套測試方案，大幅節省開發費用和時程。這是大型行業移動應用項目的必然之路。

[#2127]家庭配件市場策略與商機# 客廳配件市場是<藉助TV/STB的既有銷售渠道>幫配件廠商創造量產機會。在將TV/STB與微信平臺對接的，微信也將是<3億個移動用戶 + 3億個家庭>的中心平臺。更多思惟： http://t.cn/8FGlU1n

[#2128]<從客廳看Android TV/STB可看到"客廳配件市場"巨大商機；也可看到TV/STB與微信平臺對接的龐大商業機會。> 這項超級的架構設計，將影響數億人的移動和居家生活，並帶來龐大商機。同時，騰訊微信將成爲全球最大的<移動互聯網+物聯網>的整合中心平臺。

[#2129]當敏捷(項目)團隊不暢時，若是從團隊管理視角去求解，而無效時；極可能是架構設計是問題所在，可嘗試從架構設計視角去求解。來自架構師的視角和習慣的蛻變；就能讓架構設計和項目開發都敏捷起來。信不信由你!!更多思惟： http://t.cn/8FGlU1n

[#2131]YES；可是，若是架構師和架構設計自己並不敏捷的話，可能沒法支撐總體項目的敏捷開發呢!! 更多思惟： http://t.cn/8FGlU1n

[#2132]<Android項目 + 敏捷開發>謎題的焦點：傳統架構設計視角偏於抽象思惟，致力於抽象出穩定、可靠、不變的共同性架構；作爲應用發展的基礎。然而，這項穩定架構沒法迅速獲得，不是「足夠好」而已，這違背敏捷的Simple Solution的要求，不易迅速推進敏捷迭代。

[#2133]組合的核心工做就是「接口」設計。於是，架構與敏捷完美結合之祕訣就是：每回敏捷的迭代，都讓其接口落實爲代碼，交給TDD來觸發反饋。

[#2134]其實，<Android項目+敏捷>是完美結合。Android完善的測試框架，有利於TDD機制來推進迭代。此外，Android是一個多層框架(Framework)體系，框架內涵是代碼，能密切配合TDD和迭代過程。那麼，<Android項目+敏捷>不暢的謎底又是什麼呢?

[#2135]當敏捷項目推進不暢時，大多將焦點放在"組織架構"的改進上，所以把偏重於項目經理(PM)和團隊領導(如Scrum Master)的視角和技能的改變上。可是，我則另尋他途，將焦點放在"架構設計"的改進上，所以專一於架構師的視角和技能的<蛻變>上。

[#2136]不管是基於Android或iOS等OS平臺，建構本身行業的軟件框架都是很是重要的，爲何呢? 理由只有一個：掌控API接口，制約別人的軟件模塊，並且保護本身的業務邏輯模塊。例如，圖中的中間件框架掌握了三項接口，安內攘外做用兼備矣。

[#2137]#行業應用API設計# 行業應用API設計，依賴豐富而紮實的行業領域知識，包括從客戶進行Use Case分析，從企業經理分析Business Rules，從產業資深專家分析領域概念及其信息結構等(如圖)。以後，對映到EIT代碼造形，將其<E&I>部分美妙組合成爲框架和API了。

[#2138]物聯網業者給家庭帶來許多的"加法"思惟，也帶來複雜思惟，例如買來三星的烤箱，如何與TCL電視機對接呢? 誰來對接呢? 物聯網廠商? TCL? 三星? 都不是!! 而是第三方App開發者來替用戶作"減法"設計。請問：這些App跑在那裏? 在網關??

[#2139]軟件框架的存在，猶如萬里長城的做用，API的功用也猶如山海關的做用。惟有主動型API才能像山海關同樣制約關外勢力(App)，才能保護關內居民(即底層模塊的變更自由度)。只要瞭解這個道理，你就能理解Android關於DB的架構設計了。

[#2140]傳統上，將框架視爲平臺，會產生嚴重誤區；由於許多人於是會求平臺穩定、可靠和不變；這是不對的。框架像集裝箱，可容納形形色色的業務邏輯模塊(即軟件的插件)，也備有優良的插件管理器(如圖)來管理插件。其實，人人只能追求穩定的API。

[#2141]行業框架能跨越移動終端與後臺雲端(如附圖)，能有效化解過去Client-Server架構的分工困境。古典分工模式讓Server團隊成爲忙於應付終端需求的"救火隊"；主要緣由是Server提供給Client的API屬於被動型API，被Client調用，沒有主導權所致。

[#2142]框架不只僅是軟件系統平臺而已，其API是該行業裏<強龍/地頭蛇>分工與合做的分界線。在更高級的架構設計裏，框架與行業領域的業務邏輯引擎是分離的，自家的邏輯引擎(如圖右下)模塊必須被框架完美而有效的保護，確保其變更的自由度。

[#2143]#家庭物聯網 + 微信移動互聯網# 智慧家庭今年熱門議題是："家庭物聯網"與"微信移動互聯網"的對接。當我在推進這項對接的工做時，發現此項對接是雙方有利的完美結合，並且對微信將來發展的"虛實相依"、"軟硬結合"是很是有正面貢獻的。你們可預期這項完美的對接工程。更多思惟：http://t.cn/8Fo3HIo

[#2144]掌握在"智能家庭軟硬結合平臺者手中"；例如，1980年代企業辦公室的爭霸戰，掌握Office平臺軟件的MS得天下，而不是思科、或宏碁。綜觀當今物聯網業者，都是以數據流動、網絡流量思惟爲主，可能比彩電廠商更沒機會，更是當局者迷；您以爲如呵呢?

[#2145]<<微信 + 智慧家居>> 對於微信而言，最好的切入點是智慧家居。智慧家居是物聯網9大試點領域最接近終端用戶的行業，智慧家居是最須要人與物互動的物聯網行業之一。

[#2146]有人問我：爲何須要去推進這項對接工做呢? 不是讓家庭的電視機或網關成爲微信平臺裏的一個客戶終端就好了嗎? 替電視機賦予一個2D碼便可了。這是單向溝通功能而已，並無考慮到家庭信息(如Shopping List)推送給家人的微信手機客戶端的雙向流暢聯繫。

[#2147]智慧家庭今年熱門議題是："家庭物聯網"與"微信移動互聯網"的對接。當我在推進這項對接的工做時，發現此項對接是雙方有利的完美結合，並且對微信將來發展的"虛實相依"、"軟硬結合"是很是有正面貢獻的。你們可預期這項完美的對接工程。更多思惟：http://t.cn/8Fo3HIo

[#2148]着眼於家人(family)的心靈聯繫的無限關懷：在外用微信手機終端，回家在客廳使用TV等的雙向溝通&家人心靈聯繫。這個視角可以讓人們從新看待智慧TV，例如傳統上認爲TV就是娛樂、就是一塊屏、就是音視頻播放而已；並無真正發揮"智慧"的時代意義。

[#2149]這項超級架構設計的主要功能並不在於傳統的"智能TV"或"智慧家居"的視角，例如從手機端操控家裏設備等等。而是着眼於家人(family)在外用微信手機終端，回家在客廳使用TV等的雙向溝通&家人之間心靈聯繫的無限關懷。

[#2150]這項超級架構設計的神奇效果是：物聯網和移動互聯網二者都是N:N大型網狀結構(Network)；在相對接以後，卻神奇地變成更大的樹狀結構。雖然變大了，確因樹狀結構(Hierarchy)而能穩定、有機成長。這種神奇效果來自高老師的EIT造形的架構設計新思惟。

[#2151]許多人將TV/STB定位成爲音視頻播放的娛樂終端，而後就沒繼續探究TV/STB的"非音視頻"角色。所以，比較不容易領會TV/STB成爲微信平臺的"不移動終端"的重要涵意了。

[#2152]客廳裏的TV/STB將扮演重要角色，可與微信對接，成爲微信的"不移動客戶端"。微信既有的3億移動客戶端，服務在外的家人；國內3億個家庭裏的"微信不移動客戶端"則服務在家中的人。創造極爲舒適的"Family"生活。

[#2153]微信平臺就像一個轎子，它的必備條件是有人擡轎。就微信而言，目前的商業應用都屬於依附轎子的人，而非擡轎人。一旦，微信能回首關照一下擡轎人，也讓擡轎人受惠，則微信平臺就會涌現無限多的新潮商業模式了。

[#2154]數字家庭# <<OFA不是制定TV業界標準>> 高老師正擔任<工信部數字家庭促進中心>的OFA聯盟主席，致力於<數字家庭物聯網與移動互聯網(如WeChat、Weibo)>對接API規範。可是許多人誤解這是制定官方標準的老路；實際上是基於數字家庭產業的客廳配件市場的全新商業模式而規劃。更多思惟：http://t.cn/8Fo3HIo

[#2155]Android是開源開放的平臺和系統，就像一棵大樹；當您想要了解它、爬它、養它、餵它、安慰它、疼它、在它樹下乘涼抓螢火蟲；您徹底能夠就樹幹(架構)、樹根(底層驅動)、樹梢(App)兼顧；而不是當瓢蟲在外圍看樹葉(App)。這是許多Android初學者的陷阱，高老師給您一條輕鬆之路。

[#2156]我除了盼望將Android最新潮的知識和軟件技術普及到鄉村各地，也盼望這些廣大地區的人才，能透過互聯網而幫全球各地的業主，開發傑出軟件，包括新潮的智慧電視、車機軟硬結合系統，工業物聯網與WeChat的信息推送業務等。深山幽谷裏的人才是被正確呵護、關懷、培養，就綻開無限芬芳。

[#2157]Android產業須要培養更多的軟硬結合、多機整合多屏互動、端&雲結合的人才。這種人才的培養須要總體觀，須要善用Android開放開源平臺的特質，惟有緊扣這項特質，從第一秒鐘得初學就培養全局觀纔是正確的教育。就如同，要培養好的網球人才，第一秒鐘就要進場，而不對着牆壁打球!!

[#2158]App代碼開發者要清晰業務流程(Logic Flow)；平臺(系統)代碼開發者要清晰內存進程(process)和線程(Thread)。二者兼顧，總體系統才能穩定發展。因爲Android是開源開放平臺，初學者必須一開始就很是重視線程，才能放眼全局，有正確的視角和視野。學習Android原本就不該該跟iOS、Win-8同樣的學法!!

[#2159]在學習Android時，從第一秒鐘就持着優雅的素養：對於每一行代碼，都必須能準確而正確地說出來，目前該行代碼正由那一個線程(Thread)所執行的。

[#2161]我在課程裏，全程使用世界標準的UML Class Diagram來繪製架構圖，以" 世界級"圖形思考來給初學者一個架構師的基本能力(繪製正確的系統架構圖)。兼具<代碼+架構>就能陪養正確的素養，正確的學習出發點，是成功的保證。例如，學習打網球時，先面向牆壁練球，球感素樣就永遠錯了。

[#2162]<<Why? Android學生的投資效益日益低落?>>Android產業的發展活力，一直以來都在於它的開源開放，紮根於軟硬結合，向多機整合、多屏互動，物聯網+移動互聯網發展出枝葉茂盛的大樹。產業路線與iOS, Win-8封閉平臺不一樣，因此教育途徑也應該不一樣，不然不適當的初學途徑，只會讓學生投資效益更低落!!

[#2163]當今Android初學者的<碼農式>(又謔稱"碼奴式")教育方式，讓人人的學習的"本益比"日益低落。由於忽略了Android式開源開放的平臺，其產業發展的活力來自軟硬結合，多機多屏互動，以及"物聯網+移動互聯網"系統開發。<碼奴式")初學教育阻礙產業發展!!

[#2164]<<爲一個新興市場而整合>> 將移動互聯網平臺(如Weibo,Skype)的軟件接口，作進去數以億計的Android TV裏，這不是去訂定業界標準，而是爲了一新興的巨大市場而整合。這就是：以Android TV爲中心的智能家庭的客廳配件市場，並提供Android新一代整合開發者創業的空間。

[#2165]#行業別應用框架開發# 在<行業別應用框架開發>潮流下，各終端服務廠商，無不力求在Android、iOS、Win8等平臺之上，創建一個跨平臺的行業別應用框架，並設計行業領域API，有效實踐跨平臺，強力掌握行業別App。更多思惟：http://t.cn/8Fo3HIo

[#2166]<<爲一個新興市場而整合>> 我主持的<工信部數字家庭促進中心OFA(Open Family Alliance)聯盟，不是要去訂定業界標準，而是爲了一新興的巨大市場而整合。跳脫古典的音視頻視角來看Android TV和智慧家庭，從具備高度產值的客廳配件市場出發，銜接移動互聯網，延伸到廣大的移動終端。

[#2167]<<爲一個新興市場而整合>> 若是你從主件的戰場下來，能夠轉移到配件市場，例如來自美國的柯博文老師將與IC Coffee合辦的<iPhone & iPAD 與接口設備連結之軟/硬/韌體應用整合開發>技術講座。此外，高煥堂老師也擔任北京數字家庭OFA聯盟主席，致力推進<以TV/STB爲中心的家庭客廳配件市場>。

[#2168]隨着Android平臺的飛躍成長，各行各業的<行業別應用框架平臺>日益受到關注，<行業別應用框架平臺>意味着：專門的行業知識+軟件框架技術。尤爲是該行業的領頭羊企業，掌握了最完整、最早進的專業領域知識；一旦這些知是歸入軟件框架平臺，並掌握API，則能大幅提高它在整個行業的主導性。

[#2169]使用世界標準的UML Class Diagram來繪製架構圖，不只內容以做品來期許，還以" 世界級"圖形思考來給初學者一個架構師的基本能力(繪製正確的系統架構圖)。

[#2171]善用UML類圖(Class Diagram)來表達代碼結構，是邁向有效架構設計的起點。我在課程裏，全程使用世界標準的UML Class Diagram來繪製架構圖，以" 世界級"圖形思考來給初學者一個架構師的基本能力(繪製正確的系統架構圖)。

[#2172]<<圖形思考>>。有效的架構師都具有出色的圖形思考能力。目前Android課程和教案，惟有高老師堅持特別重視培養開發者的圖形思考能力，其它大多數書籍都只有代碼，很是不利於開發者邁向架構師之路。

[#2173]從代碼解析軟件，和從結構理解軟件；它們原本就是兩個必備的學習途徑。從代碼解析軟件，仰賴流程邏輯；從結構理解軟件，仰賴架構接口。在傳統封閉平臺上(如 Windows, iOS)只能依循<從代碼解析軟件>學習途徑；在Android開源開放平臺上的正確學習途徑則是<代碼+架構>兼具。

[#2174]從代碼解析軟件，和從結構理解軟件；它們原本就是兩個必備的學習途徑。在Android開源開放平臺上的正確學習途徑則是<代碼+架構>兼具。<從結構理解軟件>須要以圖形來表達軟件裏的類(class)和接口(interface)，以及其間的關係(relationship)，此時像UML class diagram就頗有用處了。

[#2175]<<如何讓碼農也使用UML?>> UML用在系統建模是OK的，可是Android開發者和書籍做者都不用它；由於UML都被用來表達業務邏輯、企業對象和用例分析，而不是給<碼農>來表述其代碼架構，這是UML的瓶頸也是Android開發者的損失。我但願UML不只能表達大象的知識，也能完美表述小蝦米(碼農)思路。

[#2176]爲何，使用世界標準的UML Class Diagram來繪製架構圖呢? 其用意是：以" 世界級"圖形思考來給初學者一個架構師的基本能力(繪製正確的系統架構圖)。在Android開源開放平臺上的正確學習途徑則<代碼+架構>兼具。<從結構理解軟件>須要以UML來表達軟件裏的類(class)和接口(interface)。

[#2177]因爲雲計算、大數據中心的潮流，使得人們都是圍繞着數據去思考系統架構，卻忘了：一個雲一張網、一箇中心一張網，產生的信息孤島大問題。所以，咱們必須從"網"的角度去建構一個超級架構，來整合各雲計算、大數據中心所衍生的網，而間接、實質地整合了大數據自己。

[#2178]@讓您成爲傑出架構師#頂層設計# <<家庭物聯網 + 微信移動互聯網>> 這項架構設計的神奇效果是：物聯網和移動互聯網二者都是N:N大型網狀結構(Network)；在相對接以後，卻神奇地變成更大的樹狀結構。雖然變大了，確因樹狀結構(Hierarchy)而能穩定、有機成長。這種神奇效果來自高老師的EIT造形的架構設計新思惟。

[#2179]雙向聯繫的典型範例：TV裏有個家庭Shopping List，早上安排好家人預約購買的東西，並儲存於Shopping List上。下班時，家庭媽媽臨時逛了超市，決定將東西都買了。因而透過手機瀏覽器上網，訪問TV裏的網頁去更新Shopping List。TV當即透過微信平臺將更新信息推送到各家人的手機終端。

[#2180]家庭物聯網的專一焦點，逐漸從原來的House轉移到Home，現在更邁向Family。由於House因Home而存在；至於Home則因Family而存在。更況且，一個Home有多個house；一個Family可能分散於各Home。此時，TV/STB將扮演聯繫Family的"不移動終端"。

[#2181]TV/STB的主板大廠溝通，都很是期待早日與微信對接，將微信推送的接口安全機制，部分直接寫入主板裏。如此讓微信直接深刻TV/STB的硬件核心，實現與3億個不移動終端之間的虛實相依，將能有效弭補微信在移動終端一直沒法虛實相依，縮小商業模式空間的短板問題

[#2182]在這超級架構設計裏，"虛實相依原則"與"EIT設計造形"，一直扮演着設計的核心思惟。其中的虛實相依原則是：虛在上，實在下；務虛者必須主動接觸務實者，不然虛脫離了實，就像失根的蘭花，難以取得營養或水分(在商業上，就是難以找到創新的有效商業模式）。同時，務實者也會生存得很辛苦。

[#2183]一旦微信切入了TV/STB的主板(Motheboard)，就能依循EIT樹狀體系架構，而迅速、順勢網下層延伸，掌握了整個家庭物聯網衆多Sensor端。以此類推，一旦掌握了家庭，此模式就能進而複製到學校、醫院等來服務教師、醫生等。因而，微信-based的智慧城市就天然造成了。

[#2184]高老師提出這項<<智慧城市頂層設計的統一系統架構芻議>> ，僅僅是"造形"的建議而已，並無任何實踐"標準化"的意圖。例如，唐詩七言絕句的形式，並無強迫或規範李白、杜甫等詩人的意圖。

[#2185]Herbert Simon(經濟學諾貝爾獎得主)寫的一本書：The Architecture of Complexity，談到N:N網狀架構能夠轉變成爲多層級N:1樹狀體系，獲得穩定、有機成長的活力。因此發現，這正是全國智慧城市頂層設計的有效思惟借鏡。更多思惟：http://t.cn/8Fo3HIo

[#2186]回覆青潤: 1. 基於我提出的多層樹狀體系，以手機進形攝像機和後臺的動態綁定(Binding); 2)攝像機和後臺進行視頻實時分析處理； 3) 信息推送到手機。

[#2187]<<智慧城市頂層設計的統一系統架構芻議>> 在"移動互聯網"與"物聯網"對接的實踐層面，分爲綁定(Binding)與數據傳輸(Transmit)兩個步驟。這個統一架構偏於前者，以一個穩定、能有機成長的樹狀體系來組織衆多終端或中間結點；迅速綁定目標對象，並決定最佳的數據傳輸途徑。

[#2188]<<智慧城市頂層設計的統一系統架構芻議>> 在"移動互聯網"與"物聯網"對接的實踐層面，分爲綁定(Binding)與數據傳輸(Transmit)兩個步驟。這個統一架構偏於前者，以一個穩定、能有機成長的樹狀體系來組織衆多終端或中間結點；迅速綁定目標對象，並決定最佳的數據傳輸途徑。

[#2189] 有人問到：爲何要由"移動互聯網"來銜接智慧城市裏各個區塊的"物聯網"呢? 其實，我是倒過來從物聯網出發的，想藉由"移動互聯網"來將各"物聯網"的信息，推送到移動終端裏，由於這些物聯網悠關的主人們(Stakeholder)大多隨身攜帶移動終端。更多思惟：http://t.cn/8Fo3HIo

[#2190]可先從目的想起。Herbert Simon(經濟學諾貝爾獎得主)寫的一本書：The Architecture of Complexity，談到N:N網狀架構能夠轉變成爲多層級N:1樹狀體系，獲得穩定、有機成長的活力。因此發現，這正是全國智慧城市頂層設計的有效思惟借鏡，改善目前物聯網網狀架構的瓶頸。

[#2191]<城市遠比家庭更爲複雜> 因此你們想一想如何在架構設計上，從衆多N:N結構的信息孤島羣中，創建一個比較穩定、能有機成長的多層級樹狀體系。因爲只是結構之形，與各業務(如家庭、醫療、公交等)的內涵是無關的。

[#2192]就微信而言，透過各業務區塊(如家庭、醫療、公交車等領域)裏的小平臺(如家庭平臺)的主角(如TV)，來間接(卻衆星拱月)地連結到物聯網的感知終端，於是以API銜接到無限數量硬設備，能夠彌補微信在移動終端OS和通訊平臺上沒有掌握對硬設備API的主導權的困境。

[#2193]@讓您成爲傑出架構師#頂層設計# 智慧城市源於物聯網的基礎，實體層是網狀結構，可是邏輯層必須轉換成一個較爲減化的結構，才能支撐上層商業的複雜關聯性。例如，Database的結構設計，實體層的數據結構識網狀的，必須經由Normalization的減化才能穩定、有機成長。更多思惟：http://t.cn/8Fo3z3r

[#2194]就微信而言，透過各業務區塊(如家庭、醫療、公交車等領域)裏的小平臺(如家庭平臺)的主角(如TV)，來間接(卻衆星拱月)地連結到物聯網的感知終端，藉由微信強大的互聯能力來幫各物聯網推送信息(不必定是實際數據)，藉機成爲智能城市的Command Flow整合中心，也幫了物聯網和城市。

[#2195]武漢是全球幅員最大的城市，但目前許多信息孤島，就像古代的中國。欲社會和諧、生態均衡，頂層設計須要"減法設計"，如秦國 " 書同文、車同軌"，和唐朝"詩同形"。亦即，專家Brooks提出的Conceptual Integrity。

[#2196]我建議武漢在規劃層面要留意：規劃概念的一致性(即書同文、車同軌、詩同形)。另外我還建議在系統架構上，可藉由移動互聯網(如微信、微博等)來聯接衆多物聯網，將衆多的網狀信息孤島，轉變成爲多層樹狀體系。

[#2197]智慧城市的焦點在"智慧"而不在"城市"，城市本質不能因智慧而變，它是永續經營的；智能自己則是善變的，就像衣服(智慧)加諸於人(城市)。衣服要隨着人的成長而換新，不能將人"衣服化"，也不能將城市本質智慧化了。

[#2198]高老師提出這項<<智慧城市頂層設計的統一系統架構的芻議>> ，僅僅是"造形"的建議而已，並無任何實踐"標準化"的意圖。例如，唐詩七言絕句的形式，並無強迫或規範李白、杜甫等詩人的意圖。

[#2199]將Android與iOS採相同的初學教育方式，極可能是錯誤的。由於iOS封閉，學員看不到樹幹，只好看樹葉，各自想象樹幹長相。Android能夠直接看樹幹，對樹葉的前因後果輕易撩若指掌，何苦只知其然(樹葉)不知因此然(樹幹)呢? 換個有效的新觀點!!

[#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的實例？

高煥堂：MISOO(大數據.大思考)聯盟.臺北中心和東京(日本)分社.總教練