近幾年低程式碼著實火了一把，各種平臺層出不窮，網上大把的帖子說著上了低程式碼半數人都要被辭退了（自媒體販賣焦慮太溜了）。
有幸在前端同學的極力脅迫，哦不，推薦下，也在業務中使用低程式碼平臺搭建了幾個頁面。總體來看，差強人意。
“預設”悖論
“預設”是德國哲學家、現代邏輯奠基人弗雷格於1892年提出的概念，指的是說話者在說出某個話語或句子時所做的假設，即說話者為保證句子或語段的合適性而必須滿足的前提。
“預設”悖論並不是低程式碼獨有的，所有的架構設計都會遇到這個問題。無論是分層架構，還是六邊形架構，都在試圖用“預設”的概念、模型、擴充套件來抽象問題，從而降低複雜問題的邏輯難度。
比如我們描述一個商品，基本的資訊包括標題、主圖、價格、庫存、詳情描述，複雜一些的會有 SKU、主圖影片、端圖、運費等。當我們基於這樣的商品資訊去建模的時候，很容易把商品模型拆解為商品域、營銷域、履約域等多個子域，也可能劃分為文字、富文字、多媒體、價格、庫存、SKU、擴充套件資訊等多個型別。
無論用什麼方式去建模，都無法迴避的問題是“要先有業務需求，然後才能沉澱模型，再去用模型賦能業務”。這樣就會有“預設”悖論，到底是先設計模型還是先承接業務。如果先設計模型，會不清楚業務的發展方向，模型大機率短期合適長期成為瓶頸。如果先承接業務，很可能無法及時沉澱模型，業務程式碼屎上雕花，以後也不會有人關心了。所以大部分系統都不可避免，要一直重構、多次重構。
這很像人的語言迭代，弗雷格提出的“預設”就是人這個群體自然演化出的語言能力。戰國時期“美人”可以指代“國君”，21 世紀大家都會理解成“美麗的女人”。26 個字母曾經與漢語毫無關係，現在卻變成拼音成為漢語的重要基石。重構，本質上就是重新認識業務、重新理解業務、重新設計模型，實現“預設”模型的迭代更新。重構可以是區域性小重構，也可以是全域性的大重構，取決於 ROI。
低程式碼平臺現狀
低程式碼平臺通常的宣傳都是圍繞沉澱好的模型、元件來降低搭建成本，實現頁面快速上線。基本都有以下功能模組：頁面搭建、資料邏輯、資料模型、線上部署和管理系統。低程式碼的效率提升，本質上就是基於“預設”實現複用。低程式碼主要有兩種：介面驅動，表單/資料模型驅動。
介面驅動就是預設頁面元件以及前後端統一實現，使用者透過拖拽元件方式視覺化搭建介面，然後配置頁面的互動邏輯，比如頁面的跳轉、資料獲取。複雜一些的頁面功能，比如涉及元件聯動、元件非同步拉資料，低程式碼平臺也只能實現少量確定性的聯動，複雜互動還是需要讓使用者手寫程式碼實現。
表單/資料模型驅動圍繞資料結構來定義整個應用的形態和流程，核心在於搭建表單和定義資料，可以用於 CRM、ERP 等管理系統做二次開發。
與其說低程式碼是為程式設計師提效，不如說為程式設計師提供一個“針對特定場景”的“二次開發環境”，核心還是基於複用來寫程式碼。學習一個低程式碼平臺的使用，本質上和學習一門新語言區別不大，學習成本、經驗積累都需要考慮。
而現在各個低程式碼平臺看起來並沒有統一的技術體系，遷移到低程式碼平臺和在平臺之間遷移成本都非常高。程式設計師要想職業生涯發展順利，需要持續積累和複用專業知識、專業技能，目前的低程式碼平臺對程式設計師而言完全站在了對立面，不利於程式設計師的長期發展。核心程式設計師要麼專注於解決業務領域核心問題，要麼參與低程式碼平臺的底層建設。基於低程式碼平臺的二次開發，建議交給外包去完成。
另外，基於低程式碼平臺進行二次開發，必然有確定性的業務場景，這樣的業務場景能否迴流到平臺促進平臺模型的進一步迭代，在業務發展和平臺能力提升中形成良性迴圈，不只是低程式碼平臺遇到的問題，更是每一個架構設計者需要深入思考的問題。
