導讀

今天讓我們繼續(xù) 《三品軟件——看圖說話系列》，本次討論主題與項目中【需求】的無限增長相關(guān)。
標題借用了美國科研體現(xiàn)中作用最大的一個法案的名稱，《科學：無盡的前沿》。這份法案曾經(jīng)領(lǐng)導美國科技雄霸天下，控制全球產(chǎn)業(yè)。盡管他們是科學，我們是產(chǎn)業(yè)，有較大的差異，但我們在這篇文章中主要關(guān)注其共性，那就是：如何在資源有限的情況下，安排研發(fā)經(jīng)費，如何調(diào)動人力資源，才能逼近最優(yōu)解，并在有限的時間條件下，讓我們獲得的價值最大化。

為節(jié)省您的閱讀時間，這里做個全文概述：

需求是沒有邊界的，項目中不變的規(guī)律就是一直在變（不變的項目通常是死了），然而人力資源（特別是程序員、工程師資源）是有限的，如何解決 【需求無限】 和 【人力有限】 之間的矛盾，這是每一個物聯(lián)網(wǎng)企業(yè)、IT企業(yè)所需要面對的永恒的話題。

本文提出了一個觀點，即：我們通過基于云原生編輯器，可以極大的解決無限需求的問題。

換個角度說：我們可以創(chuàng)建出一個平臺，對外培訓，賦予合作伙伴快速進行高級編輯的能力，對內(nèi)提升平臺自動化程度，用來替換大部分程序員的時間，將項目效率提升數(shù)倍。上述內(nèi)容可能有些費腦，下面我們會慢慢解釋，關(guān)于效率提升數(shù)倍（至少三倍），您一定心存質(zhì)疑，下面讓我們來看看具體的論證過程。

一、現(xiàn)狀

目前的現(xiàn)狀，程序員、工程師所處的位置，位于【連接中樞】（如圖）：

上圖中，我們可以看到：

在項目中，需求的流向，集中在程序員身上，程序員負擔了極大連接的職能，已經(jīng)超負荷，成為了整個系統(tǒng)的瓶頸。

整個系統(tǒng)是串行的，很多流程必須等待程序員，這近似于全程交通擁堵，沒辦法多線程全開。只能雇傭更多程序員，但這樣人力成本又上去了，陷入進退兩難的局面。

策劃經(jīng)理、客戶，無法直接接觸產(chǎn)品，中間被程序員隔斷了，然而系統(tǒng)設(shè)計的 idea 的傳達，需要耗費極大的溝通時間成本，不管是寫策劃文檔也好，又或者是來來回回、高密度的溝通會議也好，都在極大的消耗企業(yè)的人力資源、時間和金錢。

二、啟發(fā)

前面說了，現(xiàn)有模式類似【串行等待模式】，效率無法提升，遇到瓶頸。讓我們再來看看另外一種，【并行模式】，應該會有一些啟發(fā)（如圖）：

上圖中，我們可以看到：

Photoshop 充當了中間節(jié)點，承接了所有連接和交互。

畫家（對應于企業(yè)經(jīng)理和策劃），節(jié)省了和程序員溝通的時間，溝通時間等于零。

畫家直接接觸自己的產(chǎn)品，可以讓自己的需求通過 Photoshop 這個編輯器進行【無限】的變換，想改就改，改后立即可見，可以實現(xiàn)立即反饋、立即改進、立即部署。

以此類推，其他諸如此類的編輯器，如Word、3ds Max、CAD、SolidWorks等，在創(chuàng)作時，創(chuàng)作者同樣無需向程序員提需求便可直接創(chuàng)作。

那么，我們現(xiàn)在得到一些疑問：

為什么 IT 行業(yè)，沒有一個強大的編輯器，可以滿足【創(chuàng)作者】的需求？

為什么我們要重度依賴【程序員】？

三、困難、挑戰(zhàn)和機遇

在給出下一幅圖之前，我們先用文字來描述面臨的困境。阻礙一款強大的 App/網(wǎng)站 編輯器誕生誕生主要有以下這些原因：

1.長期以來【網(wǎng)絡帶寬】一直是個大問題，由于網(wǎng)速太慢，無法支撐云編輯器（多人同時在線編輯一個文檔或項目），而網(wǎng)站、App 則重度依賴 網(wǎng)速，所以很難出現(xiàn)好的在線云原生編輯器。

2.由于歷史遺留問題，傳統(tǒng)的編程是在沒有鼠標交互，而只有鍵盤的環(huán)境下，這種傳統(tǒng)如此牢固，以至于大家都不相信拖拽能得到好的編程體驗。

3.人們對 “高級編程” 過于崇拜，不相信積木式拖拽編輯器可以完成邏輯編程。

4.人們對 “拖拽編輯” 有誤解，認為但凡是編輯器就必須且必然是 “傻瓜化” ，并且拖拽和點擊都是給 “小孩子” 用的，實際我們反思一下就知道，很多編輯器都不是給小孩子使用的，如上面提到的 Word、CAD、3ds Max 等等。而且我們的下一代，大部分都是 iPad 原住民。這個方向值得我們?nèi)ラ_拓。然而，市面上的編輯器，特別是 h5 編輯器，都過于傻瓜化，沒有走向高培訓高技巧的編輯器之路。

5.由于前面提到的對鍵盤編程的崇拜（源于 C++、Linux ），大家認為編程就是鍵盤編程、邏輯就是鍵盤邏輯，布局就是代碼布局，美術(shù)就是美術(shù)設(shè)計完了給程序切圖和組裝。實際上，這些操作都可以由策劃和美術(shù)自己完成，只要我們提供良好的拖拽界面和少量的培訓。目前還沒有一家公司想到把UI界面布局和邏輯拖拽合二為一，這說明這件事情很困難，也說明這極有可能是一片藍海。

6.瀏覽器早期的競爭，使得網(wǎng)絡編程環(huán)境不穩(wěn)定，特別是 IE 系列瀏覽器，用戶無法在不同的瀏覽器中獲得一致的視覺和交互體驗。

7.傳統(tǒng)的編程環(huán)境中存在很多【人力斷層】，在這些斷層中，您會看到大量的程序員在做【非自動化】的工作，如：書寫各種包含符號和括號的腳本，這些腳本不提供智能化提示，難以維護。還有其它場景：手工對接接口、手工解析信號（get 和 post 協(xié)議）、手工編譯、手工部署、遠程登錄和調(diào)試。而要做出完美的編輯平臺，這些步驟都必須全部自動化。這又帶來 “性能” 問題，下面一點會講到。

8.人們迷信只有 “程序員親手寫出的代碼” 才是高性能的代碼，實際上大部分程序員是調(diào)包程序員或者膠水程序員，他們產(chǎn)生的代碼，不但性能不高，而且有可能性能很差，經(jīng)常報錯。

9.優(yōu)秀程序員不是不存在，而是被大廠壟斷，中小企業(yè)難以承擔優(yōu)秀程序員過高的成本。

10.并沒有任何一個平臺能夠?qū)?yōu)秀程序員輸出的組件以人性化的方式提供給廣大的產(chǎn)品經(jīng)理或策劃，即便是 github 和 npm 社區(qū)，也沒有做到，這不是能力問題，而是習慣問題，由于慣性思維，人們傾向于雇傭程序員團隊 ，然后間接實現(xiàn)產(chǎn)品，而不是提供編輯器給產(chǎn)品經(jīng)理，讓產(chǎn)品經(jīng)理有能力去直接構(gòu)建產(chǎn)品。

11.跨界程序員太少，以致于很少有程序員能想到【合并界面編輯器和邏輯編輯器】。

12程序員即便是想到這條路徑，但令人遺憾的是，程序員表達能力通常不足，而大部分企業(yè)負責人也只愿意嘗試現(xiàn)有模式，不愿意承擔風險和代價。但是，我們都知道，越是有風險的事情，越有機會，因為大部分人都不敢踏入雷池，只有膽大者可以搶占先機，實際投資的時候，也不需要  ALL  IN  所有資源。

13.實際實現(xiàn)過程中，還有很多斷層，包含但不限于這些：數(shù)據(jù)庫、Linux/Windows部署環(huán)境設(shè)置、域名設(shè)置、緩存配置、連接斷層、權(quán)限斷層、底層瀏覽器生態(tài)斷層......要合并這些斷層，沒有極強的架構(gòu)能力和預見能力，是無法達成的。因為困難，所以很多拖拽式編輯器的企業(yè)，放棄了合并這些斷層，放棄了邏輯編輯器，最后只能做簡單定制。話又說回來，有時候難，恰恰代表了機遇，因為無人競爭。

反過來看，我們認準的方向，也并不是盲目和毫無根據(jù)的，可以觀察到，目前各種條件已經(jīng)接近成熟，筆者認為是時候做一款界面布局和邏輯拖拽合為一體的產(chǎn)品了，理由如下：

1.5G 來臨，未來不管我們身在何處，網(wǎng)速將不再是問題。

2.設(shè)備越來越輕量化，特別是今年，VR 設(shè)備解決了很多暈眩和分辨率的問題，正在重新火起來，拖拽式編輯將迎來新的藍海。將來，用戶隨時隨地都可以使用大屏幕拖拽編輯+語音輔助控制+VR空間編輯。

3.FaceBook 正在研發(fā)新的手環(huán)，一旦完成，可以支持在 3D 虛擬空間中，輕易拿捏 和抓取物品，編輯物品，編輯的效率將迎來巨大的飛躍。

4.語音控制越來越智能化，可以用來輔助編輯器，提高編輯效率。

5.React 、 Vue 等項目，也間接地證明了，模塊化是未來的趨勢，一個邏輯文件上千行的歷史，將一去不復返，而積木式編輯器，正好可以在少量代碼的環(huán)境下流暢工作。

6.Flash 、Weex、Flutter 等項目，都在試圖統(tǒng)一當年瀏覽器沒有做到的一致化環(huán)境，而 WebAssembly 技術(shù)，也在不斷的進行統(tǒng)一規(guī)劃，未來的環(huán)境會越來越好。

7.由于摩爾定律的指引，CPU 、內(nèi)存等資源的成本逐年下降，我們現(xiàn)在可以用自動化批處理程序來替代很多程序員的手工操作，這實際是用算力換時間，容量換時間。

8.人工智能的發(fā)展，也給平臺智能化運作帶來了曙光。

9.網(wǎng)絡的評價模式，用戶內(nèi)容的產(chǎn)出模式以及分享模式，已經(jīng)在現(xiàn)有的大量 App 上得到了驗證，我們只需要把這種模式推廣到 組件編輯器云平臺上。

10.蘋果的 AppStore 模式，也證明了軟件市場的潛在價值，而我們可以參照此模式，產(chǎn)生出一個全新的，更低顆粒度的積木市場。用戶可以用積木搭建自己的 App。

11.天使投資家的眼界也越來越豐富，以此為目標的團隊，只要能獲得對應的驗證數(shù)據(jù)，相信能通過風險投資進行快速擴張，并最終形成具有網(wǎng)絡優(yōu)勢的組件市場，如此，資金便不再是問題。

12.Chrome 以及 Flutter 、 Kraken 等平臺的性能，已經(jīng)接近原生，是時候考慮跨平臺編輯器了。

13.我們在企業(yè)內(nèi)部已經(jīng)獲得共識，即：一切都是輸入、處理、輸出，包括產(chǎn)品策劃的文檔以及編程的代碼，本質(zhì)上都是在編輯函數(shù)，也就是說，文檔、組件、積木、封裝、函數(shù)、邏輯，可以等價，既然如此，何不嘗試做一個統(tǒng)一編輯界面，產(chǎn)品經(jīng)理和策劃，直接操作編輯器，而程序員只需遠程提供積木式組件支持。

四、最終架構(gòu)

總結(jié)起來，編輯器獲得的，就一個字，快。為什么快呢？請看下圖：

由上圖，我們可以看到，用戶通過編輯器，直接編輯自己的產(chǎn)品，無需等待，可以獲得即時反饋，三方是并行狀態(tài)，互不阻塞。這本身就代表了效率的極大提升（至少三倍）。這當中，有沒有漏洞和難題呢 ？有的，但也不是沒有規(guī)避的路徑：

1.一開始組件會非常少（這個可以通過合作的方式解決，開源社區(qū)和企業(yè)伙伴都可以貢獻組件，我們內(nèi)部也積累了一些組件，而且目前平臺可以快速封裝現(xiàn)有組件，這方面幾乎沒有實施風險）

2.一開始的培訓過程需要反復斟酌（還好我們內(nèi)部有程序員曾經(jīng)做過培訓教師）

3.社區(qū)的分享和付費機制、以及規(guī)章制度，有一個完善的過程（需要磨合）。

4.拖拽式交互體驗需要不斷迭代。（需要時間打磨）

5.平臺不夠自動化。（需要我們補全和編寫自動化編譯和部署邏輯）

一旦解決以上問題，將會產(chǎn)生飛輪效應：組件越多 → 用戶越多 → 慕名來平臺賺取收入的程序員也就越多 → 能篩選出的優(yōu)質(zhì)組件也就越多 → 用戶也就越多。這是一個正循環(huán)。

三品軟件目前正在努力達成這一平臺，設(shè)立了一個專門運營此項目的部門，我們希望在不久的將來能通過這個平臺賦能給我們的企業(yè)客戶，讓他們獲得如下能力：

1、 像現(xiàn)有的H5編輯平臺那樣，快速生成App和 網(wǎng)站，但依然保有強大細致的像素級定制和更新能力。

2、通過云平臺編輯器， 快速生成企業(yè)自身的編輯器 ，不必依賴程序員。

3、企業(yè)之間，可以自由的共享和售賣自己編寫的組件，不必再拖延到完成整個項目，將來的企業(yè)，可以只專注于單個組件，而沒有必要完成整個項目（這是一種社會資源浪費，也是內(nèi)卷）。

4、 快速對接其它企業(yè)的能力。

5、 自動部署的能力。

6、 像Word或CAD一樣，最大限度剝離程序員，節(jié)省大量溝通成本。

7、 企業(yè)則由此降低了人力成本，有更多的經(jīng)費應對經(jīng)濟危機，有更多的資金進行其它的投資。

筆者認為這樣的平臺建立起來后，可能會淘汰一批技術(shù)落后的程序員。物競天擇，優(yōu)勝劣汰，革自己的命，讓天下程序員無路可走，在競爭激烈的大環(huán)境下，存活下來的程序員都是最優(yōu)秀的。而在組件式平臺上，也只有最好的那幾家可以通過提供良好的拖拽式體驗，以及穩(wěn)定的組件存活。
拖拽式雖然有很多項目在嘗試，但真正并入邏輯拖拽的廠商，少之又少，而我們認為，即便是編寫邏輯，人腦也更愿意用手指拖拽的方式來操作，人腦是惰性的，自然會選擇更貼近手指的操作。并且隨著基礎(chǔ)設(shè)施的完善（網(wǎng)絡、VR、硬件智能等），拖拽的編輯效率最終會超過鍵盤編程，而且您可以在家中，就可以享用全世界最好的程序員寫出來的最穩(wěn)定的組件，也可以享用最優(yōu)秀的美術(shù)，提供的最精致的界面裝飾。為什么不呢？三品軟件正在路上，目前我們已完成了很多基礎(chǔ)工作，比如布局管理器和表單管理器，正在完成最后一塊拼圖：邏輯組件編輯器以及相關(guān)的推薦、評論、分享付費型社區(qū)。

期待有更多合作伙伴加入我們，共同建設(shè)下一個擁有良好編輯體驗的組件化全球市場。如果您有更好的建議或意見，歡迎與我們聯(lián)系探討。