目前低代碼技術正處在風口，低代碼平台産品不斷湧現，亂花漸欲迷人眼。作為軟體公司或企業IT部門的負責人，在做低代碼平台選型時需要關注哪些方面，才能順利“上車”，讓低代碼為自己的團隊賦能？
除了産品功能是否滿足目前項目需求，價格是否在預算範圍内之外，以下幾個問題的答案同樣重要。
Q1：是否支援協同開發和版本管理？
項目開發過程中，我們難免遇到客戶回報某個新開發的功能沒有用，但是過一段時間以後反悔，又希望加回來的情況。這是軟體開發的常态。為了解決這一問題，傳統的軟體開發團隊都會引入版本管理機制，低代碼也不例外。面對頻繁的需求變更、棘手的問題排查，低代碼平台的版本管理，特定子產品復原等操作的價值就會展現出來。
此外，為了加速項目的傳遞速度，我們通常需要集中更多人員進行同步開發。隻有具備協同開發能力的低代碼平台才能讓這一過程變得可管理，避免混亂。
是以，不論項目規模大小，選擇一款相容主流代碼庫、支援靈活開發的低代碼平台都會對開發工作有所幫助。
Q2：是否支援自由設計資料庫結構？
資料庫是所有企業管理軟體的“地基”。為了後續功能的開發更加友善，擴充性更強，維護性更佳，良好的資料庫設計至關重要。這個點是企業軟體自身的屬性決定的，無論是低代碼還是傳統的純代碼，都不會有變化。
事實上，軟體開發技術發展到今天，資料庫設計的最佳實踐早已被總結成了久經考驗的資料庫設計範式。低代碼開發平台是否能夠對開發者開放資料庫結構的自由設計能力，能夠讓開發者基于資料庫設計範式不斷優化資料結構，直接決定了該平台的專業性。如果你需要開發高标準的核心業務應用，或者對應用後期的可擴充性、可維護性有要求，那麼資料庫設計能力在評估過程中至關重要。
Q3：能否靈活自由設計顯示頁面？
不同的企業、不同的使用者都有着差異化的使用習慣和審美風格。即便面對同樣的業務需求，客戶對軟體的頁面呈現和互動也會有完全不同的要求。舉例來說，客戶A比較喜歡在頁面的右上角尋找送出按鈕；客戶B可能習慣于送出按鈕出現在頁面的正下方，客戶C則對送出按鈕放到頁面的右下角的設計更加青睐。于是我們需要為不同的客戶做不同的頁面布局，以縮減使用教育訓練成本，提升使用者的滿意度。
類似的問題和解決方案，我相信您在多年的軟體傳遞經驗中已有體會。當然這裡舉例可能是冰山一角，客戶對頁面布局和樣式風格的差異化要求遠不止于此。如果您認可滿足使用者的使用習慣，适配公司的設計風格的重要性，那麼請盡量選擇支援靈活自由設計顯示頁面的低代碼平台，以確定我們在項目開發和傳遞時不會陷入被動。
Q4：能否支援前後端分離的系統架構，後端複雜邏輯如何解決？
正如前面所說，軟體行業發展了多年，沉澱出了很多最佳實踐。與資料庫設計範式類似的，還有前後端分離，資料庫讀寫分離等等。上一點重點講了前端，這裡則要将目光轉向後端。
在前後端分離架構的支撐下，不論是軟體公司還是企業IT團隊，在發展的過程中都會積累出自己的“核心數字資産”，這些資産往往表現在一些背景業務複雜邏輯計算方法（有的可能還會包含一些用于調優的“魔法數字”）。背景的邏輯複雜度高、技術積累價值大，相對較為穩定。如何用低代碼實作後端複雜的業務邏輯，持續積累“核心數字資産”，是低代碼平台必須解決的問題。在做技術評估時，千萬别忘了這些運作在背景，沒有任何界面的邏輯，因為這些才是系統和開發團隊的核心競争力。
Q5：是否有全系統子產品的解決方案？
在實際項目傳遞過程中，如果我們僅可以滿足99%的需求，另外1%的需求滿足不了，真實使用者大機率是不會買單的。是以，在評估低代碼産品的時候，我們一定要保證該平台可以支撐所有系統子產品類型的開發，至少也要有足夠的擴充性，可以確定使用純代碼開發出的子產品能夠與低代碼子產品進行無縫內建。
考慮到巨大的生産力差距，低代碼平台覆寫的子產品越多，整個項目的開發效率也會越高。那麼，企業軟體通常會涉及哪些類型的子產品呢？我将其中最常見的列舉如下：
- 多終端頁面
- 可精确列印的報表
- 圖表構成的可視化大屏
- 自動化任務
Q6：如何保證開發出應用的系統安全性？
安全性對任何一個系統都至關重要。使用低代碼平台所開發出的應用中,絕大多數邏輯都是低代碼開發者自行建構的，而不是出自低代碼平台廠商。是以，我們很難通過平台的安全性報告來簡單評判開發出應用的安全性，這就相當于沒人關心Visual Studio和eclipse的安全報告一樣。
這并不意味着我們不需要關心低代碼平台自身的安全性。那麼，我們該如何看待低代碼平台的安全性，如何評估使用該平台開發出應用的安全性？以下幾點值得參考：
- 該低代碼平台是否有金融或者銀行業的客戶？這些行業一般對安全性要求比較高，他們能用一般行業肯定可以使用
- 在評估階段，您可以基于該平台建立一個demo程式，并對這個demo做安全性檢查，下面是一些安全檢查的工具或者産品：ZAP – OWASP（免費）、SonarQube – SonarWorks（收費）、Burp Suite – PortSwigger（收費）、AppScan - IBM（收費）
Q7：平台是否獨立，能夠不依賴其他第三方的産品?
這個點聽上去有些奇怪，為什麼會有低代碼平台依賴特定的第三方産品？這就與國内低代碼所處的發展階段有關了。我來舉兩個例子：
- 有的産品說他是Excel的設計模式，但是其實他們所有的頁面設計都是在Excel中，甚至通路時也是在Excel中通路，聽起來沒什麼大問題，但是這其中有一個非常重要的點，Excel經常會更新Excel2008，Excel2010，Excel2016，….，這樣每一次Excel更新，您都需要重新購買一次他們這個平台了；
- 有的低代碼産品說自己是B/S架構，但是你必須安裝他們特定的浏覽器才能通路，這跟C/S架構的系統有什麼差別？
為了確定後面的開發和部署過程可控，我推薦您優先選擇獨立的低代碼平台。如果因為其他原因需要選擇一款依賴特定的第三方軟體，如資料庫、Web伺服器等的低代碼平台，則需要将這些依賴的軟體納入部署清單和操作手冊。
Q8：是否會産生新的“資料孤島”？
資料孤島這個概念從提出到現在，一直是企業資訊化行業最希望解決的問題。作為新一代的軟體開發技術，我們不需要使用低代碼開發出來的應用成為新的資料孤島。是以，不論是連接配接現有的資料庫，還是支援通過Web API與其他軟體互通，低代碼都必須具有開放性，不能産生新的資料庫孤島。
跟進一步，如果該低代碼平台可以幫助我們解決企業的資料孤島問題，将多個系統打通，通過整合多源資料實作協同增效，那就更是一個加分項目了。
Q9：該平台的産品生态建設如何，是否有激勵機制？
聚沙成塔，如果一個低代碼産品選擇孤軍奮戰，沒有生态，大機率是不能長久的。對于低代碼開發平台，生态的價值主要展現在以下兩個方面：
- 模闆：模闆也叫開發成果，是指開發者使用低代碼平台為特定行業或場景建構的“半成品”系統。基于半成品進行二次開發，可以進一步提升企業應用的建構速度。成熟的低代碼平台通常具備模闆市場，通過商務和技術手段，鼓勵開發者将自己使用該平台開發出的應用放在市場中分享或銷售，打造“人人為我，我為人人”的正向循環。
- 插件：低代碼平台通常會開放插件機制，以吸引更多開發者封裝自己開發的“子產品”。插件和平台在一起運作，讓低代碼平台的應用場景更豐富。事實上，一家平台廠商的技術能力再強，也不能全部滿足客戶的所有需求。隻有開放插件機制，建立插件付費環境，才能讓廣大的開發者都參于進來，共同打造更強大的平台。
低代碼平台生态的關鍵在于如何建立長效激勵機制，實作正向循環，通俗的了解就是讓生态上遊的開發者可以通過付費機制獲得合理的回報。我們相信，隻有提供長效激勵機制的平台生态才能持久。
小結
在低代碼平台的井噴期，使用者更應該擦亮眼睛，選擇合适的平台産品，充分利用新技術帶來的新價值、新動能。上面九個問題，就是我為您整理的低代碼技術選型思路，希望能夠幫正在評估低代碼平台的軟體公司和企業IT部門少走彎路，抓住時代潮流，開啟低代碼之旅。