低代碼實戰篇一：創建認知與深挖業務

筆者自2020年5月底入職新公司以來，一頭扎進公司低代碼平臺的建設中。從零開始，在實踐中不斷打磨，也總結了很多經驗與教訓。在此，但願能拋磚引玉，給各位大佬帶來更多新的思考。

本系列計劃分爲四篇，逐步講解低代碼平臺建設實踐中的各類問題和解決辦法：

• 低代碼實戰篇一：創建認知與深挖業務
• 低代碼實戰篇二：結合具體業務產品談談實現
• 低代碼實戰篇三：圍繞現有能力不斷拓展產品形態
• 低代碼實戰篇四：總結與展望

本篇爲開篇，按照是什麼、爲何、應怎麼作的結構來展開，大約須要八分鐘的閱讀時間。

引子

筆者從事前端六年，其實也就是今年纔對低代碼相關概念和思想有所瞭解，可是不知覺中運用到低代碼模式來進行開發卻早在16年初就開始了。

當時筆者做爲部門內前端小能手，接手了一個即便在如今看也是至關麻煩的項目。這個項目的目的在於按期以表格的形式收集審覈成員公司的報表，彙總給集團高層和相關分析部門查看。剛接手時筆者想着不就是建幾個表單，填寫、提交、審覈、查看一條龍完事兒了嘛。

結果後面一對接需求才傻了眼，集團下有上百個成員公司，歸屬於數個版塊集團公司，每一個版塊集團負責統一收集版塊內的關鍵運營指標數據並上報。可是每一個板塊的業務截然不同，彙總的表格格式、數據絕大部分都不同！！每一個業務版塊平均十多張表格，多的時候總共六七十個徹底不同的表格！！這還不是最可怕的，最可怕的是因爲業務變化頻繁，這些表格還會常常變更！！並且還要能支持在移動端完美的展示表格數據（移動端展示大表格的體驗極差）！！

作過業務系統的童鞋們都知道，數據庫裏維護六七十個業務表是很是麻煩的，業務表字段要是頻繁的改動那更是沒辦法作。前端童鞋也很苦逼呀，幾十個表單頁面改來改去，那不得原地爆炸。

時間緊急，初版開發時間只有一個月，苦思很多天的我終於想到了一套在當時看來解了燃眉之急的解決方案：

1. 每一個表格用一個json對象來描述，大概以下：

{
  row_01: {
    column_01: {
      rowspan: 0,
      colspan: 0,
      editable: false,
      type: 'string',
      value: '業務',
      ...
    },
    column_02: {
      rowspan: 0,
      colspan: 0,
      editable: false,
      type: 'string',
      value: '指標',
      ...
    }
  },
  row_02: {
    column_01: {
      rowspan: 0,
      colspan: 0,
      editable: false,
      type: 'string',
      value: '淨現金流',
      ...
    },
    column_02: {
      rowspan: 0,
      colspan: 0,
      editable: true,
      type: 'number',
      value: '',
      ...
    }
  }
}

這是一個2 X 2的表格，實際業務中的表格要遠遠複雜得多，可是經過一個精心設計的 json schema，總能完備得描述這個表格長什麼樣子，哪幾行是表頭，單元格要跨幾行跨幾列，哪些單元格是不可改的，哪些單元格是可改的，可編輯單元格的內容類型（字符串、數字、時間點、時間段、金額等等）

二、PC端展示表格時基於json schema作渲染，僞代碼以下：

<table>
  <tr v-for="row in jsonSchema">
    <td
      v-for="cell in row"
      :rowspan="cell.rowspan"
      :colspan="cell.colspan">
      <span v-if="!cell.editable">{{cell.value}}</span>
      <template v-else>
        <input v-if="cell.type==='string'" v-model="cell.value" />
        <input-number v-if="cell.type==='number'" v-model="cell.value" />
        <date-time  v-if="cell.type==='dateTime'" v-model="cell.value" />
        ...等等其餘類型輸入項
      </template>
    </td>
  </tr>
</table>

沒錯，核心代碼就是這麼簡單。。

三、移動端定義一系列適用於移動端的組件，好比主副標題、指標詳細（左右結構、上下結構），根據不一樣業務類型對數據展現的不一樣需求，基於 json schema 轉換成另外一套 mobile dsl（什麼是DSL），再基於 mobile dsl 和移動端組件生成一系列組件的組合。好比：

這樣的顯示在移動端上就比表格的形式舒服多了~

轉換後的mobile dsl 大概是這樣的：

[
  {
    type: "section",
    title: "財務指標",
    subTitle: "萬元",
    list: [
      {
        type: "description",
        layout: "horizontal",
        title: "淨現金流",
        desc: "1000"
      },
      ...
    ]
  },
  ...
  {
    type: "introduction",
    intro: "XXXXX"
  }
]

渲染的僞代碼我就不寫了，也挺簡單的，

四、每一個表格定製一份 json schema 做爲表格模板，填報人每一個填報週期均可以此模板爲基礎填寫表格，某個填報週期若是表格發生了變更，只須要調整表格的 json schema 和根據具體的修改，更改移動端 mobile schema 便可。只須要一個數據表，就能解決以往幾十上百個數據表才能解決的問題~後續通過統計，增增改改至少有兩百個不一樣版本的複雜表格。。。

如今回看當時這個初級項目，儘管還有許許多多的問題，好比因爲項目投入和人手經驗能力的問題，未能作到圖形化輸出json schema，徹底是靠的人力手工輸出哈哈。。還好比表格版本管理功能邏輯混亂等等。可是這是我第一次獨自一人從需求調研到產品設計到數據庫表設計再到前端開發後端監督再到項目管理，完整的掌控一個項目，各方面都有了較大的提高。

若是當時項目投入再大點，完善基於圖形化界面輸出 json schema 的功能，基本就是一個比較標準的低代碼類應用了。惋惜經費不足、人手不足，只能作到手擼json的階段。不過這個項目也爲我積累了不少寶貴的經驗，畢竟從需求調研、產品功能設計、數據庫表設計再到前端開發後端監督等等我都有極大程度的參與。

low-code低代碼究竟是什麼？

因此低代碼究竟是什麼呢？看了我剛剛舉的例子，可能你們已經有了一個初步的概念。在這我根據本身的理解，作一下概括總結。

低代碼是以效率提高爲目的，經過圖形化配置、少許參數配置、內置隱含邏輯規則等方式，輸出可以徹底描述業務模型且可以兼容代碼編寫的數據，並以此根據業務或產品形態，完成應用的構建與渲染。

以效率爲目的

一是爲人而服務，不只是提高開發人員的效能，更要能給業務應用所關聯的全部人員提供效率提高的保障。二是爲業務而服務，營銷頁面低代碼平臺快速搭建營銷頁面，場景應用低代碼平臺快速輸出應用，流程表單低代碼平臺快速輸出功能邏輯完備的表單流程等等。

圖形化配置、少許參數配置、內置隱含邏輯規則等方式

蘊含着一個低代碼平臺的一個重要核心，那就是門檻必定要足夠低，簡單易懂的操做方式，所見即所得的操做體驗，低代碼甚至徹底不須要寫代碼的低要求。

輸出可以徹底描述業務模型且可以兼容代碼編寫的數據

這要求可以對業務持續進行深刻的分析，對業務的全貌具備充分的瞭解，低代碼平臺適合較爲垂直的業務領域，過於追求大而全，低代碼可能反而成爲阻礙。

根據業務或產品形態，完成應用的構建與渲染

經過我上面項目的例子，很好理解，輸入的是表格，輸出的不必定也是表格，多是適合移動端展現的樣式，也可能表格數據通過BI輸出適合大屏展現的可視化圖表。展示形態（pc、mobile、大屏等）、數據載體（單一數據，結構化數據，BI處理的數據）、平臺特性（安卓、iOS、小程序、h5等）等都對低代碼平臺有較大影響，咱們必須結合實際業務深刻分析。

爲何要作低代碼平臺呢？

由於業務需求，也由於成本效率更高，更由於從長遠上，低代碼已經成爲一種趨勢。對於技術團隊或者我的，結合業務儘快接入或者瞭解，有利於在細分領域迅速佔有技術優點。對於企業，對於定製化需求不是特別高的業務，低代碼平臺能較好的增效賦能。

固然，我反覆強調業務，必定要結合具體的業務來思考當前是否須要開發或者接入一個低代碼平臺。

可是，提早了解了解也蠻好~

低代碼平臺應該怎麼作呢？

接下來的系列文章中，筆者將結合公司的低代碼平臺產品—一款經過圖形化拖拽和簡單參數配置就能生成Andriod、iOS、支付寶小程序、微信小程序四端UI一直、體驗一致、功能一致的應用—來談談這個產品是怎樣從無到有一步步建設而來的。

主要內容包括但可能不限於：

1. 業務分析與抽象
2. 數據模型與組件抽象
3. 動態數據賦能
4. 可用性、易用性和知足更定製化的需求
5. 拓展運營和開放的能力

歡迎你們在評論區交流，若有錯誤也請指正哈。

感興趣的朋友歡迎點贊關注，年末KPI就靠各位大佬啦。我將在元旦放假期間儘快完成所有文章，儘快發出~