免費AI編程助手
-
全棧平臺
- 阿里-云鳳蝶
- 云鳳蝶自由畫布之道：分層模型
- 阿里-金蟬
- 阿里-宜搭
- 阿里-天馬
- 騰訊-積木
- 騰訊-lowcode
- 無遠開發(fā)平臺
- 奧哲
- ivx
- 閃電數據管理
- 巴克云
- 數式科技
- 明道云 支持公共云和私有部署，私有部署在Github可獲得免費社區(qū)版下載
- 輕流
- 速融云
- 簡道云
- 炎黃盈動
- 廣州天翎myApps
- 活字格
- 起步科技
- 金蝶云-蒼穹
- 普元
- OpsMind
- xdeer
- 湘北智造
- 表單大師
- Zion/載航
- Appsmith（Github）
- 白碼
- 捷碼
- 支持業(yè)務系統(tǒng)/管理系統(tǒng)、可視化大屏、3D園區(qū)低碼快速開發(fā)
-
支持離線部署
頁面搭建
僅包含前端部分的 low code 平臺
- MAKA
- 易企秀
- 上線了
- 兔展
- 稿定設計
- 壹伴
- 創(chuàng)客貼
- 點石
- 京東-通天塔
- 阿里-imgcook
- 轉轉-魔方
- 人人貸-活動運營平臺
- 美團-樂高
- 百度-h5
- 政采云-魯班
- 攜程-民宿CMS
- 攜程-樂高
- 知乎-Versatile Editor
- [阿里-bi designer_blank_nofollow](https://github.com/dt-fe/weekly/blob/v2/164.精讀《數據搭建引擎 bi-designer API-設計器》.md)
-
店鋪裝修
非獨立頁面，依附于業(yè)務系統(tǒng)存在的頁面搭建
- shopify
-
有贊-微頁面
- 淘寶店鋪裝修
- 阿里-飛冰
- 阿里-formilyjs
- 阿里-gaea-editor
- 阿里-sula
- blockVisualEditor
- pager
- 運滿滿-碼良
- X-Page-Editor
- Vue-Layout
- antd-visual-editor
- pipeline-editor
- panel-magic
- 百度外賣-blocks
- Esview
- gen
- bee gen pro
- 百度-amis
- 唯品會-ams
- vue-admin
- 魯班 H5
- 華炎魔方
- h5-factory
- vision
- brick-design
- 隨心秀
- yh5
- rxeditor
- activity-YD
- layoutit
- Ramiko
- jeecg-boot
- sparrow-js
- Tefact: Tefact 輕量級無代碼/低代碼，H5、表單編輯器
- 星搭: 星搭無代碼平臺，快速構建中后臺、小程序
- 好未來曉黑板go-zero微服務框架: 你不需要懂微服務，懂業(yè)務就行
- cube：快速搭建中后臺頁面
- react-visual-design: 基于react的h5組件搭建
- Web Designer
- h5maker
- pl-drag-template
- form-generator：Element UI表單設計及代碼生成器
- form-render：通過 JSON Schema 生成標準 Form，基于React
- Vue Json Design
- rebuild
- W5 SOAR
- https://github.com/blocks/blocks
- https://github.com/frappe/frappe
- https://github.com/ipselon/structor
- https://github.com/vigetlabs/colonel-kurtz
- https://github.com/BuilderIO/builder
- https://github.com/vuegg/vuegg
- https://webcodesk.com/
-
辦公/管理系統(tǒng) a.k.a no-code
- 黑帕云
- 維格表
- 阿里云-Teambition
- 阿里云-RPA
- SeaTable
- 蒲公英-Tracup
- 蒲公英-Seed
- 伙伴云
- monday.com
- Airtable
-
聲明式編程
行業(yè)綜述
- 精讀《對低代碼搭建的理解》
- 頁面可視化搭建工具前生今世
- React.js 可視化編輯工具
- 對低代碼、零代碼產品的一些看法
- 對 aPaaS 的產品認知
- 無代碼編程
- 萬物代碼化：從低代碼、云開發(fā)到云研發(fā)的思考
- 《早早聊搞搭建》搞過搭建的我收獲了什么？
-
技術點
- 可逆計算
- 161.精讀《可視化搭建思考 - 富文本搭建》
- 面向 Model 編程的前端架構設計
- 流動的數據——使用 RxJS 構造復雜單頁應用的數據邏輯
- 使用 React 寫個簡單的活動頁面運營系統(tǒng) - 設計篇
- 【電商】用可視化編輯，解構看起來非常炫酷的專題頁面
- 如何搭建一個功能復雜的前端配置化框架(一)
- 可視化拖拽組件庫一些技術要點原理分析
-
國外
- https://www.honeycode.aws/
- https://developers.google.com/appmaker
- https://powerapps.microsoft.com/zh-cn/
- https://www.zoho.com/creator/
- https://www.salesforce.com/
- https://www.appian.com/
- https://bubble.io/
- https://www.adalo.com/
- https://thunkable.com/
- http://www.vvveb.com/vvvebjs/editor.html
- https://www.forestadmin.com/
- https://mobirise.com/
- https://paperbits.io/
- https://builderx.io/
- https://grapesjs.com/
- https://reactstudio.com/
- https://www.wix.com/
- https://university.webflow.com/
- https://www.squarespace.com/
- https://www.framer.com/
- https://www.figma.com/
- https://www.mendix.com/zh/
- https://www.outsystems.com/
- https://retool.com/
- https://www.quickbase.com/
- https://layoutit.com/
-
https://www.claris.com/zh/filemaker/
一切改進都是源自于人類的缺陷
How we think
- 人腦是串行的，無法有效并行思考多條線索
-
人腦不適合思考并行執(zhí)行的多線程
- 【單線程】把共享變量的編程模式改成事務整體提交的模式
-
人腦不適合思考同時呈現在屏幕上的多個獨立的業(yè)務流程
- 代碼是按發(fā)生時間組織的，在一起的代碼未必是邏輯上有關聯的業(yè)務流程
- 【按業(yè)務切分文件】閱讀者應該可以按照自己的任務目標來跟蹤索引，而不是默認一個按鈕點擊引起的處理邏輯都一定要寫在一個大文件里
- 【按變更頻率切分文件】業(yè)務變更是閱讀的首要原因，代碼應該按照業(yè)務變更的頻率來組織。會同時變更的代碼應該放在一起
人腦很難管理多份獨立可變的狀態(tài)，本質上每個獨立變化的狀態(tài)就是一個獨立的線程
- 驅動狀態(tài)數量熵增的三大因素：
- 因為交互體驗的要求，從后端到富客戶端到3d動畫，狀態(tài)被復制多份，越來越靠近展示層
- 因為硬件物理的約束，內存從CPU統(tǒng)一尋址，到異構計算，CUDA，每個硬件核都有一層自己的內存
- 因為數據量的增長，從統(tǒng)一的OLAP從庫，到Data Lake，Data Mart，數據被復制成越來越份，流水線越來越長
- 對抗狀態(tài)數量熵增的手段：
- 【聲明式數據聯動】減少獨立變化的狀態(tài)，用表達式來表達 derived state
- 【全局虛擬數據層】借鑒Unix的統(tǒng)一文件抽象，引入一層統(tǒng)一的虛擬數據層。盡可能把狀態(tài)轉化成 cache
- 代碼是按發(fā)生時間組織的，在一起的代碼未必是邏輯上有關聯的業(yè)務流程
-
人腦很難理解新增對原有行為的劇烈變化，更習慣逐層穩(wěn)定疊加。也就是人更希望“控制變量”
- css 最大的難度在于不正交，新增一條對規(guī)則會引起意想不到的效果
- 【局部化布局】swiftui 的 HStack/VStack/ZStack 布局規(guī)則數量少，每條規(guī)則作用都是局部的穩(wěn)定的疊加
- 性能優(yōu)化往往需要破壞局部性，因為局部的自治容易引起重復勞動
- 【局部化IO】系統(tǒng)自動實現 I/O 的批量等可以自動化做的全局優(yōu)化
- 【局部化IO】業(yè)務寫成自治的，但是可以附加額外的手工全局調優(yōu)。而不是強制要求把業(yè)務邏輯從局部抽出去
How we perceive
- 人眼只能在狹窄的感受野里獲得信息
- css 最大的難度在于不正交，新增一條對規(guī)則會引起意想不到的效果
-
人對時間的感知是來自于對空間的感知
-
人希望在一個屏幕內從上往下的獲取時間順序上從早到晚的信息
- callback 的編程方式破壞了屏幕上的順序和時間順序的直接映射關系
- 【協(xié)程式IO】用協(xié)程取代 callback，把屏幕上的代碼擼直
通過 status 字段驅動的業(yè)務狀態(tài)機破壞了屏幕上的順序和時間順序的直接映射關系
- 【協(xié)程式業(yè)務流程】用協(xié)程取代 status 狀態(tài)機，把屏幕上的代碼擼直
-
因為感受野的限制，源代碼沒有空間展示所有的細節(jié)
- 類型定義，內存分配等“細節(jié)”占用了大量的視覺區(qū)域
- 【IDE細節(jié)隱藏】在文本上省略掉細節(jié)，由 IDE 進行補全，當鼠標移動上去的時候才展示出來
- 人最習慣的空間整理方式仍然是層狀的文件夾
- 所有的“架構”設計，最終都是對文件夾和文件的設計。但是一個維度的靜態(tài)索引（文件夾嵌套）無法滿足所有可能的檢索需求
- 【IDE按需索引】由 IDE 來補全文件夾分類不能滿足的索引需求，針對閱讀者的任務來設計IDE索引
- 類型定義，內存分配等“細節(jié)”占用了大量的視覺區(qū)域
-
視桿細胞容易忽略形狀和順序的差異，但是對顏色更敏感
- 語法高亮占用了寶貴的資源，但是并沒有考慮閱讀者的訴求
- 【IDE按需高亮】對于不同的任務，閱讀者希望找到的重點是不同的，語法高亮應該結合任務來做
How we collaborate
- 人與人之間最高效的溝通的方式是面對面的交互式聲波震動
-
人類低下的溝通帶寬根本上限制了一個團隊的規(guī)模
- 上線速度要求越快越好，但是加人帶來的邊際效益遞減
- 減少開會拉齊，團隊應該盡可能地自治，而不是什么都要靠 feature team 橫向拉通
高內聚，低耦合
- 【靜態(tài)鏈接包】編程工具應該提供更多的組合可能，而不是所有的組合都要在運行時用面向對象的多態(tài)來實現
- 【按變更頻率切分包】分工應該按照變更頻率來確定，分工應該是明確的
-
盡可能由最終用戶，或者靠近最終用戶的團隊來解決問題，而不是長距離傳遞需求
- 最終用戶編程：直接讓需求提出者自己來實現需求
- 把“學習”內置到工具里，需要內置一個教學工具
- 最終用戶的編程工具開發(fā)難度高，成本高，投入超過了單個軟件的回報
- 【編輯器預制】把“公式編輯”，“店鋪裝修”等常見共性需求提前預制
- 教學工具的目標是教學，而不是把自己標桿為更先進的生產力
- 【教學內置】提供教學模式和生產力模式的無縫切換
- 把“學習”內置到工具里，需要內置一個教學工具
- 低代碼編程：通過提前預制，把工作量前置，減少應用開發(fā)者的規(guī)模，從而可以在組織架構上把開發(fā)者內置到用戶組織內部。與此相對應的是文檔驅動的外包式開發(fā)。
- “預制”來自于對共性需求的提前預判
- 【非功能性需求云化】非功能性需求的實現，都是運行在相似的機器上
- 操作系統(tǒng)
- k8s
- RPC 框架
- 開發(fā)者都是人類
- 編程工具
- 溝通工具
- 用戶都是人類
- 【SaaS組件】IM / 電話 / 短信
- 【Ui組件】字處理器 / 表格
- 【CRUD生成】慣用的展現和交互
- 列表詳情
- 樹狀層級
- 表格結構
- 可拖拽白板
- 【SaaS組件】相對穩(wěn)定的業(yè)務流程
- 登錄注冊
- 支付
- 行業(yè)內相對穩(wěn)定的業(yè)務共性流程
- 電商
- HR / 招聘
- 銷售管理 / CRM
- “預制”來自于對共性需求的提前預判
How we learn
- 最終用戶編程：直接讓需求提出者自己來實現需求
-
人的“歸納/理解/學習”能力高度依賴于可視化交互式地操縱與反饋
- 幫助應該放在任務執(zhí)行的地方，與其說“可視化”，不如說是“可發(fā)現”
- 【填空題變選擇題】單獨的語法手冊是不好使的，必須提供界面上的按鈕，把填空題變成選擇題，這樣才能啟發(fā)學習
- GUI 設計器 / 店鋪裝修
- 公式編輯器
- 審批 / 工作流設計器
- trigger 流程設計器
- 人習慣于用手觸碰一下對象，然后觀測其反饋，從而歸納學習
- 不可觀測的行為無法學習
- 生產環(huán)境的bug無法本地復現，我怎么找規(guī)律？
- 【TestInProduction】tracing，大量的 tracing，流量回放
- lowcode 平臺的bug沒有任何線索，除了找平臺開發(fā)者，我能怎么辦？
- 不能要求用戶了解所有的內部細節(jié)，“平臺”要做到可依賴
- 業(yè)務邏輯問題的定位和生產環(huán)境的bug定位一樣，靠 tracing
- 反饋太慢的行為給人的負面感受是指數增加的
- 本地機器太慢了跑不起來，需要上公司的沙盒環(huán)境來復現問題
- 【云IDE】
- 改完了代碼需要重新編譯重新加載
- 【LanguageServer】交互式開發(fā)的時候跳過不必要的編譯
- 【所見即所得】所見即所得的 GUI 開發(fā)，本質上就是用解釋器執(zhí)行，換取編譯時間的縮減
- 【HMR】重加載的時候保持頁面狀態(tài)
no code / low code / pro code
一切的改進都是源自于人類的缺陷
- 幫助應該放在任務執(zhí)行的地方，與其說“可視化”，不如說是“可發(fā)現”
- no code：自己編程給自己用，給用戶的感覺是一個更強大的辦公/實用軟件。主要的手段是用圖形化操作等方式降低學習曲線。no code 一定要面向非常固定的領域才能做到好用。
- low code：編程給其他人用，為此創(chuàng)造了一個 citizen developer 的概念。主要的手段是平臺預制好常見的需求，減少需要從頭寫的代碼。low code 也要面向指定的領域才能讓平臺提前預測需求，但相比 no code 可以不把使用場景限定得那么死。
- pro code：low code 的平臺自己不會選擇 low code 來創(chuàng)建這個平臺本身，因為 low code 并沒有降低從頭構建一個系統(tǒng)的成本。但是 pro code 的平臺自己會選擇 pro code 來創(chuàng)建這個平臺本身，比如 react 開發(fā)者會選擇用 react 來創(chuàng)建自己的開發(fā)工具，因為 pro code 的工具和平臺都是以從根本上降低從頭構建一個系統(tǒng)的復雜度為目標的。
