RevConsult ：https://consult.revtel.tech/

去年下半年開始了幾個工廠設備的監控專案顧問開發。有別於以往比較多接觸的消費者端應用，情境確實比較不一樣。系統開發很重要的一個點是因時制宜、因地制宜，這次就算是一個很好的案例。

本篇文章紀錄一下值得分享的心得。

內容：以 APP 及 Web 替智能設備加上可以遠端監測及控制的能力

簡單敘述一下背景，這是一個台灣在智能設備領域有非常傑出的成果的公司。經朋友介紹跟我們合作開發類似戰情的遠端監測及控制系統讓管理者能掌握工廠動態。

其中的溝通蠻複雜的，也有賴客戶的協助才能順利完成任務。最終客戶在產業展覽中獲得獎項的認可，算是個雙贏的結果。

誒不要隨便搞掛人家系統

在這個工廠生產的情境中，監控系統要明確設計成外掛 (或許「控」的部分不一定，但起碼「監」的部分一定是)。

過往在一些像港區物流系統(見本文)的經驗，我們可以發現蠻多市面上運行的系統技術老舊簡陋，這倒不完全是主事者是否與時俱進，而可能是權衡之後的理性選擇。當然理性不等於最優，而變革也未必是改善。

就如同工廠環境的資安需求跟雲端需求不太一樣，更重於內部控管及系統運行不停機。系統架構上可能有一些方向可以考慮，舉兩個例子：

1. 善用中台架構
   中台的做法在這幾年蠻流行的。作為一個區隔實體，這種架構可以很好的封裝複雜度及保留開發彈性。比如當你面對原系統溝通時幾乎都是透過資料庫在交換資料時，搭建一些中台來做資料轉換及流程控制便是很好的做法。
2. 主動詢問大於被動通知
   這裡蠻反直覺的。站在資訊流效率及系統效能的角度來看，似乎能訂閱就不該輪詢。可如果系統整體還未曾完全掌握、潛在風險還沒有完全排查，主動行為至少比較好控制。

這裡暫且打住，先回到我們主題 — 系統設計的因地制宜。

一招鮮吃遍天？這世界可沒這麼單純

作為一個工程師或架構設計者，我們都得朝著尋找最佳解的目標奔去。但也必須有雅量的去接受自己以及世界的不完美。

開發的第一步總是從「同理」及「理解」開始 (可參見本文)，尤其在對不熟悉的領域更要小心。人總是會有思維慣性以及一些沉沒成本(如公司已經開發好的框架)，這些都是隱性的天花板。

不要隨便地想要去改動人家的系統及流程架構，不然可能追悔莫及。舉幾個案例：

1. 你只看到訂房系統後大量的人力耗費，但你有想過他們的人員訓練有多困難嗎？
2. 你只看到對方報價系統只做到詢價表單，但你有想過他們的產品結構中那些無法被抽象的人治邏輯嗎？
3. 你只看到他們流程系統還在用 FTP 管理資料，但你有想過他們的對口單位裝置都非常老舊且無法更換嗎？

看不到的地方往往才是最危險的地方。

讀歷史的重點跟讀架構一樣：讀出不得已

不知道大家怎麼讀歷史的？其實在你覺得某些歷史人物很愚蠢時，你很可能就走歪了。每個人面對的情境、握有的資源都不一樣，設身處地去同理才能真正了解。

來自第一線的行為慣性應該盡量參考。當中可能有很多無意義雜音，但通常答案也潛在在其中。

讀架構及設計架構也是如此，這些「不得已」才是系統中真正該注意的地方。善用軟體切割的方式去封裝這些「不得已」然後結合出可繼續擴充及開發的結構才是安全的道路。

黑格爾的這句「凡是合乎理性的東西都是現實的，凡是現實的東西都是合乎理性的」實在是至理。

始於「已知的未知」，敗於「未知的未知」

最後提一下很常看到的問題，就是在開發之初就想著成本最佳化。

這裡的概念很類似開發時所說的「過早最佳化是萬惡的根源」( premature optimization is the root of all evil )。有些事情急不得也無法急，這在規劃以及實作都是一樣的。

系統設計是在追求解決「已知的未知」，但卻往往因忽略了「未知的未知」中而失敗。

要保持彈性來因應這些不可見風險，適度的冗余是必要的。成本的控制是一個獨立的任務，這可以等主線到一段落時再思考，也應該正式納入開發排程。

之前曾遇過因為要省下雲端費用造成系統尖峰時不穩的案例，損失的除了有形的訂單之外也包含心力的耗費。工程問題總是有方式解決的不是嗎？

因時制宜的選用技術，因地制宜的設計架構才能最終解決問題。