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

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

Q1：是否支持協(xié)同開發(fā)和版本管理？

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

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

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

（Git：一款主流的版本控制系統(tǒng)，圖片來自Git官網(wǎng)）

Q2：是否支持自由設計數(shù)據(jù)庫結(jié)構(gòu)？

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

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

（滿足設計范式要求的數(shù)據(jù)庫結(jié)構(gòu)示意圖，圖片來自網(wǎng)絡）

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

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

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

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

Q4：能否支持前后端分離的系統(tǒng)架構(gòu)，后端復雜邏輯如何解決？

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

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

（前后端分離，圖片來自網(wǎng)絡）

Q5：是否有全系統(tǒng)模塊的解決方案？

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

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

• 多終端頁面
• 可精確打印的報表
• 圖表構(gòu)成的可視化大屏
• 自動化任務

Q6：如何保證開發(fā)出應用的系統(tǒng)安全性？

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

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

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

（OWASP的ZAP檢測工具，圖片來自ZAP官網(wǎng)）

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

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

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

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

Q8：是否會產(chǎn)生新的“數(shù)據(jù)孤島”？

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

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

（數(shù)據(jù)孤島現(xiàn)象，圖片來自網(wǎng)絡）

Q9：該平臺的產(chǎn)品生態(tài)建設如何，是否有激勵機制？

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

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

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

（多種連接器插件，圖片來自Power Apps官網(wǎng)）

小結(jié)

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