剛剛看到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就直接開始寫程式，連思考前兩點的非功能性需求都不管，然後功能性需求只 以規格書出發，不去釐清製作者那個灰色地帶，這個特別是在非同領域的外包程式開發人員 身上特別容易發生。 最後一點是：農夫都一樣，種稻米跟種西瓜的都可以互相轉換。這幾年各公司為了控制成本 ，都會把程式開發外包。可是這就是災難的起點。一個長年開發射擊指令的資深工程師，他 們必定知道那些業界的眉角，一但看到相關功能中模擬兩可的規格書，一定會去問清楚。但 是外包工程師如果沒有經驗，會直接被自己的不同領域的直覺所蒙蔽而開發出不符合高壓力 需求的模組。而這個已經在航空業界軟體出現過一些問題，但絕大多數都幸虧能提早發現修 復。 好啦，牢騷發一發，給各位看倌獻醜了。 再來就是美食副時間： 果然韓流不是叫假的，我也喜歡吃辣炒豬肉套餐^_^： https://i.imgur.com/nwn7FZB.jpeg 同樣是豬肉，中國北方扣肘子加回鍋肉： https://i.imgur.com/968Bv57.jpeg -- Grundriss Weisheit グルトリスハイト https://i.imgur.com/4LqlURK.jpg --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 184.147.45.96 (加拿大) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Military/M.1753160962.A.612.html