鴻蒙OS 4.0公測機型公布：甚至連nova6都支持
華為全新的HarmonyOS 4.0操作系統將于今天下午正式登場，官方在發布會之前也已經正式給出了可升級的機型產品，這意味著這些機型會率先支持升級享用。這次的HarmonyOS 4.0支持
近年來，“低代碼”這一概念在資本市場上愈發火熱，各種低代碼平臺項目也紛紛上馬。
然而，此類平臺的設計者與維護者們，或早或晚，終將會面對“低代碼”與生俱來的一組底層矛盾，而是否能合理地處理這組矛盾，最終決定了此平臺的發展前景。
我們團隊正在維護一套基于DSL（領域特定語言）的表單管理平臺。該平臺由客戶方團隊自建，其中包含了前端UI、數據管理、表單規則管理等模塊。設計目標是：讓業務人員以書寫DSL的方式定義表單模板，此后可以直接基于模板生成UI并管理表單數據，從而達到低代碼甚至零代碼創建表單的效果。
該平臺自建立以來，已經支持了數百個大型表單的成功上線，支持了公司業務的快速成長。
然而隨著業務的持續發展，該平臺的疲態也日益凸顯：
以上案例，生動展現了一款低代碼平臺的典型生命周期：
而此類平臺之所以會有如此表現，根本癥結在于其發展受到了“低代碼”天然自帶的一組矛盾的掣肘，該矛盾可以用不可能三角的形式加以描述：
如圖，該三角的三個頂點分別代表了低代碼平臺的三個核心設計目標：
而這三個目標形成了如此一個三角形的結構，意味著在同一低代碼平臺上，他們永遠不可能同時被滿足：
a.若一平臺在易于使用的同時功能強大，則必然擁有較高的系統復雜度。
其中，系統復雜度與維護成本成正比，與系統性能成反比。也即，較高的系統復雜度最終會導致平臺擁有較高的維護成本以及較低的系統性能。
例子：人工智能編程。用戶只需使用自然語言描述需求（易于使用），系統就能生成代碼（功能強大），但該技術至今仍未完全成熟（高系統復雜度）。
b.若一平臺易于使用的同時保持低系統復雜度，則必然功能受限
例子：Scratch少兒編程。使用圖形化界面編程（易于使用），指令只需經過簡單翻譯即可執行（低系統復雜度），但功能只能滿足教學目的（功能受限）。
c.若一平臺功能強大的同時保持低系統復雜度，則必然擁有較高的使用成本
例子：通用編程語言。圖靈完備理論上可以實現任何功能（功能強大），編譯或解釋為機器指令執行（低系統復雜度），但存在較高的專業門檻（高使用成本）。
正所謂：
軟件工程就是trade-off的藝術
對于低代碼平臺上述的三個目標來說，“我全都要”的結果只能是“全都得不到”，最終勢必會陷入到按下葫蘆浮起瓢的窘境當中。所以，對于任何一款低代碼平臺的設計者來說，做出合理的trade-off都將是所有工作中的重中之重。
那么如何trade-off來破解“不可能三角”呢？需要基于以下2個事實：
通常，一款低代碼產品的宣傳會向我們許諾至少以下兩個承諾：
對應到我們的三個核心設計目標上去，很容易看出：
與之相對的，雖然低代碼平臺也會將“功能強大”作為其一大賣點，但又往往會特意強調其功能具有特定的應用范圍。常見的有針對企業工作流、報表、ERP等場景設計的低代碼平臺。
綜上，三個設計目標可以被簡短的總結為：
我們可以將一款低代碼平臺所面向的問題域，劃分為封閉問題域與開放問題域兩類，它們之間的區別在于問題空間是否存在確定的邊界。
例如說對于一個To C的低代碼開發平臺，在UI交互方面，它的問題域就是開放的。
因為終端用戶的交互需求無法窮盡：同樣是展示數據，既可以用文本、表格，亦可以用圖表、3D模型，甚至可以用AR、VR……
也因此，平臺不可能提供一個滿足100%應用場景的UI構建方案。
所以，我們可以化用“二八定律”對這個問題做個略微粗暴的總結（當然這里的2與8都是虛數）：
對于一開放問題域，任何單一方案至多只能滿足其80%場景。
注：筆者非常喜歡React新版文檔中所使用的“逃生艙”（Escape Hatches）這一比喻，因此在此處也借鑒一番。但需要注意的是，這篇文章中的逃生艙與React中的概念并不完全相同，還需讀者自行鑒別。
聊到這里，其實我們的最佳策略已經不言而喻了。如上所述，已知：
顯而易見，對于平臺設計者來說，他們應該將絕大部分精力投入到服務好平臺最擅長的那80%業務場景當中去，竭盡全力在優勢領域中做到盡善盡美。
至于剩余的20%邊緣場景，在某些時候，直接放棄或許也是一種可以接受的選項。
當然，對于那些富有野心的平臺來說，這恐怕難以接受。那么此時的最佳策略便是本節的標題所指：在平臺設計之初，設計者就應該考慮到為將來某些高級使用者提供一個完善的“逃生艙”機制。
這里的“逃生艙”指的是一種向平臺使用者暴露底層能力的機制。它可以是一組低級API，也可以是一批可供二開擴展的集成點，甚至也可以是一套進行定制開發的解決方案。總之，為了滿足從過去至將來100%的業務需求，平臺必須允許用戶在有必要的時候進行“抽象降級”，有機會乘坐逃生艙從平臺規定的條條框框之中逃離。
這樣的設計思想其實在軟件工程領域相當常見，譬如plugin API之于webpack、unsafe之于rust、指針之于C#等等……只不過由于低代碼平臺本身業務的復雜性，設計出一套優雅的“逃生艙”機制并不容易，因此設計者在平臺設計的早期就必須考慮這個問題。
當前我們團隊遇到的問題，就是由于平臺早期缺乏良好的“逃生艙”設計，導致了面對超出平臺能力的新需求時無從下手：
可以用一個詞來形容——積重難返。
如上，筆者將本人在低代碼平臺上遇到的困難與思考進行了些淺顯總結，斗膽試圖借此來發現一點架構設計的普遍規律，慚愧慚愧……
文章最后，再試著簡單總結一些由本文觀點得出的建議。
對于使用者來說，最大的啟示是在技術選型的階段最好留個心眼，切勿輕信了平臺銷售對其產品功能的吹噓。尤其是如果有人膽敢宣揚他的平臺無所不能，今天開發明天上線后天解雇程序員云云，那你可得小心了。
正如前文所言，任何低代碼產品的出發點都是為了降低用戶的使用成本，所以如果一個平臺即承諾了易用性，又承諾了功能性，那么代價是什么？
經驗來說，反倒是專注于一個特定領域的平臺供應商往往更加務實，也有更大概率做出更成熟的產品。
對于設計者來說，最大的挑戰是在如上不可能三角中取得平衡。對于不同類型的系統設計取向自然也不同，但對于低代碼平臺這一品類來說，大部分情況下，易用性和系統復雜度還是比功能性重要的多。
因此如果你的產品也具有類似的價值取向的話，那么作為架構設計者，盡早地規劃“逃生艙”的設計和落實才是負責任的做法。
本文鏈接：http://www.www897cc.com/showinfo-26-67340-0.html低代碼平臺中的“不可能三角”
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Python的調試工具和技巧
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號