前言

新技術層出不窮。過去十年時間裡，我們經歷了許多激動人心的新技術，包括那些新的框架、語言、平臺、程式設計模型等等。這些新技術極大地改善了開發人員的工作環境，縮短了產品和專案的面世時間。然而作為在軟體行業第一線工作多年的從業者，我們卻不得不面對一個現實，那就是當初採用新技術的樂趣隨著專案週期的增長而迅速減少。無論當初的選擇多麼光鮮，半年、一年之後，只要這個專案依然活躍，業務在擴張——越來越多的功能需要加入，一些公共的問題就會逐漸顯露出來。構建過慢，完成新功能讓你痛不欲生，團隊成員無法很快融入，文件無法及時更新等等。

在長期運轉的專案中，架構的腐化是怎麼產生的？為什麼常見的物件導向技術無法解決這類問題？如何延緩架構的腐化？

本文將嘗試解釋這一切，並提出相應的解決方案。讀者需要具備相當的開發經驗——至少在同一個專案的開發上一年以上；公司負責架構演進、產品演進的角色會從本文找到靈感。

架構

架構這個詞在各種場合不斷地以各種面目表現出來。從維基百科的詞條看來，我們經常聽到的有外掛架構（Plugin），以資料庫為中心的架構（Database Centric），模型-檢視-控制器架構（MVC），面向服務的架構（SOA），三層模型(Three-Tier model)，模型驅動架構（MDA）等等等等。奇妙的是，這些詞越大，實際的開發者就越痛苦。SOA很好——但在它提出的那個年代，帶給開發者的只是面向廠商虛無縹緲的“公共資料型別”；MDA甚至都沒有機會淪為新一輪令人笑話的CASE工具。

在繼續閱讀之前，讀者不妨問自己一個問題：在長期的專案中，這些大詞是否真的切實給你帶來過好處？更為功利的問題是：你，作為戰鬥在一線的開發者，在長期專案中可曾有過美好的體驗？

技術的演變與揮之不去的痛

企業應用的發展似乎從十年前開始騰飛。從Microsoft ASP/LAMP(Linux、Apache、MySQL、PHP)年代開始，各種企業應用紛紛向瀏覽器遷移。經過十年的發展，目前陣營已經百花齊放。與過去不同，現在的技術不僅僅在程式語言方面，常見的程式設計套路、最佳實踐、方法學、社群，都是各種技術獨特擁有的。目前佔據主流的陣營有：

• Rails

• Java EE平臺。值得一提的是Java VM已經成為一種新的宿主平臺，Scala、JRuby更為活躍並引人矚目

• LAMP平臺。Linux/MySQL/Apache並沒有多少變化，PHP社群從Rails社群獲得了不少養分，出現了許多更加優秀的開發框架

• Microsoft .NET平臺

• Django

沒有理由對這些新技術不感到振奮。它們解決了許多它們出現之前的問題。在它們的網站上都宣稱各種生產效率如何之高的廣告語，類似於15分鐘建立一個部落格應用；2分鐘快速教程等等。比起過去21天才能學會XXX，現在它們在上手難度上早已大幅度降低。

需要潑冷水的是，本文開篇提出的問題，在上述任何一種技術下，都如幽靈般揮之不去。採用Ruby on Rails的某高效團隊在10人團隊工作半年之後，構建時間從當初的2分鐘變成2小時；我們之前採用Microsoft .NET 3.5 (C# 3.0)的一個專案，在產生2萬行程式碼的時候，構建時間已經超過半小時；我們的一些客戶，工作在10年的Java程式碼庫上——他們竭盡全力，保持技術棧與時俱進：Spring、Hibernate、Struts等，面對的困境是他們需要同時開啟72個專案才能在Eclipse中獲得編譯；由於編譯打包時間過長，他們去掉了大部分的單元測試——帶來巨大的質量風險。

如果你真的在一個長期的專案工作過，你應該清楚地瞭解到，這種痛苦，似乎不是任何一種框架能夠根本性解決的。這些新時代的框架解決了大部分顯而易見的問題，然而在一個長期專案中所面對的問題，它們無能為力。

一步一步：架構是如何腐化的

無論架構師在任何時代以何種絢麗的方式描述架構，開發中的專案不會超出下圖所示：

基本架構示意

一些基本的準則：

• 為了降低耦合，系統應當以恰當的方式進行分層。目前最經考驗的分層是MVC+Service。

• 為了提供基礎的訪問，一些基本的、平臺級別的API應該被引入。用Spring之類的框架來做這件事情。

• 用AOP進行橫向切分業務層面共性的操作，例如日誌、許可權等。

• 為了保證專案正常構建，你還需要資料庫、持續整合伺服器，以及對應的與環境無關的構建指令碼和資料庫遷移指令碼。

階段1

滿足這個條件的架構在初期是非常令人愉悅的。上一部分我們描述的框架都符合這種架構。這個階段開發非常快：IDE開啟很快，開發功能完成很快，團隊這個時候往往規模較小，交流也沒有問題。所有人都很高興——因為用了新技術，因為這個架構是如此的簡單、清晰、有效。

階段2

好日子不算太長。

很快你的老闆（或者客戶，隨便什麼）有一攬子的想法要在這個團隊實現。工作有條不紊的展開。更多的功能加入進來，更多的團隊成員也加入了進來。新加入的功能也按照之前的架構方式開發著；新加入的團隊成員也對清晰的架構表示欣喜，也一絲不苟的遵循著。用不了多久——也許是三個月，或者更短，你會發現程式碼庫變成下面的樣子：

正常開發之後

你也許很快會意識到這其中有什麼問題。但你很難意識到這到底意味著什麼。常見的動作往往圍繞著重構——將縱向相關的抽取出來，形成一個新的專案；橫向相關的抽取出來，形成一個名叫common或者base的專案。

無論你做什麼型別的重構，一些變化在悄悄產生（也許只是快慢的不同）。構建過程不可避免的變長。從剛開始的一兩分鐘變成好幾分鐘，到十幾分鍾。通過重構構建指令碼，去掉那些不需要的部分，構建時間會降到幾分鐘，你滿意了，於是繼續。

階段3

更多的功能、更多的成員加入了。構建時間又變長了。隨著載入程式碼的增多，IDE也慢了下來；交流也多了起來——不是所有人能夠了解所有程式碼了。在某些時候，一個很有道德的程式設計師嘗試重構一部分重複邏輯，發現牽涉的程式碼太多了，好多都是他看不懂的業務，於是他放棄了。更多的人這麼做了，程式碼庫越來越臃腫，最終沒有一個人能夠搞清楚系統具體是怎麼工作的了。

針對架構的技術我建立一個Java架構學習群619881427，裡面會分享錄製微服務，分散式，原始碼分析，JVM，Java工程化這些專題的視訊，感興趣的朋友可以加一下。

系統在混亂的狀態下繼續緩慢地混亂——這個過程遠比本文寫作的時間要長很多，之間會有反覆，但據我觀察，在不超過1年的時間內，無論採用何種技術框架，應用何種架構，這個過程似乎是不可抗拒的宿命。

常見的解決方案

我們並非是坐以待斃的。身邊優秀的同事們在問題發現之前採取了各種解決方案。常見的解決方案如下：

升級工作環境

沒有什麼比一臺與時俱進的電腦更能激勵開發人員了。最多每隔三年，升級一次開發人員的電腦——升級到當時最好的配置，能夠大幅度的提升生產效率，激勵開發人員。反過來，利用過時的電腦，在慢速的機器上進行開發，帶來的不僅僅是客觀上開發效率的降低，更大程度上帶來的是開發人員心理上的懈怠。

升級的工作環境不僅僅是電腦，還包括工作的空間。良好的，促進溝通的空間（以及工作方式）能夠促進問題的發現從而減少問題的產生。隔斷不適合開發。

分階段的構建

一般而言，構建的順序是：本地構建確保所有的功能執行正常，然後提交等待持續整合工作正常。本地構建超過5分鐘的時候就變得難以忍受；大多數情況下你希望這個反饋時間越短越好。專案的初期往往會執行所有的步驟：編譯所有程式碼，執行所有測試。隨著專案週期的變長，程式碼的增多，時間會越來越長。在嘗試若干次重構構建指令碼再也沒辦法優化之後，“分階段構建”成為絕大多數的選擇。通過合理的拆分、分層，每次執行特定的步驟，例如只執行特定的測試、只構建必要的部分；然後提交，讓持續整合伺服器執行所有的步驟。這樣開發者能夠繼續進行後續的工作。

分散式構建

即便本地快了起來，採用分階段構建的團隊很快發現，CI伺服器的構建時間也越來越讓人不滿意。每次提交半小時之後才能得到構建結果太不可接受了。各種各樣的分散式技術被建立出來。除了常見的CI伺服器本身提供的能力，許多團隊也發明了自己的分散式技術，他們往往能夠將程式碼分佈到多臺機器進行編譯和執行測試。這種解決方案能夠在比較長的一段時間內生效——當構建變慢的時候，只需要調整分佈策略，讓構建過程執行在更多的叢集機器上，就可以顯著的減少構建時間。

採用JRebel或者Spork

一些新的工具能夠顯著地提速開發人員的工作。JRebel能夠將需要編譯的Java語言變成修改、儲存立即生效，減少了大量的修改、儲存、重新編譯、部署的時間；Spork能夠啟動一個Server，將RSpec測試相關的程式碼快取於其中，這樣在執行RSpec測試的時候就不用重新進行載入，極大提升了效率。

到底是什麼問題？

上述的解決方案在特定的時間域內很好地解決了一部分問題。然而，在專案運轉一年，兩年或者更久，它們最終依然無法避免構建時間變長、開發變慢、程式碼變得混亂、架構晦澀難懂、新人難以上手等問題。到底問題的癥結是什麼？

人們喜歡簡潔。但這更多的看起來是一個謊言——沒有多少團隊能夠自始至終保持簡潔。人們喜歡簡潔只是因為這個難以做到。並不是說人們不願意如此。很多人都知道軟體開發不比其他的勞動力密集型的行業——人越多，產量越大。《人月神話》中已經提到，專案增加更多的人，在提升工作產出的同時，也產生了混亂。短期內，這些混亂能夠被團隊通過各種形式消化；但從長期看來，隨著團隊人員的變動（新人加入，老人離開），以及人正常自然的遺忘曲線，程式碼庫會逐漸失控，混亂無法被消化，而專案並不會停止，新功能不斷的加入，架構就在一天天的過程中被腐蝕。

人的理解總有一個邊界，而需求和功能不會——今天的功能總比昨天的多；這個版本的功能總比上個版本的多。而在長時間的開發中，忘記之前的程式碼是正常的；忘記某些約定也是正常的。形成某些小而不經意的錯誤是正常的，在巨大的程式碼庫中，這些小錯誤被忽視也是正常的。這些不斷積攢的小小的不一致、錯誤，隨著時間的積累，最終變得難以控制。

很少有人注意到，規模的變大才是導致架構腐化的根源——因果關係在時空上的不連續，使得人們並不能從其中獲得經驗，只是一再重複這個悲劇的迴圈。

解決方案

解決方案的終極目標是：在混亂髮生之前，在我們的認知出現障礙之前，就將專案的規模控制在一定範圍之內。這並不容易。大多數團隊都有相當的交付壓力。大多數的業務使用者並沒有意識到，往一個專案/產品毫無節制地增加需求只會導致產品的崩潰。看看Lotus Notes，你就知道產品最終會多麼令人費解、難以使用。我們這裡主要討論的是技術方案。業務上你也需要始終對需求的增長保持警惕。

0. 採用新技術

這可能是最廉價的、最容易採用的方案。新技術的產生往往為了解決某些特定的問題，它們往往是經驗的集合。學習，理解這些新技術能夠極大程度減少過去為了完成某些技術目標而進行的必要的經驗積累過程。就像武俠小說中經常有離奇遭遇的主人公突然獲得某個世外高人多年的內力一樣，這些新技術能夠迅速幫助團隊從某些特定的痛點中解脫出來。

已經有足夠多的例子來證明這一觀點。在Spring出現之前，開發者的基本上只能遵循J2EE模式文件中的各種實踐，來構建自己的系統。有一些簡單的框架能夠幫助這一過程，但總體來說，在處理今天看起來很基礎的如資料庫連線，異常管理，系統分層等等方面，還有很多手工的工作要做。Spring出現之後，你不需要花費很多精力，很快就能得到一個系統分層良好、大部分設施已經準備就緒的基礎。這為減少程式碼庫容量以及解決可能出現的低階Bug提供了幫助。

Rails則是另外一個極端的例子。Rails帶來的不僅僅是開發的便利，還帶來了人們在Linux世界多年的部署經驗。資料庫Migration， Apache + FastCGI或者nginx+passenger，這些過去看起來複雜異常的技術在Rails中變得無足輕重——稍懂命令列的人即可進行部署。

任何一個組織都無法全部擁有這些新技術。因此作為軟體從業者，需要不斷地保持對技術社群的關注。閉門造車只能加速架構的腐化——特別是這些自己的發明在開源社群早已有成熟的方案的時候。在那些貌似光鮮的產品背後，實際上有著無數的失敗的案例成功的經驗在支撐。

針對架構的技術我建立一個Java架構學習群251981998，裡面會分享錄製微服務，分散式，原始碼分析，JVM，Java工程化這些專題的視訊，感興趣的朋友可以加一下，進來可以免費獲取下面的學習資料。

我們曾經有一個專案。在意識到需求可能轉向類似於key-value的文件資料庫之後，團隊大膽的嘗試採用SQLServer 2008的XML能力，在SQL Server內部實現了類似於No-SQL的資料庫。這是一個新的發明，創造者初期很興奮，終於有機會做不同的事情了。然而隨著專案的進行，越來越多的需求出現了：Migration的支援、監控、管理工具的支援、文件、效能等等。隨著專案的進展，最終發現這些能力與時下流行的MongoDB是如此的相似 ——MongoDB已經解決了大多數的問題。這個時候，程式碼庫已經有相當的規模了——而這部分的程式碼，讓許多團隊成員費解；在一年之後，大約只有2個人能夠了解其實現過程。如果在早期採用MongoDB，團隊本有機會摒棄大部分相關的工作。

值得一提的是，高傲的開發者往往對新技術不夠耐心；或者說對新技術的能力或侷限缺乏足夠耐心去了解。每一個產品都有其針對的問題域，對於問題域之外，新技術往往沒有成熟到能夠應對的地步。開發者需要不斷地閱讀、思考、參與，來驗證自己的問題域是否與其匹配。淺嘗輒止不是好的態度，也阻礙了新技術在團隊內的推廣。

新技術的選型往往發生在專案/產品特定的時期，如開始階段，某個特定的痛點時期。日常階段，開發者仍然需要保持對程式碼庫的關注。下一條，重構到物理隔離的元件則是對不斷增大的程式碼庫另一種解決方案。

1. 重構到物理隔離的元件

顯而易見的趨勢是，對於同一個產品而言，需求總是不斷增多的。去年有100個功能，今年就有200個。去年有10萬行程式碼，今年也許就有20萬行。去年2G 記憶體的機器能夠正常開發，今年似乎得加倍才行。去年有15個開發人員，今年就到30個了。去年構建一次最多15–20分鐘，今年就得1個小時了，還得整個分散式的。

有人會注意到程式碼的設計問題，孜孜不倦地進行著重構；有人會注意到構建變慢的問題，不懈地改進著構建時間。然而很少有人注意到程式碼庫的變大才是問題的根源。很多常規的策略往往是針對組織的：例如將程式碼庫按照功能模組劃分（例如ABC功能之類）或者按層次劃分（例如持久層、表現層），但這些拆分之後的專案依然存在於開發人員的工作空間中。無論專案如何組織，開發者都需要開啟所有的專案才能完成編譯和執行過程。我曾經見到一個團隊需要在Visual Studio中開啟120個專案；我自己也經歷過需要在Eclipse中開啟72個專案才能完成編譯。

解決方案是物理隔離這些元件。就像團隊在使用Spring/Hibernate/Asp.NET MVC/ActiveRecord這些庫的時候，不用將它們對應的原始碼放到工作空間進行編譯一樣，團隊也可以將穩定工作的程式碼單元整理出來形成對應的庫，標記版本然後直接引用二進位制檔案。

在不同的技術平臺上有著不同的方案。Java世界有歷史悠久的Maven庫，能夠良好的將不同版本的 JAR以及他們的以來進行管理；.NET比較遺憾，這方面真正成熟的什麼也沒有——但參考Maven的實現，團隊自己造一個也不是難事（可能比較困難的是與MSBuild的整合）；Ruby/Rails世界則有著名的gem/bundler系統。將自己整理出來的比較獨立的模組不要放到rails/lib /中，整理出來，形成一個新的gem，對其進行依賴引用（團隊內需要搭建自己的gems庫）。

同時，程式碼庫也需要進行大刀闊斧的整改。之前的程式碼結構可能如下，（這裡以SVN為例，因為SVN有明確的trunk/branches/tags目錄結構。git/hg類似）

原來的庫結構

改進之後，將會如下圖所示：

改進的庫結構

每個模組都有屬於自己的程式碼庫，擁有自己的獨立的升級和釋出週期，甚至有自己的文件。

這一方案看起來很容易理解，但在實際操作過程中則困難重重。團隊運轉很長一段時間之後，很少有人去關心模組之間的依賴。一旦要拆分出來，去分析幾十上百個現存專案之間的依賴相當費勁。最簡單的處理辦法是，檢查程式碼庫的提交記錄，例如最近3個月之內某個模組就沒有人提交過，那麼這個模組基本上就可以拿出來形成二進位制依賴了。

很多開源產品都是通過這個過程形成的，例如Spring（請參考閱讀《J2EE設計開發程式設計指南》，Rod Johnson基本上闡述了整個Spring的設計思路來源）。一旦團隊開始這樣去思考，每隔一段時間重新審視程式碼庫，你會發現核心程式碼庫不可能失控，同時也獲得了一組設計良好、工作穩定的元件。

2. 將獨立的模組放入獨立的程式

上面的解決方案核心原則只有一條：始終將核心程式碼庫控制在團隊可以理解的範圍內。如果運轉良好，能夠很大程度上解決架構因為程式碼規模變大而腐化的問題。然而該解決方案只解決了在系統在靜態層面的隔離。當隔離出的模組越來越多，系統也因此也需要越來越多的依賴來執行。這部分依賴在執行期分為兩類：一類是類似於 Spring/Hibernate/Apache Commons之類的，系統執行的基礎，執行期這些必須存在；另外一類是相對獨立的業務功能，例如快取的讀取，電子商城的支付模組等。

第二類依賴則可以更進一步：將其放到獨立的程式中。現在稍具規模的系統，登入、登出功能已經從應用中脫離而出，要麼採用SSO的方案來進行登陸，要麼則乾脆代理給別的登陸系統。LiveJournal團隊在開發過程中，發現快取的讀寫實際上可以放到獨立的程式中進行（而不是類似EhCache的方案，直接執行於所在的執行環境中），於是發明了現在鼎鼎有名的memcached. 我們之前進行的一個專案中，發現支付模組完全能夠獨立出來，於是將其進行隔離，形成了一個新的、沒有介面的、永遠在執行的系統，通過REST處理支付請求。在另外一個出版專案中，我們發現編輯編寫報告的過程實際上與報告發行過程雖然存在類級別的重用，但在業務層面是獨立的。最終我們將報告發行過程做成了一個常駐服務，系統其他的模組通過MQ訊息與其進行互動。

這一解決方案應該不難理解。與解決方案1不同的是，這一方案更多的是要對系統進行面向業務層面的思考。由於系統將會以獨立的程式來執行這一模組，在不同的程式中可能存在一定的程式碼重複。例如Spring同時存在兩個不相關的專案中大家覺得沒什麼大不了的；但如果是自己的某個業務元件同時在同一個專案的兩個程式中重複，許多人就有些潔癖不可接受了。（題外話：這種潔癖在OSGi環境中也存在）這裡需要提醒的是：當處於不同的程式時，它們在物理上、執行時上已經徹底隔離了。必須以程式的觀點去思考整個架構，而不是簡單的物理結構。

從單程式模型到多程式模型的架構思維轉變也不太容易——需要架構師有意識的加強這方面的練習。流行的.NET和Java世界傾向於把什麼都放到一起。而 Linux世界Rails/Django則能更好的平衡優秀產品之間的程式協調。例如memcached的使用。另外，現在多核環境越來越多，與其費盡心思在程式語言層面上不如享受多核的好處，多程式能夠簡單並且顯著地利用多核能力。

3. 形成高度鬆散耦合的平臺+應用

現在將眼光看更遠一些。想象一下我們在做一個類似於開心網、Facebook、人人網的系統。它們的共同特點是能夠接入幾乎無限的第三方應用，無論是買賣朋友這類簡單的應用，還是絢麗無比的各種社交遊戲。神奇的是，實現這一點並不需要第三方應用的開發者採用跟它們一樣的技術平臺，也不需要服務端提供無限的運算能力——大部分的架構由開發方來控制。

在企業應用中實現這個並不難。這其中的祕訣在於：當使用者通過Facebook訪問某個第三方應用的時候，Facebook實際上通過後臺去訪問了第三方應用，將當前使用者的資訊（以及好友資訊）通過HTTP POST送到第三方應用指定的服務網址，然後將應用的HTML結果渲染到當前頁面中。某種意義上說，這種技術本質上是一種伺服器端的mashup. （詳情參考InfoQ 文章）

Facebook App架構

這種架構的優點在於極度的分散式。從外觀上看起來一致的系統，實際由若干個耦合極低、技術架構完全不同的小應用組成。它們不需要被部署在同一臺機器上，可以單獨地開發、升級、優化。一個應用的癱瘓不影響整個系統的執行；每個應用的自行升級對整個系統也完全沒有影響。

這並非是終極的解決方案，只在某些特定的條件下有效。當系統規模上非常龐大，例如由若干個子系統組成；介面基本一致；子系統之間關聯較少。針對這個前提，可以考慮採用這種架構。抽象出極少的、真正有效公用的資訊，在系統之間通過HTTP POST.。其他的系統完全可以獨立開發、部署，甚至針對應用訪問的情況進行特定的部署優化。如果不這麼做，動輒上百萬千萬行的程式碼堆在一個系統中，隨著時間的推移，開發者逐漸對程式碼失控，架構的腐化是遲早的事情。

例如，銀行的財務系統，包括了十多個個子系統，包括薪資、資產、報表等等模組，每一部分功能都相對獨立並且複雜。整個系統如果按照這種方式拆分，就能夠實現單點優化而無需重新啟動整個應用。針對每個應用，開發者能夠在更小的程式碼內採用自己熟悉的技術方案，從而減少架構腐化的可能。

結語

沒有糟糕的架構，變化使之

我訪問過很多團隊。在很多專案開始的時候，他們花很多時間在選擇用何種技術體系，何種架構，乃至何種IDE。就像小孩子選擇自己鍾愛的玩具，我相信無論過程如何，團隊最終都會欣然選擇他們所選擇的，並且堅信他們的選擇沒有錯誤。事實也確實如此。在專案的開始階段很難有真正的架構挑戰。困難的地方在於，隨著時間的增長，人們會忘記；有很多的人加入，他們需要理解舊程式碼的同時完成新功能；每一次程式碼量的突破，都會引起架構的不適應；這些不適應包括：新功能引入變得困難，新人難以迅速上手；構建時間變長等等。這些能否引起團隊的警覺，並且採取結構性的解決方案而不是臨時性的。

關於文件

很多人說敏捷不提倡文件。他們說文件很難寫。他們說開發人員寫不了文件。於是就沒有文件。

奇怪的是我看到的情況卻不是這樣。程式寫得優秀的人，寫起文字來也很不錯。ThoughtBlogs上絕大多數都是程式設計師，很多人的文字寫得都很贊。

而專案中的文件往往少得可憐。新人來了總是一頭霧水。令人奇怪的是，新人能夠一天或者兩天之內通過閱讀RSpec或者JBehave迅速瞭解這些工具的使用，到了團隊裡面卻沒有了文件。

拋開專案持續運轉並交付的特性不談，我認為巨大的、不穩定的程式碼庫是文件迅速失效的根源。如果我們能夠按照上述的解決方案，將程式碼庫縮小，那麼獨立出來的模組或者應用就有機會在更小的範圍內具備更獨特的價值。想象一下現在的Rails3/Spring框架，他們往往有超過20個第三方依賴，我們卻沒有覺得理解困難，最重要的原因是依賴隔離之後，這些模組有了獨立的文件可以學習。

企業級專案也可以如此。

建立應用程式的生態環境，而非單一的專案

功能總是不斷的、不斷的加到同一個產品中。這毫不奇怪。然而通過我們前面的分析，我們應當重新思考這個常識。是建立一個日益龐大的、緩慢的、毫無生機的產品，還是將其有機分解，成為一個生機勃勃的具有不同依賴的生態系統？專案的各方人員（包括業務使用者、架構師、開發者）應當從短視的眼光中走出來，著眼於建立可持續的應用程式生態系統。