剛剛看到F126級巡防艦出現IT介面整合的問題，正好想起過去的案子，這裡來閒聊一下。

第一：我們都是黑箱，驅動端不需要知道細節（My Way）。很多寫程式的人，都習慣把模組
們當成一個個黑箱，透過介面交換資訊。但是呀，很多這樣想的人，都是活在一個完美世界
，接收端可以無限制即時回應（Highway）。這個錯誤更常出現在習慣API式模組開發（API
Way）的年輕世代中，而且特別是印度出身的工程師簡直是著了迷一般迷信這套。

但實際上，只要是呼叫都會有延遲跟容量上限。幾毫秒的延遲，對雷達及指令相關的雙向資
料傳輸上，就可以是被擊中或閃躲成功的差異。所以好的演算法跟緻密的結構很重要，跟一
般商業IT不同，不可以幻想無窮盡的記憶體給那個每秒幾萬筆傳輸；這個是在很多商業軟體
及介面開發時，都不必太考慮的問題。

另外，只要是演算跟伺服器，都會有負荷上限，也就是說，你呼叫端一個固定時間內傳出的
呼叫，必須小於接收端的處理能量及介面暫存區的容量，而且你還要考慮進入了暫存區就會
保證有延遲及丟棄。如果開發者幻想著每個呼叫都是保證的同步呼叫，那在高壓力環境之下
保證會來個time out或者not responding，這樣子會干擾呼叫端對於下一步指令的應對，久
而久之系統就會出現錯誤的內容給使用者，這樣輕則造成指揮官誤判，重則武器系統不聽話
暴走。

第二：該死的資料格式。為了有效的傳輸，當然就是被傳輸的越精簡越好。過去有類似EDI
Fact / ASN這類的固定長度傳輸，好處是解譯速度超快，而且有很多成熟的演算法加入讀取
跟拆解，這也造成很多政府機關仍然對這類形式很有愛。只是呀，這20年來，資料格式已經
上太空好久了。過去有XML引領了30年的風騷，現在有JSON在那邊長江後浪推前浪。如果兩
端系統在這些格式之間需要轉換，輕則減慢速度回到上一段的問題，重則在文數字及符號之
間出現不相容，然後直接給你錯誤的編碼讓你掉出錯誤處理閉包（closure）。而還有一個
問題是，不論是XML或者JSON，在資料解譯跟轉線上，就算在在最佳演算法之下，仍輸給EDI
這類以長度決定一切的格式，但是那些外包的碼農公司，還是很迷信「新就是好」。

第三：頭過身就過。這個問題特別容易發生在這幾年迷信API跟Micro Service萬歲的年輕工
程師上（還有那該死的Swagger被誤用及濫用）。基於第一點，很多程式開發人員在面對一
大堆程式碼之下，變成只關心介面之間測試過即可，跟Domain Experts及Special Matter E
xperts互動不足，甚至也輕視了規格書及Use cases的意義（我就遇到過規格書無用論，只
要設計好Swagger即可代替文件）。變成只要介面間傳輸成功及格式正確即可；最多糟糕是
看到Swagger就直接開始寫程式，連思考前兩點的非功能性需求都不管，然後功能性需求只
以規格書出發，不去釐清製作者那個灰色地帶，這個特別是在非同領域的外包程式開發人員
身上特別容易發生。

最後一點是：農夫都一樣，種稻米跟種西瓜的都可以互相轉換。這幾年各公司為了控制成本
，都會把程式開發外包。可是這就是災難的起點。一個長年開發射擊指令的資深工程師，他
們必定知道那些業界的眉角，一但看到相關功能中模擬兩可的規格書，一定會去問清楚。但
是外包工程師如果沒有經驗，會直接被自己的不同領域的直覺所蒙蔽而開發出不符合高壓力
需求的模組。而這個已經在航空業界軟體出現過一些問題，但絕大多數都幸虧能提早發現修
復。