圖片來源@Unsplash

最近低代碼概念很火，作為一名毫無代碼基礎的小白，看到鋪天蓋地的“低代碼/無代碼基礎創(chuàng)建應用”的言論，總是會心聲疑惑：代碼零基礎真的可以開發(fā)應用嗎？

在跟一些企業(yè)交流的過程中，多數(shù)對這個問題給出了肯定的回答。但是如果不自己上手試，總覺得“低代碼”聽起來還是有些抽象。

據(jù)鈦媒體App了解，釘釘宜搭在近期開放了試用體驗。我忍不住試了試，以下是真實開發(fā)日志，來看看這個“低代碼”應用的“真假”吧：

零代碼開發(fā)的“宜報題”

“每周報選題”對媒體從業(yè)者來說一點兒也不陌生，但由于這個需求太小眾，一般大家都用在線協(xié)作文檔就解決了選題的留存和管理問題。

協(xié)同辦公軟件們，并沒有針對媒體行業(yè)專門做“選題”管理工具。我就從這個市場空白入手，評測主題有了：

用釘釘宜搭創(chuàng)建一款“報選題”小應用～

我給這個應用起的名字是“宜報題”——此處還需要強調(diào)的是，“宜報題”想要解決的媒體行業(yè)選題管理這一需求，并沒有經(jīng)過專業(yè)調(diào)研，這款應用的誕生主要是為了評測下釘釘宜搭，并真實體驗下低代碼開發(fā)。

先來說下“宜報題”的最終整個呈現(xiàn)效果。因為鈦媒體內(nèi)容團隊管理采取“采編獨立”的機制，我在開發(fā)中，把編輯崗需要審核稿件的幾位同事，定義成了“編輯”角色，把幾位需要撰寫稿件的同事定義為“記者”角色。

這里也感謝在“宜選題”中出鏡的幾位同事，為了降低應用的流程設計復雜度，只能隨機抽選他們幾位出鏡。

宜報題選題申報界面

上面這個圖，是“記者”進入宜選題應用時的選題申報界面，“記者”需要寫明選題名稱，以及闡述選題亮點，并針對性選擇一位編輯，標明自己的身份（稿件實際執(zhí)行人）后，選好預計的初稿完成日期即可提交選題進入“選題審批”階段。

宜報題審批界面3

如上圖，這是一篇編輯審核通過，“記者”進入執(zhí)行階段的稿子。編輯在審批選題時，也可順帶提出選題建議。雙方在選題進展過程中也能進行評論交流。在稿件完成后，記者可提交“已完成”來反饋稿件進度。

宜報題已完成界面

當然，考慮到在實際運行過程中，一些稿子會由于時效性等綜合原因，無法繼續(xù)執(zhí)行，所以也設置了“不想寫了”按鈕，表示稿件終止，并退回至相應節(jié)點審批。

簡單，但也存在一些門檻

上面幾張低代碼應用的最終呈現(xiàn)效果是不是看起來很簡單？但其實做起來并不順利?？赡苡捎谖覍Α耙藞箢}”的要求更為復雜，中間進入到“邏輯圈”迷宮。結果就是這個看起來非常簡單的小應用，從熟悉宜搭界面到最后完成測試大概花了5個小時。

5個小時！

第一步，因為“報題”實際上涉及到一個審批流程，所以我選用了宜搭里的一個審批模版。然后利用宜搭的組件庫，搭建起來一個表單。很順利。

宜報題表單界面

表單設計完成，接下來是第二步：流程設計。

按照宜搭設置的規(guī)則，已成形的表單中的“單選”組件會自動成為“審批條件”的備選項。

宜報題流程審批設置界面

兩個審批條件選中，系統(tǒng)會自動進入“如果編輯是A1，記者是A2，就執(zhí)行A3”的邏輯，大概就是這樣：

后臺審批路徑的可能性展示

數(shù)學好的同學可以算下，在前臺看起來非常簡單的兩個單選，在后臺跑起來需要有多少種可能性。

這里遇到了坎兒。如果要簡單的場景，可能就是設定一兩個審批人，大家套用一套審批規(guī)則就行。但在我的實際工作中，由于編輯（審批人）是多個，記者（實際執(zhí)行人）也是多個，所以這里就出現(xiàn)了排列組合，基礎的規(guī)則已經(jīng)無法解決了。

更復雜的一項邏輯是，我需要為每種可能的“A3”設置執(zhí)行路徑，就像這樣：

宜搭審批節(jié)點路徑設置界面

大家可以發(fā)現(xiàn)，前臺呈現(xiàn)的每一個選項，在后臺都是一個“角色”，為了將這些角色串聯(lián)進入流程審批，我需要將對他們一一定義，于是在這個看起來簡單的選題審批應用中，我定義了十余個角色。

宜報題中為審批路徑設置的角色

對每一個可能審批節(jié)點的定義，是花時間最久的地方。在第一部分提到的兩個看起來是為選題業(yè)務設置的兩個“已完成”、“不想寫了”兩個按鈕，也是手動設置的，他們在后臺長這樣：

宜搭節(jié)點動作設置界面

不過，開發(fā)過程中有個bug在于：假如團隊來了一個新人，我要把這個新角色設置進入這個審批流程里面，那么以上審批節(jié)點都要推倒重來一次。

宜搭審批節(jié)點復制拷貝界面

好在宜搭上設置了“復制粘貼”功能，不然，真的要把“打工人”搞si了。（此處完全可以理解 ITer 對人工智能的瘋狂追求了，現(xiàn)在我也想要“人工智能”。

這里就有了一個小結論：這類低代碼開發(fā)工具，主要是將代碼開發(fā)編程圖形化的拖拽，但在邏輯上由于需要人工定義，在智能性上目前還有一定不足。

當然，我也遇到了一些需要代碼和函數(shù)知識儲備的才能處理的問題，比如這些：

宜搭上某些看不懂的界面

完全看不懂，對不對？所以我選擇跳過這些函數(shù)，傻瓜式搭建了這個報題小應用。

一個成熟的角色工作臺長這樣

像上圖這樣用低代碼開發(fā)出數(shù)據(jù)分析界面的，在我這里可以封神了。

完整“開發(fā)”經(jīng)驗總結如下：

1、本人承諾，整個小應用的搭建，沒有使用任何代碼。是的，這里我用了“搭建”，而不是“開發(fā)”。整個應用的搭建還是很順暢，沒有代碼經(jīng)驗確實可以搭建起來一些日常的應用，因為整個過程真的就像搭積木，與現(xiàn)實中搭積木不同的是，這個積木是搭完是“活”的，是可以跑起來的。有興趣的朋友打打殺殺的游戲玩兒累了，可以上來把低代碼當成益智游戲；

2、網(wǎng)上說的低代碼幫助“人人成為開發(fā)者”，這個結論有某種程度上的正確性，但是也并不全對。比如上述涉及到函數(shù)以及復雜的審批邏輯時，對于像我這樣不懂代碼，函數(shù)只懂“SUM”、高中數(shù)學最多考90分的人來說，還是有一定難度；

3、低代碼的使用體驗，一定程度上要依賴核心平臺。比如這個“宜報題”，因為是用釘釘宜搭開發(fā)出來的，所以用釘釘打開更加順暢。如果將應用鏈接復制到其它平臺，會要求注冊登陸“宜搭”賬號。所以長遠來看，低代碼應用生態(tài)會不會更加開放對低代碼的“公民化”具有重要意義；

4、最后總結，雖然低代碼現(xiàn)在還不能完全滿足一些復雜功能的開發(fā)，但是一定要肯定的是低代碼對企業(yè)邊緣應用開發(fā)需求的滿足，比如我們現(xiàn)在使用很方便的防疫表單、簡單的費用審批等等，可以按照自己想法快速搭建好，這個對提高企業(yè)效率是很有價值的。（本文首發(fā)鈦媒體App，作者 | 秦聰慧）