全棧平臺(tái)

• 螞蟻楊周璇：我做前端這十多年來的感悟
• 云鳳蝶可視化搭建的推導(dǎo)與實(shí)現(xiàn)
• 云鳳蝶中臺(tái)研發(fā)提效實(shí)踐
• 中臺(tái)建站的智能化探索
• 云鳳蝶如何打造媲美 sketch 的自由畫布

• 長(zhǎng)夜未央——企業(yè)級(jí)研發(fā)提效的下一階段
• 十倍效能提升——Web 基礎(chǔ)研發(fā)體系的建立
• 前端服務(wù)化——頁(yè)面搭建工具的死與生

• 如何設(shè)計(jì)阿里經(jīng)濟(jì)體都在用的搭建服務(wù)—天馬

• 積木系統(tǒng)v2@江源.pptx
• 積木系統(tǒng)，將運(yùn)營(yíng)系統(tǒng)做到極致

• 騰訊云開發(fā)低碼平臺(tái)

• 案例
• 為什么專業(yè)開發(fā)者都選擇無遠(yuǎn)

• 氚云

• 關(guān)于iVX平臺(tái)實(shí)現(xiàn)的總體技術(shù)?！镜痛a/無代碼、可視化開發(fā)語(yǔ)言】
• iVX是怎么開發(fā)出來的？0代碼開發(fā)的理論基礎(chǔ)是什么？】
• iVX和其他低代碼的開發(fā)平臺(tái)區(qū)別究竟在哪里
• ih5

• 閃電數(shù)據(jù)管理 —— 無代碼數(shù)據(jù)管理(開發(fā))系統(tǒng)
• lightning —— 基于Django的無代碼Admin及低代碼開發(fā)框架

• OpsMind 前端低代碼開發(fā)平臺(tái)--MPlatform

• 支持業(yè)務(wù)系統(tǒng)/管理系統(tǒng)、可視化大屏、3D園區(qū)低碼快速開發(fā)

支持離線部署

頁(yè)面搭建

僅包含前端部分的 low code 平臺(tái)

• 京東商城活動(dòng)頁(yè)面構(gòu)建系統(tǒng)——通天塔

• 持續(xù)迭代的電商可視化運(yùn)營(yíng)頁(yè)面生成系統(tǒng)

• 活動(dòng)運(yùn)營(yíng)自動(dòng)化平臺(tái)實(shí)踐

• 美團(tuán)外賣前端可視化界面組裝平臺(tái) —— 樂高

• 前端即服務(wù)-通向零成本開發(fā)之路

• 前端工程實(shí)踐之可視化搭建系統(tǒng)（一）

• 活動(dòng)專題系統(tǒng)搭建過程中我的一些思考

• 干貨 | 已配置4000+頁(yè)面，攜程前端組件化探索之“樂高”運(yùn)營(yíng)系統(tǒng)

• 「可視化搭建系統(tǒng)」——從設(shè)計(jì)到架構(gòu)，探索前端領(lǐng)域技術(shù)和業(yè)務(wù)價(jià)值

360 - 即視

• http://h5.dooring.cn/

店鋪裝修

非獨(dú)立頁(yè)面，依附于業(yè)務(wù)系統(tǒng)存在的頁(yè)面搭建

有贊-微頁(yè)面

• 淘寶店鋪裝修

• MegaLayout - 下一代Formily表單布局解決方案
• https://designable-antd.formilyjs.org/

• 可視化在線編輯器架構(gòu)設(shè)計(jì)

• 如何設(shè)計(jì)高擴(kuò)展的在線網(wǎng)頁(yè)制作平臺(tái)

• 【第1524期】頁(yè)面可視化搭建工具技術(shù)要點(diǎn)

• 基于 Angular 的小程序可視化編輯器 Panel-Magic 的實(shí)現(xiàn)解析

• 百度外賣如何做到前端開發(fā)配置化

• Ovine：基于 amis 補(bǔ)全了路由、權(quán)限相關(guān)的組件
• 愛速搭

• 一個(gè)簡(jiǎn)單易用的電商活動(dòng)頁(yè)面生成系統(tǒng)

• 使用 React 構(gòu)建頁(yè)面可視化搭建工具

• 實(shí)時(shí)輸出前端代碼，折騰大半年的開源項(xiàng)目 sparrow-js

Moria - Lowcode development platform

• nocobase

https://github.com/odoo/odoo

• https://github.com/imgcook/imove

辦公/管理系統(tǒng) a.k.a no-code

Notion

• https://welovenocode.com/nocodelist

聲明式編程

• "Probabilistic scripts for automating common-sense tasks" by Alexander Lew

行業(yè)綜述

工程化之低代碼體系

• LowCode平臺(tái)前端實(shí)戰(zhàn)之京東投放素材中心

技術(shù)點(diǎn)

• 可逆計(jì)算：下一代軟件構(gòu)造理論
• 從可逆計(jì)算看聲明式編程

可視化拖拽組件庫(kù)一些技術(shù)要點(diǎn)原理分析（二）

• 可視化拖拽組件庫(kù)一些技術(shù)要點(diǎn)原理分析（三）

國(guó)外

https://www.claris.com/zh/filemaker/

• FoC 聊天記錄：https://marianoguerra.github.io/future-of-coding-weekly/history/?fromDate=2017-06-13&toDate=2017-06-14&channel=general&filter=

一切改進(jìn)都是源自于人類的缺陷

How we think

• 人腦是串行的，無法有效并行思考多條線索

人腦不適合思考并行執(zhí)行的多線程

• 【單線程】把共享變量的編程模式改成事務(wù)整體提交的模式

人腦不適合思考同時(shí)呈現(xiàn)在屏幕上的多個(gè)獨(dú)立的業(yè)務(wù)流程

• 代碼是按發(fā)生時(shí)間組織的，在一起的代碼未必是邏輯上有關(guān)聯(lián)的業(yè)務(wù)流程
  • 【按業(yè)務(wù)切分文件】閱讀者應(yīng)該可以按照自己的任務(wù)目標(biāo)來跟蹤索引，而不是默認(rèn)一個(gè)按鈕點(diǎn)擊引起的處理邏輯都一定要寫在一個(gè)大文件里
• 【按變更頻率切分文件】業(yè)務(wù)變更是閱讀的首要原因，代碼應(yīng)該按照業(yè)務(wù)變更的頻率來組織。會(huì)同時(shí)變更的代碼應(yīng)該放在一起

人腦很難管理多份獨(dú)立可變的狀態(tài)，本質(zhì)上每個(gè)獨(dú)立變化的狀態(tài)就是一個(gè)獨(dú)立的線程

• 驅(qū)動(dòng)狀態(tài)數(shù)量熵增的三大因素：
  • 因?yàn)榻换ンw驗(yàn)的要求，從后端到富客戶端到3d動(dòng)畫，狀態(tài)被復(fù)制多份，越來越靠近展示層
  • 因?yàn)橛布锢淼募s束，內(nèi)存從CPU統(tǒng)一尋址，到異構(gòu)計(jì)算，CUDA，每個(gè)硬件核都有一層自己的內(nèi)存
  • 因?yàn)閿?shù)據(jù)量的增長(zhǎng)，從統(tǒng)一的OLAP從庫(kù)，到Data Lake，Data Mart，數(shù)據(jù)被復(fù)制成越來越份，流水線越來越長(zhǎng)
• 對(duì)抗?fàn)顟B(tài)數(shù)量熵增的手段：
  • 【聲明式數(shù)據(jù)聯(lián)動(dòng)】減少獨(dú)立變化的狀態(tài)，用表達(dá)式來表達(dá) derived state
• 【全局虛擬數(shù)據(jù)層】借鑒Unix的統(tǒng)一文件抽象，引入一層統(tǒng)一的虛擬數(shù)據(jù)層。盡可能把狀態(tài)轉(zhuǎn)化成 cache

人腦很難理解新增對(duì)原有行為的劇烈變化，更習(xí)慣逐層穩(wěn)定疊加。也就是人更希望“控制變量”

• css 最大的難度在于不正交，新增一條對(duì)規(guī)則會(huì)引起意想不到的效果
  • 【局部化布局】swiftui 的 HStack/VStack/ZStack 布局規(guī)則數(shù)量少，每條規(guī)則作用都是局部的穩(wěn)定的疊加
• 性能優(yōu)化往往需要破壞局部性，因?yàn)榫植康淖灾稳菀滓鹬貜?fù)勞動(dòng)
  • 【局部化IO】系統(tǒng)自動(dòng)實(shí)現(xiàn) I/O 的批量等可以自動(dòng)化做的全局優(yōu)化
• 【局部化IO】業(yè)務(wù)寫成自治的，但是可以附加額外的手工全局調(diào)優(yōu)。而不是強(qiáng)制要求把業(yè)務(wù)邏輯從局部抽出去

How we perceive

• 人眼只能在狹窄的感受野里獲得信息

人對(duì)時(shí)間的感知是來自于對(duì)空間的感知

人希望在一個(gè)屏幕內(nèi)從上往下的獲取時(shí)間順序上從早到晚的信息

• callback 的編程方式破壞了屏幕上的順序和時(shí)間順序的直接映射關(guān)系

• 【協(xié)程式IO】用協(xié)程取代 callback，把屏幕上的代碼擼直

通過 status 字段驅(qū)動(dòng)的業(yè)務(wù)狀態(tài)機(jī)破壞了屏幕上的順序和時(shí)間順序的直接映射關(guān)系

• 【協(xié)程式業(yè)務(wù)流程】用協(xié)程取代 status 狀態(tài)機(jī)，把屏幕上的代碼擼直

因?yàn)楦惺芤暗南拗疲创a沒有空間展示所有的細(xì)節(jié)

• 類型定義，內(nèi)存分配等“細(xì)節(jié)”占用了大量的視覺區(qū)域
  • 【IDE細(xì)節(jié)隱藏】在文本上省略掉細(xì)節(jié)，由 IDE 進(jìn)行補(bǔ)全，當(dāng)鼠標(biāo)移動(dòng)上去的時(shí)候才展示出來
• 人最習(xí)慣的空間整理方式仍然是層狀的文件夾
  • 所有的“架構(gòu)”設(shè)計(jì)，最終都是對(duì)文件夾和文件的設(shè)計(jì)。但是一個(gè)維度的靜態(tài)索引（文件夾嵌套）無法滿足所有可能的檢索需求
  • 【IDE按需索引】由 IDE 來補(bǔ)全文件夾分類不能滿足的索引需求，針對(duì)閱讀者的任務(wù)來設(shè)計(jì)IDE索引

視桿細(xì)胞容易忽略形狀和順序的差異，但是對(duì)顏色更敏感

• 語(yǔ)法高亮占用了寶貴的資源，但是并沒有考慮閱讀者的訴求
• 【IDE按需高亮】對(duì)于不同的任務(wù)，閱讀者希望找到的重點(diǎn)是不同的，語(yǔ)法高亮應(yīng)該結(jié)合任務(wù)來做

How we collaborate

• 人與人之間最高效的溝通的方式是面對(duì)面的交互式聲波震動(dòng)

人類低下的溝通帶寬根本上限制了一個(gè)團(tuán)隊(duì)的規(guī)模

• 上線速度要求越快越好，但是加人帶來的邊際效益遞減

• 減少開會(huì)拉齊，團(tuán)隊(duì)?wèi)?yīng)該盡可能地自治，而不是什么都要靠 feature team 橫向拉通

高內(nèi)聚，低耦合

• 【靜態(tài)鏈接包】編程工具應(yīng)該提供更多的組合可能，而不是所有的組合都要在運(yùn)行時(shí)用面向?qū)ο蟮亩鄳B(tài)來實(shí)現(xiàn)
  • 【按變更頻率切分包】分工應(yīng)該按照變更頻率來確定，分工應(yīng)該是明確的

盡可能由最終用戶，或者靠近最終用戶的團(tuán)隊(duì)來解決問題，而不是長(zhǎng)距離傳遞需求

• 最終用戶編程：直接讓需求提出者自己來實(shí)現(xiàn)需求
  • 把“學(xué)習(xí)”內(nèi)置到工具里，需要內(nèi)置一個(gè)教學(xué)工具
    • 最終用戶的編程工具開發(fā)難度高，成本高，投入超過了單個(gè)軟件的回報(bào)
    • 【編輯器預(yù)制】把“公式編輯”，“店鋪裝修”等常見共性需求提前預(yù)制
  • 教學(xué)工具的目標(biāo)是教學(xué)，而不是把自己標(biāo)桿為更先進(jìn)的生產(chǎn)力
    • 【教學(xué)內(nèi)置】提供教學(xué)模式和生產(chǎn)力模式的無縫切換
• 低代碼編程：通過提前預(yù)制，把工作量前置，減少應(yīng)用開發(fā)者的規(guī)模，從而可以在組織架構(gòu)上把開發(fā)者內(nèi)置到用戶組織內(nèi)部。與此相對(duì)應(yīng)的是文檔驅(qū)動(dòng)的外包式開發(fā)。
  • “預(yù)制”來自于對(duì)共性需求的提前預(yù)判
    • 【非功能性需求云化】非功能性需求的實(shí)現(xiàn)，都是運(yùn)行在相似的機(jī)器上
    • 操作系統(tǒng)
    • k8s
    • RPC 框架
    • 開發(fā)者都是人類
    • 編程工具
    • 溝通工具
    • 用戶都是人類
    • 【SaaS組件】IM / 電話 / 短信
    • 【Ui組件】字處理器 / 表格
    • 【CRUD生成】慣用的展現(xiàn)和交互
      • 列表詳情
      • 樹狀層級(jí)
      • 表格結(jié)構(gòu)
      • 可拖拽白板
    • 【SaaS組件】相對(duì)穩(wěn)定的業(yè)務(wù)流程
    • 登錄注冊(cè)
    • 支付
    • 行業(yè)內(nèi)相對(duì)穩(wěn)定的業(yè)務(wù)共性流程
    • 電商
    • HR / 招聘
    • 銷售管理 / CRM

How we learn

人的“歸納/理解/學(xué)習(xí)”能力高度依賴于可視化交互式地操縱與反饋

• 幫助應(yīng)該放在任務(wù)執(zhí)行的地方，與其說“可視化”，不如說是“可發(fā)現(xiàn)”
  • 【填空題變選擇題】單獨(dú)的語(yǔ)法手冊(cè)是不好使的，必須提供界面上的按鈕，把填空題變成選擇題，這樣才能啟發(fā)學(xué)習(xí)
  • GUI 設(shè)計(jì)器 / 店鋪裝修
  • 公式編輯器
  • 審批 / 工作流設(shè)計(jì)器
  • trigger 流程設(shè)計(jì)器
• 人習(xí)慣于用手觸碰一下對(duì)象，然后觀測(cè)其反饋，從而歸納學(xué)習(xí)
  • 不可觀測(cè)的行為無法學(xué)習(xí)
  • 生產(chǎn)環(huán)境的bug無法本地復(fù)現(xiàn)，我怎么找規(guī)律？
    • 【TestInProduction】tracing，大量的 tracing，流量回放
  • lowcode 平臺(tái)的bug沒有任何線索，除了找平臺(tái)開發(fā)者，我能怎么辦？
    • 不能要求用戶了解所有的內(nèi)部細(xì)節(jié)，“平臺(tái)”要做到可依賴
    • 業(yè)務(wù)邏輯問題的定位和生產(chǎn)環(huán)境的bug定位一樣，靠 tracing
  • 反饋太慢的行為給人的負(fù)面感受是指數(shù)增加的
  • 本地機(jī)器太慢了跑不起來，需要上公司的沙盒環(huán)境來復(fù)現(xiàn)問題
    • 【云IDE】
  • 改完了代碼需要重新編譯重新加載
    • 【LanguageServer】交互式開發(fā)的時(shí)候跳過不必要的編譯
    • 【所見即所得】所見即所得的 GUI 開發(fā)，本質(zhì)上就是用解釋器執(zhí)行，換取編譯時(shí)間的縮減
  • 【HMR】重加載的時(shí)候保持頁(yè)面狀態(tài)

no code / low code / pro code

一切的改進(jìn)都是源自于人類的缺陷