PTT評價

[討論] My Way, High Way, API Way

看板Military標題[討論] My Way, High Way, API Way作者
Pegasus170
(魯蛇肥宅台勞+前義務役)
時間推噓18 推:18 噓:0 →:35

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

我們都知道世界各級戰鬥艦上武器裝備之多,多到每個系統整合架構師會發出各種國罵。然而,就我的經驗中,最常出現的災難有以下幾類:

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

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

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

所以設計時,必須要考慮容錯及資料修補,而偏偏資料修補這塊很少出現在商業軟體開發上,必經這是要出演算法得東西(所以演算法一直是計算機科學領域中重中之重)。

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

第三:頭過身就過。這個問題特別容易發生在這幾年迷信API跟Micro Service萬歲的年輕工程師上(還有那該死的Swagger被誤用及濫用)。基於第一點,很多程式開發人員在面對一大堆程式碼之下,變成只關心介面之間測試過即可,跟Domain Experts及Special Matter Experts互動不足,甚至也輕視了規格書及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 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 184.147.45.96 (加拿大)
PTT 網址

ARCHER2234 07/22 13:20不行,韓式餐點我不會看

kira925 07/22 13:23大家被硬體進步慣壞了

classskipper07/22 13:23

Pegasus170 07/22 13:24台積電也是其中一份子^_^

Pegasus170 07/22 13:24台積電的晶片也慣壞了一堆軟體工程師

FishJagor 07/22 13:27

fuhrershih 07/22 13:28韓式套餐一份多少錢?

Wooctor 07/22 13:33

Pegasus170 07/22 13:3522加幣

MIshad 07/22 13:35同意 現在一堆軟體優化爛到炸就是沒有自己的底層 架

MIshad 07/22 13:35構在別人打包功能之上的軟體怎麼優化還是會有毛病

Pegasus170 07/22 13:36樓上,印度工程師很喜歡玩堆積木,別期待優化。所

Pegasus170 07/22 13:36以我這邊有個笑話,是今天標題的原型:My Way, Hig

Pegasus170 07/22 13:36hway, Indian Way

ARCHER2234 07/22 13:40等等,這個笑話我不是業界好像也常常聽到,為什麼呢

ARCHER2234 07/22 13:40

Pegasus170 07/22 13:42友好握手

ARCHER2234 07/22 13:43我現在在想是誰常常跟我吐槽印度

zo6596001 07/22 14:37Show me Da wei ! My buda !

skyhawkptt 07/22 14:56內容讚 餐點棒 相關書單準備上....XDDD

fuhrershih 07/22 15:4922加幣好像有點小貴,但是內容物看起來應該管飽

fantasyhorse07/22 15:50那句是不是跟輕度 中度 重度 印度梗是一樣道理?

BW556 07/22 17:04

utn875 07/22 17:46優文,推

Pegasus170 07/22 19:10是一樣呀!但是西方人不用中文,有他們自己的梗。

cppwu 07/22 19:11算力就過剩,沒有最佳化的軟體架構也能活的下去……

cppwu 07/22 19:11 這年頭有時候都會有是不是只剩MCU的韌體在斤斤計較

cppwu 07/22 19:11效能

cppwu 07/22 19:11的錯覺

Pegasus170 07/22 19:11小菜可以續。

Pegasus170 07/22 19:14但是軍事武器裝備可沒辦法那樣奢侈地衝算力,一條

Pegasus170 07/22 19:14軍艦或一架戰鬥機的電力跟重量是很斤斤計較地^_^

Pegasus170 07/22 19:15軍工產業很在乎最佳化/優化,日本工程師這點也蠻強

Pegasus170 07/22 19:15的。

MartianIT 07/22 20:2322加便宜呀 這樣在一小時航程外加稅小費至少30鎂

user1120 07/22 22:51

CLisOM 07/23 08:24Q

CLisOM 07/23 08:27現在硬體太強,工程師不需絞盡腦汁,AI寫軟體目前

CLisOM 07/23 08:27也只能寫到功能達標沒法優化太多吧?

Pegasus170 07/23 09:31AI伺服器算力都很強大,AI用自己持有的算力來寫程

Pegasus170 07/23 09:31式,當然不需要替自己的程式優化呀!^_^

CGT 07/23 09:34軟體工程師都會追求新的技術,畢竟他們職涯可能轉

CGT 07/23 09:35去開發軍工以外的領域,除非你保障他們吃一輩子。

CGT 07/23 09:36前蘇聯的軟體演算法很強,也是因為硬體落後歐美

Pegasus170 07/23 09:51而那個影片的優化/最佳化也是基於過去原始的電腦架

Pegasus170 07/23 09:51構下不得不做的妥協。在2000年以後出場的電腦架構

Pegasus170 07/23 09:51,都幾乎不需要那樣做了。現在的戰鬥系統用得更少

Pegasus170 07/23 09:51,原因其實不複雜,就跟我指導教授說的笑話一樣:

Pegasus170 07/23 09:51螢幕上兩個點,現實距離一英哩。

SRNOB 07/23 11:19現在不一樣了 過陣子會大爆發 AI寫程式太想

SRNOB 07/23 11:19我過去兩天讓AI跑的超過我自己十年的份

Pegasus170 07/23 16:26那個22加幣是完稅價