低程式碼平臺在移動開發方面的缺陷

本文由公眾號EAWorld翻譯發表，轉載需註明出處。

作者：Timo Railo 

譯者：白小白 

原題：Why most low-code platforms fall short on mobile development 

原文：http://t.cn/Exd4Gg1

白小白：

文章翻好後，我請一位在移動平臺領域工作多年的同事看了下，他的看法是，首先文中所講的一些內容並不適合中國的國情。比如，從他接觸的客戶來看，多數大廠的技術路線已經不考慮對基於WebView的應用整合。從UI模型的角度看，RN、Flutter（谷歌推出的移動框架，已經發布到1.2版本）包括國內一些業界的移動平臺從未強調低程式碼，但是強調程式碼通過UI模型與設計儘可能連貫。

從文中所述的情況來看，國外的移動平臺，至少在以私有方式部署的移動平臺領域，技術上或者說技術的應用上相對於國內還是有所落後的，比如文中所說的未見有企業級實踐的React Native技術，就國內來說，金證股份，韻達快遞，張家港農商行，中信重工，陝西國土等行業使用者都已經基於RN技術的移動平臺建設了自己的移動應用。

從我個人的角度，我認為文中關於選擇移動平臺的考量要素，對開發者的體驗重視，以及對遺留系統的整合等內容的闡述，還是有一定的參考意義，因此還是推薦給大家看下。歡迎在文後給出評論，講下自己的看法。

簡單說一下背景：從Mac OS 9的時代（大概是1980年代末）以來，我一直在使用各種不同的快速開發平臺和低程式碼開發工具。這些工具和平臺讓我愛恨交加。理想情況下，工具可以幫你節省80%的工作，但卻對剩餘的20%無能為力。同時，從Sybian系統大行其道的時代開始，我就從事與移動應用開發相關的工作，那是蘋果公司尚未在移動應用領域掀起驚天革命的年代。

我的另一個身份是Appzio公司的CTO，公司的主業是為原生移動應用開發提供低程式碼開發平臺。我們曾經把Appzio的設計理念定義為“人人皆可開發應用”，當然，我們很快意識到這是一個嚴重的思維誤區，並摒棄了這個理念。

可以說，我對這個行業知之甚深，並願意分享我的如下觀點：多數的低程式碼平臺在高質量的移動應用開發方面並不盡如人意。

依據以往的個人經驗，我會揭示一些低程式碼平臺所固有的缺陷，並提出一些值得被關注的重要問題，這些問題往往會被大多數人所忽略。本文適用於iOS或者Android移動應用的開發。

一、視覺化配置VS程式碼開發：

收益遞減的臨界點

能夠讓你以視覺化配置的方式或者編輯器來開發移動應用的工具多如牛毛。像是Mobile Roadie、Good Barber、AppyPie、AppMachine這類工具還提供了預定義的功能模組和基於網頁的配置工具。但這些工具的成熟性還存在一些問題，並且也無法提供額外的特性。

AppyPie的配置介面

諸如Mendix、Outsystem、Appian和Kony這些企業級工具提供了複雜的視覺化編輯器。起初，這樣的產品設計可以讓人更快上手，至少可以更容易的完成一些Demo應用。但用久了這些基於瀏覽器的視覺化工具，你就會開始懷念傳統的程式設計介面了。

Mendix的視覺化編輯器

當我們依據“人人皆可開發應用”的理念重新定義Appzio平臺的產品功能的時候，設定了相當高的指標：我們希望平臺輸出一個實用的，完全原生的移動應用，擁有應用內購、實時位置等原生功能，最重要的是，提供完全原生的使用者體驗。我們已知的是，視覺化的構建器並不足以滿足這樣的需求。

打造一個全原生的移動應用體驗需要擁有使用者體驗和最佳實踐方面的知識積澱，並深入理解業務邏輯的運作方式。這就導致我們前述的那一大坨產品功能設定顯得過於複雜，簡單講，要想做到這一點，工具的使用者必須是一個程式設計師。而如果你是一名程式設計師，程式碼開發對你來說，是解決複雜問題的最佳和最快的方式。

學習使用一個視覺化的工具，意味著你不得不學習一種新的程式設計正規化，並且這種正規化本身不可避免的存在侷限性。即使學會了工具的使用，也很快會到達收益遞減的臨界點。換句話說，在不同的選單和配置項之間繞來繞去所花的時間甚至比你直接寫程式碼來得還要長。而且最終還往往不能完成全部你想要的功能。

基於這樣的原因，我們放棄了視覺化配置介面的理念，轉而把精力花在優化基於程式碼的開發過程，並且建立一個平臺，提供更高的開發速度且並不犧牲靈活性。

二、Gartner忽略了什麼？

Gartner的“企業級高生產力aPaas”魔力象限研究報告實際上可以作為企業級低程式碼開發平臺的白皮書。長期以來，Gartner使用頗具魅力的字母組合hpaPaaS作為High-productivity application platform as a service的縮寫。報告中有一段定義如下：

企業級高生產力aPaaS市場中活躍著很多的供應商，他們致力於為企業級應用以及服務的開發和部署提供從低程式碼到無程式碼的雲端平臺。

十分有趣的是，在這一報告中，Gartner對於終端使用者的體驗惜墨如金。報告中所提及的多數平臺工具不過是提供了一個基於PhoneGap（被收購後更名為Cordova）、JavaScript或者Web View的美化的Web打包器。我想，這也是在這些工具中少有“消費者導向應用”的主要原因。因為他們根本不在意這一點。

移動應用的個人使用者和企業使用者始終在每日使用的原生應用間比較著使用者體驗的差異。像是載入時間的長短，介面是否時尚，充滿創造力的原生使用者介面是最基本的要求，但這些要求往往超越了多數低程式碼平臺的能力。

三、使用低程式碼平臺來實現

一個定製化的使用者體驗的真正代價

說說為什麼PhoneGap這類工具大勢已去。如果你想快速的把一堆東西攢在一起，他們是可以滿足要求的，但如果需要更復雜的使用者體驗，你實際上最好以原生的程式碼開發來進行實現。或者也可以藉助這樣的平臺來實現，前提是能夠提供原生的開發體驗以及豐富的自定義功能。

在使用PhoneGap的時候，你不僅需要與JavaScript打交道，還需要與另外兩種解釋性語言HTML和CSS打交道。

而且，以這種方式建立的應用，大體上就是基於WebView的機制嵌在應用中的一個網頁。這將帶來如下的缺陷：

• 效能問題

• 缺少原生功能

• 高度依賴作業系統

• JS引擎的異構性

• 多屏適配問題

• 多執行緒問題

• 同步方面的問題

還有一個流行的替代方案，是使用JS渲染引擎。但這種方式的缺陷在於跨系統多版本和多屏適配的體驗一致性。實際上，此處我們還是遇到了一個收益遞減的臨界點。通常情況下，在原生應用的開發過程中，我們花時間最多解決的往往是如何在不同的螢幕尺寸下顯示相同的外觀。尤其是在需要原生級應用效能的場景。

當我們在原生程式碼/Web配置器/JS渲染之間做出選擇時，原生程式碼開發的優勢顯而易見，所以，一個好問題是：為什麼所有的低程式碼平臺都不採用原生程式碼的方式？這樣的架構決策背後有很多原因：

1、遺留系統的問題。很多低程式碼平臺已經存在了很長時間。5年以前，移動開發領域的跨平臺框架與其後數年的原生程式碼開發方式水平相當，然而形勢已經發生了逆轉，PhoneGap已經慢慢被時代所拋棄。ReactNative在當下炙手可熱並且前景廣闊，但就我所知，還沒有企業級平臺基於ReactNative來構建其移動應用。

2、工程師的技能。使用低程式碼平臺來進行工作的工程師大多來自Web開發和後端開發。PhoneGap對於Web開發者來說是一個很自然的工具。而使用原生程式碼來構建一個平臺需要完全不同的技能棧。

3、對Web應用的支援。很多低程式碼平臺可以不只生成移動應用客戶端，並且可以生成Web應用或者一個改良的Web應用。採用這樣的方法，以打包器的方式來解決移動應用開發的問題成為最佳實踐。事實上就是這樣。如果我們自己生成可以在原生的iOS系統和安卓系統上提供一致功能的應用，需要付出四倍的努力。

然而，時至今日，原生的移動應用遠比以往更加強大。我相信，一些低程式碼平臺的供應商應該重新審視他們的架構並摒棄PhoneGap。

四、好的低程式碼平臺是什麼樣子？

根據操作環境的不同，評價移動應用開發工具的維度並不相同。為了簡化起見，我製作了一張圖表來描述低程式碼平臺所需要具備的一些關鍵特性。也許並不完備，但至少可以在你面臨一些關鍵決斷時提供一些決策參考。

圖片由EAWorld編譯

五、如何加速移動開發？

為了理解低程式碼平臺的價值，最好的方式就是審視一下如何加速移動開發。我將對這個話題做一些擴充套件，把傳統的原生開發納入討論。

1、如何加速傳統的原生移動應用開發？使用提供了第三方SDK和現成的程式碼模組的框架實現功能擴充套件。

2、如何加速跨平臺的移動應用開發？使用同時支援iOS和安卓系統的客戶端程式碼庫，使用現成的包和模組以及第三方SDK擴充套件應用功能。

3、如何加速移動應用的後端開發？選擇恰當的BaaS（backend as a service）供應商和框架，謹慎的選擇程式語言，建立從模型直接生成API的自動化方式，使用不同的模組和元件來擴充套件功能。

4、如何加速移動開發的規劃過程？主要得益於如Invision一樣的視覺化的原型工具，來建立可實際點選的原型，以及使用提供現成使用者介面的UI工具。

5、使用低程式碼平臺來加速移動開發。需要綜合使用多種方式，包括使用模板、現成的模組、自動化的程式碼生成機制、配置化程式設計、自動化的雲端部署、自動化測試、更便捷的開發者協作 、緊耦合的後端和前端開發過程等。

無論使用哪一種方式來加速移動開發，都存在著權衡。比如，如果使用現成的模組，平臺是否提供了豐富的配置和定製化功能來滿足需要？如果後端使用了無伺服器架構，在需要實現更復雜的業務邏輯的場景之下，是否會存在侷限性？

六、開發者體驗

當今世界，作為僱主，在全球範圍內都面臨著對開發者的激烈競爭。如果你的開發者不喜歡你選擇的平臺，這就成為一個問題。無論選擇哪一個平臺，都存在著難以評估的學習曲線。因此，更易上手的平臺將在競爭中有更大的優勢。開發者是否能夠在平臺上快樂的工作，將顯著的影響你從平臺中所獲得的收益。

聰明的開發者可以基於傳統的開發模型以一種更加敏捷的方式來開發移動應用。畢竟傳統移動開發大多遵循瀑布式的開發模式。低程式碼平臺可以很好的做為敏捷開發工具來使用。

有一個維度可能在評估體系中看來無關緊要，但卻對開發者體驗產生著顯著的影響，即，如何在裝置上預覽應用程式的變更。對於預覽，有三種不同的層次：

1、重新構建：使用Xcode或者Android Studio來進行預覽，需要重新構建整個移動應用。這意味著每次變更都需要花費一些時間來看到變更的結果。同時，需要開發者在裝置上安裝了Xcode或者Android Studio並且配置正確。

2、熱過載：仍舊需要重新載入整個應用，但至少不需要在裝置上安裝什麼東西，而且也不會有程式碼編譯的過程。

3、實時編輯：儲存變更 ，重新整理螢幕，就可以預覽變更的效果。

為了更好的闡述從開發者視角看來的不同，下面我給出了兩個簡短的動態圖片，來體現一個簡單的文字變更是如何在裝置上進行預覽的。

熱過載(用時2分鐘)

開啟連結http://t.cn/EJtrmtJ檢視動圖

實時編輯(用時11秒)

開啟連結http://t.cn/EJtFzYW檢視動圖

七、當價格成為阻礙

如果你為世界財富500強工作，通常可以認為公司不存在錢不夠花的煩惱。但在為移動應用開發申請預算時，情況又不盡相同。無論對於哪種規模的企業來說，花費都必須與預期的回報相適應。

許可證的花費，尤其是應用存在許多使用者的的情況下，是很昂貴的。低程式碼平臺的供應商通常按席位、開發者、開發例項來進行收費。很難評估最終所付的價格（這還不包括二次開發的費用）。你的業務收益和時間成本的節約需要與價格相一致。

並且，通常來說，平臺越是具有專業性，對於新的使用者越是需要花費更長的時間去熟悉。你需要為此做出時間規劃，畢竟想找到熟悉平臺的現成的開發者基本上是個不可能的任務。

八、檢查表

在為你的移動應用專案尋找潛在的低程式碼開發平臺的時候，下面這個列表可供參考。嘗試首先按照業務需要回答問題，然後再看一下所選擇的平臺是否可以滿足要求，這樣將有利於比較候選者的差異。

1、使用者體驗有多重要？是否僅應用於小團隊使用者，並且可以接受更長的載入時間和不那麼時尚的使用者介面？是否需要將應用釋出於AppStore和PlayStore？是否需要開發消費者導向的應用？

2、哪些開發者將在這個專案中工作？是否是你自有的團隊？他們此前熟悉哪些技術棧？對於你所準備選擇的平臺，他們的態度是激動的、擔心的還是消極的？如果你完全依賴於外部團隊，平臺的選擇變得不那麼重要，而讓你的需求得以滿足反而是決定因素。

3、是否同時需要Web應用版本的移動應用？

4、包含開發成本在內的總擁有成本如何？

5、你是否需要在本地還是雲端的環境運營這些移動應用？對這一問題的回答可能會淘汰很多低程式碼平臺或者是略微提升平臺的使用成本。如果計劃將應用基於雲端運營，是否有哪些安全考量？

6、基於待選擇的低程式碼平臺，是否存在示例的應用，與你所要開發的移動應用的質量和功能需求大體近似？

7、團隊的開發過程是基於瀑布式還是敏捷式的開發模式？如果是基於敏捷的開發，平臺在多大程度上滿足這樣的場景？是否在每一次功能更新時，使用者都需要重新下載新版本的應用，還是說，你可以將更新推送給使用者而不需要更新客戶端的二進位制檔案？

8、當專案中存在多個開發者協作開發的場景時，如何對開發過程進行組織？

9、你希望平臺的供應商提供哪些支援？平臺對於新的使用者上手難度如何？

九、最後的思考

低程式碼或者無程式碼方法，對於移動應用開發來說是一條捷徑，前提是平臺可以滿足你的期待，並且提供足夠的與你的需求相一致的功能特性。對於熟悉平臺的開發者來說，時間成本的節省相對於傳統的移動應用開發來說是數量級的提升。

如果你對所需要開發的專案已經有了大致的構想，我的建議是你去找到潛在的平臺供應商並獲得一個反饋的列表，列表中應該逐項列出對於你需求規格的滿足程度。更進一步，如果你已經設計好了UI介面，這一反饋列表將幫助你找到潛在的問題。

如果你已經為移動應用專案選定了低程式碼平臺，最好從介面設計階段開始就明確平臺的功能邊界和侷限性。在某些情況下，克服平臺的侷限性來滿足設計師所設計的絢爛的UI介面的需要，甚至比採用傳統開發方式所需要的花費更多。

最後，並且特別重要的是，找到基於低程式碼平臺的示例應用。只要看到現成的功能和使用者體驗，則對於你的應用來說就是可實現的。如果找不到這樣的示例，請謹慎從事並且在簽約前獲取一些額外的保證。

關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562043/viewspace-2639611/，如需轉載，請註明出處，否則將追究法律責任。