應用開發有趣的地方, 除了有寫不完的程式, 某種程度必須與時俱進, 不斷的面對改變。再者, 資訊科技在各行各業滲透程度愈來愈高, 自然產生更多應用開發的需求。變化, 擴散, 再加上循環, 形成無窮盡。有人厭倦, 卻也有更多人加入。
經歷一些隨坡逐流的改朝換代, 逐漸也有自己的步調, 去調適需求, 參與人力, 以及處理不同目標。
從流行的角度, 所謂的階段應該是 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
0 comments:
Post a Comment