目前低代碼技術正處在風口，低代碼平臺產品不斷涌現，亂花漸欲迷人眼。作為軟件公司或企業IT部門的負責人，在做低代碼平臺選型時需要關注哪些方面，才能順利“上車”，讓低代碼為自己的團隊賦能?

　　除了產品功能是否滿足當前項目需求，價格是否在預算范圍內之外，以下幾個問題的答案同樣重要。

　　Q1：是否支持協同開發和版本管理?

　　項目開發過程中，我們難免遇到客戶反饋某個新開發的功能沒有用，但是過一段時間以后反悔，又希望加回來的情況。這是軟件開發的常態。為了解決這一問題，傳統的軟件開發團隊都會引入版本管理機制，低代碼也不例外。面對頻繁的需求變更、棘手的問題排查，低代碼平臺的版本管理，特定模塊回滾等操作的價值就會體現出來。

　　此外，為了加速項目的交付速度，我們通常需要集中更多人員進行同步開發。只有具備協同開發能力的低代碼平臺才能讓這一過程變得可管理，避免混亂。

　　所以，不論項目規模大小，選擇一款兼容主流代碼庫、支持敏捷開發的低代碼平臺都會對開發工作有所幫助。

(Git：一款主流的版本控制系統，圖片來自Git官網)

　　Q2：是否支持自由設計數據庫結構?

　　數據庫是所有企業管理軟件的“地基”。為了后續功能的開發更加方便，擴展性更強，維護性更佳，良好的數據庫設計至關重要。這個點是企業軟件自身的屬性決定的，無論是低代碼還是傳統的純代碼，都不會有變化。

　　事實上，軟件開發技術發展到今天，數據庫設計的最佳實踐早已被總結成了久經考驗的數據庫設計范式。低代碼開發平臺是否能夠對開發者開放數據庫結構的自由設計能力，能夠讓開發者基于數據庫設計范式不斷優化數據結構，直接決定了該平臺的專業性。如果你需要開發高標準的核心業務應用，或者對應用后期的可擴展性、可維護性有要求，那么數據庫設計能力在評估過程中至關重要。

(滿足設計范式要求的數據庫結構示意圖，圖片來自網絡)

　　Q3：能否靈活自由地設計顯示頁面?

　　不同的企業、不同的用戶都的使用習慣和審美風格具有差異化。即便面對同樣的業務需求，客戶對軟件的頁面呈現和交互也會有完全不同的要求。舉例來說，客戶A比較喜歡在頁面的右上角尋找提交按鈕;客戶B可能習慣于提交按鈕出現在頁面的正下方，客戶C則對提交按鈕放到頁面的右下角的設計更加青睞。于是我們需要為不同的客戶做不同的頁面布局，以縮減使用培訓成本，提升用戶的滿意度。

　　類似的問題和解決方案，我相信您在多年的軟件交付經驗中已有體會。當然這里舉例可能是冰山一角，客戶對頁面布局和樣式風格的差異化要求遠不止于此。如果您認可滿足用戶的使用習慣，適配公司的設計風格的重要性，那么請盡量選擇支持靈活自由設計顯示頁面的低代碼平臺，以確保我們在項目開發和交付時不會陷入被動。

(使用同款低代碼平臺開發不同樣式的表格，圖片來自活字格官網)

　　Q4：能否支持前后端分離的系統架構，后端復雜邏輯如何解決?

　　正如前面所說，軟件行業發展了多年，沉淀出了很多最佳實踐。與數據庫設計范式類似的，還有前后端分離，數據庫讀寫分離等等。上一點重點講了前端，這里則要將目光轉向后端。

　　在前后端分離架構的支撐下，不論是軟件公司還是企業IT團隊，在發展的過程中都會積累出自己的“核心數字資產”，這些資產往往表現在一些后臺業務復雜邏輯計算方法(有的可能還會包含一些用于調優的“魔法數字”)。后臺的邏輯復雜度高、技術積累價值大，相對較為穩定。如何用低代碼實現后端復雜的業務邏輯，持續積累“核心數字資產”，是低代碼平臺必須解決的問題。在做技術評估時，千萬別忘了這些運行在后臺，沒有任何界面的邏輯，因為這些才是系統和開發團隊的核心競爭力。

(前后端分離，圖片來自網絡)

　　Q5：是否有全系統模塊的解決方案?

　　在實際項目交付過程中，如果我們僅可以滿足99%的需求，另外1%的需求滿足不了，真實用戶大概率是不會買單的。因此，在評估低代碼產品的時候，我們一定要保證該平臺可以支撐所有系統模塊類型的開發，至少也要有足夠的擴展性，可以確保使用純代碼開發出的模塊能夠與低代碼模塊進行無縫集成。

　　考慮到巨大的生產力差距，低代碼平臺覆蓋的模塊越多，整個項目的開發效率也會越高。那么，企業軟件通常會涉及哪些類型的模塊呢?我將其中最常見的列舉如下：

　　多終端頁面

　　可精確打印的報表

　　圖表構成的可視化大屏

　　自動化任務

　　Q6：如何保證開發出應用的系統安全性?

　　安全性對任何一個系統都至關重要。使用低代碼平臺所開發出的應用中,絕大多數邏輯都是低代碼開發者自行構建的，而不是出自低代碼平臺廠商。所以，我們很難通過平臺的安全性報告來簡單評判開發出應用的安全性，這就相當于沒人關心Visual Studio和eclipse的安全報告一樣。

　　這并不意味著我們不需要關心低代碼平臺自身的安全性。那么，我們該如何看待低代碼平臺的安全性，如何評估使用該平臺開發出應用的安全性?以下幾點值得參考：

1. 該低代碼平臺是否有金融或者銀行業的客戶?這些行業一般對安全性要求比較高，他們能用一般行業肯定可以使用
2. 在評估階段，您可以基于該平臺創建一個demo程序，并對這個demo做安全性檢查，下面是一些安全檢查的工具或者產品：ZAP – OWASP(免費)、SonarQube – SonarWorks(收費)、Burp Suite – PortSwigger(收費)、AppScan - IBM(收費)

(OWASP的ZAP檢測工具，圖片來自ZAP官網)

　　Q7：平臺是否獨立，能夠不依賴其他第三方的產品?

　　這個點聽上去有些奇怪，為什么會有低代碼平臺依賴特定的第三方產品?這就與國內低代碼所處的發展階段有關了。我來舉兩個例子：

• 有的產品說他是Excel的設計模式，但是其實他們所有的頁面設計都是在Excel中，甚至訪問時也是在Excel中訪問，聽起來沒什么大問題，但是這其中有一個非常重要的點，Excel經常會更新Excel2008，Excel2010，Excel2016，….，這樣每一次Excel升級，您都需要重新購買一次他們這個平臺了;
• 有的低代碼產品說自己是B/S架構，但是你必須安裝他們特定的瀏覽器才能訪問，這跟C/S架構的系統有什么區別?

　　為了確保后面的開發和部署過程可控，我推薦您優先選擇獨立的低代碼平臺。如果因為其他原因需要選擇一款依賴特定的第三方軟件，如數據庫、Web服務器等的低代碼平臺，則需要將這些依賴的軟件納入部署清單和操作手冊。

　　Q8：是否會產生新的“數據孤島”?

　　數據孤島這個概念從提出到現在，一直是企業信息化行業最希望解決的問題。作為新一代的軟件開發技術，我們不需要使用低代碼開發出來的應用成為新的數據孤島。所以，不論是連接現有的數據庫，還是支持通過Web API與其他軟件互通，低代碼都必須具有開放性，不能產生新的數據庫孤島。

　　跟進一步，如果該低代碼平臺可以幫助我們解決企業的數據孤島問題，將多個系統打通，通過整合多源數據實現協同增效，那就更是一個加分項目了。

(數據孤島現象，圖片來自網絡)

　　Q9：該平臺的產品生態建設如何，是否有激勵機制?

　　聚沙成塔，如果一個低代碼產品選擇孤軍奮戰，沒有生態，大概率是不能長久的。對于低代碼開發平臺，生態的價值主要體現在以下兩個方面：

• 模板：模板也叫開發成果，是指開發者使用低代碼平臺為特定行業或場景構建的“半成品”系統。基于半成品進行二次開發，可以進一步提升企業應用的構建速度。成熟的低代碼平臺通常具備模板市場，通過商務和技術手段，鼓勵開發者將自己使用該平臺開發出的應用放在市場中分享或銷售，打造“人人為我，我為人人”的正向循環。
• 插件：低代碼平臺通常會開放插件機制，以吸引更多開發者封裝自己開發的“模塊”。插件和平臺在一起運行，讓低代碼平臺的應用場景更豐富。事實上，一家平臺廠商的技術能力再強，也不能全部滿足客戶的所有需求。只有開放插件機制，建立插件付費環境，才能讓廣大的開發者都參于進來，共同打造更強大的平臺。

　　低代碼平臺生態的關鍵在于如何建立長效激勵機制，實現正向循環，通俗的理解就是讓生態上游的開發者可以通過付費機制獲得合理的回報。我們相信，只有提供長效激勵機制的平臺生態才能持久。

(多種連接器插件，圖片來自Power Apps官網)

　　小結

　　在低代碼平臺的井噴期，使用者更應該擦亮眼睛，選擇合適的平臺產品，充分利用新技術帶來的新價值、新動能。上面九個問題，就是我為您整理的低代碼技術選型思路，希望能夠幫正在評估低代碼平臺的軟件公司和企業IT部門少走彎路，抓住時代潮流，開啟低代碼之旅。