資料流 dataflow

即使再愛寫程式, 仍然相信未來的數位應用是不需要寫的。

如果不用寫, 那會是:

1. 程式產生器, 像填寫問卷或描述摘要一般, 再生出對應程式。
2. 強化版 IDE 或 Scratch/Alice 拖拉。
3. 人工智慧 加 對話介面 (Siri+)。

前兩項侷限在某些範圍, 最後一項雖然部分已達成, 但普及(廣度/深度)仍然需要時間。

比較相信的方式是透過資料驅動 (data driven), 雖然這詞已被定義在特定範圍, 這裡以更廣的角度來看 …

用時事舉例, 偏黑色的例子: 如果一個名字出現在高層的『黑名單』, 不用特別吩咐, 組織裡就會有特別的處理方式。在這情境下, 名字資料, 有機會驅動許多非正規服務的運作。服務的多寡, 端視人心有多黑。

愈寫愈冷, 換點正常的舉例。

有一陣子, 在商業/工作流程的產品上開發。流程、表單、管理, 組合得好, 客戶也開心 … 幾乎相信這是數位化的聖杯。直到某年夏天安裝冷氣, 師傅們能在 12 樓凌空裝支架固然讓人驚嘆 (工作加表演, 合法嗎?), 完工後立即用 Line 拍照回報, 才發現之前產品有些地方是到達不了的。整個過程能辨識身分(IM User), 在特定通道(開群組)資料不會亂, 而使用者要準備的資料只有照片 (手機應用的普及又比客製程式優) … 不用專屬產品, 卻綽綽有餘。雖然做功能評比, 產品可能會有優勢, 但實務上是能忽略。

另外, 豐富的雲端應用, 也消彌客製開發的必要。

例如, Google Forms 讓問卷填寫、搜集更容易。遇到排班表的需求, 雖然表單難做, 但可直接使用 Google Sheets 像真實的班表開放給大家填。配合清楚的規則(有填寫紀錄), 以及 Line 即時使用協助, 只要填上姓名資料即可。原本預計幾天才能做完(傳統紙本), 結果不到一個小時就收工。

這三個範例, 都只有少量且必要資料, 就足以成事。形式上分別類於反應式 (reactive, 資料到服務), 流處理 (stream processing), 以及資料協作 (collaboration) 的例子。前兩者明確定義類等於資料流 (dataflow), 最後一項是目前數位化應用的主力之一 。

從已往開發的角度來看, 會需要採買或打通一些產品, 外加一些寫程式的工作。現在, 依附已有的應用, 在適當規劃下, 都只要一些資料就可達成目標。

未來利用資料流的方式, 當是愈來愈多。

應用開發的階段史 - 套包、殼層、木馬

應用開發有趣的地方, 除了有寫不完的程式, 某種程度必須與時俱進, 不斷的面對改變。再者, 資訊科技在各行各業滲透程度愈來愈高, 自然產生更多應用開發的需求。變化, 擴散, 再加上循環, 形成無窮盡。有人厭倦, 卻也有更多人加入。

經歷一些隨坡逐流的改朝換代, 逐漸也有自己的步調, 去調適需求, 參與人力, 以及處理不同目標。

從流行的角度, 所謂的階段應該是 web, agile, mobile, serivce, cloud, big data, …。

這裡從過往經歷不同的嘗試來看:

最早著手於開發的基石們, 不斷認識不同的語言, 元件, 工具。

一直到現在, 用套包 package 解決特定問題, 產品、框架、服務大多以這種方式存在, 相處也愈來愈自然(不見得輕鬆), 不論是著手使用, 或要加加減減。

再一步是面對人力更迭。

長久以來, 雖然大家的任務可能不同, 不同工但同具, 甚至同工同具, 讓大家視野皆同, 很多問題時間可解。一旦有客戶的人員要加入開發組, 就成為一項挑戰, 因為整疊工具要上手, 並不是短短時間可解決的。

雖然主流是大家一起學寫程式, 但有難易、親疏之分, 要把人力拉齊不容易。

開源常見的腳本語言可解這項難題 … 把落落長的實作, 用更容易表達的方式呈現。對新加入開發組的客戶而言, 更好學習, 更好應用, 也更容易維護。

原本歸功腳本語言的強大, 後來習得資料流 (dataflow) 手段, 以試算表 (spreadsheet) 搭配某元件解決另一項難題後, 方才體驗到這是殼層 shell 概念在發功。是 linux, osx 使用者的日常, 但放到應用開發 … 可讓需要程式專業的部分開放給更多人參與。

最後是跳脫循規蹈矩。

原因是客戶指定基石 .net 加上 m 社的一堆產品。.net 固然是近來完整又與時俱進, 有問題的是搭建在上面 流程、表單 等產品。後來 m 社也宣告 2013 是最後一版, 且在 2023 停止支援。

實際面臨的問題是, 即使只改一個需求甚至改一個字元, 都得歷經一段超過 10+ 分鐘的特殊工具存檔, 打包 (pack) 與部署 (deploy) 過程。這和主流編纂原碼, 由版本控制系統加持部署的方式大不同。而且它的部署還不時有原因不詳的失敗 … 實際時間是 n 倍計。

儘管不同平台有不同部署的方式, 但對於資訊應用系統, 以原碼或利用殼層隔出原碼操作, 讓所改即所得, 是較理想的方式。最好的例子是 web 應用, 不論 html/css/js 如何往上擴充, 原碼透明度都高, 找問題並解決才方便。畢竟運算資源提高了, 這種方式對待人力資源是比較友善的。

改變的契機在一個與 linux 整合的專案, 前端依然是 m 社的產品組合, 後端則帶進開源服務套件。後來順勢把其他專案的後端都取代, 但使用者接觸到的包含 m 社的 web 介面、管理、資料庫保持不變。取而代之的後端可視為木馬, 透過這個木馬讓開發者得以直接變更原碼, 更快更容易達成目標。

以上回顧了過往開發的三個階段: 套包(package), 殼層(shell), 木馬(trojan)。

基本上, 對一包包推陳出新的零件保持興趣, 相處得好, 伺機解決疑難雜症。

這些有的可能是產品, 有的是框架, 有的是服務, 有的是個語言, … 各別自成體系, 學習曲線各自不同。如果需要更多人加入擴展應用系統, 人員程度角色不一的狀況下, 規劃出殼層是種解決方式。

搭建殼層通常透過腳本語言做簡化和操作 API 以及資料, 如果要非程式人員也能貢獻, 規劃資料流的殼層, 例如試算表則是更佳法門。

然而面對品牌迷思, 教育別人, 不如改變自己, 種子也要扎根才有長大的機會。塞個玻璃般透明的木馬, 成為一種手段, 畢竟開放又方便, 讓人很難拒絕。

• How to Draw a Horse by Van Oktop