[討論] My Way, High Way, API Way
剛剛看到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
--
不行,韓式餐點我不會看
大家被硬體進步慣壞了
推
台積電也是其中一份子^_^
台積電的晶片也慣壞了一堆軟體工程師
推
韓式套餐一份多少錢?
推
22加幣
同意 現在一堆軟體優化爛到炸就是沒有自己的底層 架
構在別人打包功能之上的軟體怎麼優化還是會有毛病
樓上,印度工程師很喜歡玩堆積木,別期待優化。所
以我這邊有個笑話,是今天標題的原型:My Way, Hig
hway, Indian Way
等等,這個笑話我不是業界好像也常常聽到,為什麼呢
?
友好握手
我現在在想是誰常常跟我吐槽印度
Show me Da wei ! My buda !
內容讚 餐點棒 相關書單準備上....XDDD
22加幣好像有點小貴,但是內容物看起來應該管飽
那句是不是跟輕度 中度 重度 印度梗是一樣道理?
推
優文,推
是一樣呀!但是西方人不用中文,有他們自己的梗。
算力就過剩,沒有最佳化的軟體架構也能活的下去……
這年頭有時候都會有是不是只剩MCU的韌體在斤斤計較
效能
的錯覺
小菜可以續。
但是軍事武器裝備可沒辦法那樣奢侈地衝算力,一條
軍艦或一架戰鬥機的電力跟重量是很斤斤計較地^_^
軍工產業很在乎最佳化/優化,日本工程師這點也蠻強
的。
22加便宜呀 這樣在一小時航程外加稅小費至少30鎂
推
Q
現在硬體太強,工程師不需絞盡腦汁,AI寫軟體目前
也只能寫到功能達標沒法優化太多吧?
AI伺服器算力都很強大,AI用自己持有的算力來寫程
式,當然不需要替自己的程式優化呀!^_^
軟體工程師都會追求新的技術,畢竟他們職涯可能轉
去開發軍工以外的領域,除非你保障他們吃一輩子。
前蘇聯的軟體演算法很強,也是因為硬體落後歐美
而那個影片的優化/最佳化也是基於過去原始的電腦架
構下不得不做的妥協。在2000年以後出場的電腦架構
,都幾乎不需要那樣做了。現在的戰鬥系統用得更少
,原因其實不複雜,就跟我指導教授說的笑話一樣:
螢幕上兩個點,現實距離一英哩。
現在不一樣了 過陣子會大爆發 AI寫程式太想
我過去兩天讓AI跑的超過我自己十年的份
那個22加幣是完稅價
15
[問卦] 沒人發現寫程式只是呼叫已經有的API而已如題 大部分寫程式 就是呼叫已經寫好的 函式庫、框架、模組、套件、API而已吧 只要上網google查怎麼用23
Re: [討論] 怎樣算是一個合格的junior cpp programme針對關於 TDD 的討論另外回一篇好了 覺得用推文太長了 XD : 推 stupidlove0: 朝聖!重要的真的是unit test 08/23 18:47 : → HZYSoft: 回樓上 TDD 問題,TDD 不只要測試,還要先寫測試才寫code 08/23 21:33 : → HZYSoft: 很多人無法習慣這種順序,是否一定要 TDD 這有爭議 08/23 21:3419
[請益] 非本科的是不是要還沒學過作業系統的債小弟是ee畢業沒有受過cs本科訓練 而研究所就是作cv領域,未來目標想往3d視覺方向走 目前在工業製造設備商已工作了1年,基本上公司就是有關設備的軟體功能都要全包,包 函影像算法開發,應用場景,設備機器的控制,流程動態規划,使用者介面設計 在開發視覺方法的部份沒有大致問題,在程式開發應用上,碰上的需求都能靠數學硬幹出11
[問題] 只靠API可以打造裸K看盤軟體嗎?如題.. 一般API都用來程式交易,但我只想打造看盤軟體 如果只靠期貨商提供的API可以打造跟券商軟體同步的看盤/下單器嗎? 目前我用WPF框架已經可以讀數據畫K棒 想打造一個自己喜歡的看盤介面![[問題] 只靠API可以打造裸K看盤軟體嗎? [問題] 只靠API可以打造裸K看盤軟體嗎?](https://static.tradingview.com/static/images/logo-preview.png)
7
[心得] ChatGPT協助軟體開發的指令集近來寫程式時大量試用ChatGPT 剛好使用golang開發side project, 所以在各種情況下遇到的問題,都試著問ChatGPT 真的覺得超好用的! 網頁好讀版:附上心智圖、完整範例(有些範例太長,PPT沒有辦法完整呈現)6
Re: [請益] 專精前端(或後端)vs全端工程師之前剛好有一份工作是全端,我不知道是否會趨勢化,但全端不一定是一人包前後的案子 事實上那是一份不小的專案,前後端各有數人在開發,甚至客戶 App 也會來串機器 簡單介紹一下那個專案架構 我方開發 web 前端,機器上跑大量 C 的程式,需要把既有 command line 東西視覺化 為了達成雲端操作,所以需要有一個全端來設計 API + SDK6
Re: [請益] 工控背景工作十年不理想,請教未來出路小弟跟您領域剛好有點相反... 目前大概是41歲左右 剛開始出來工作 就是單純軟工 寫UI 從asp php asp.net(vb c#) ...反正有什麼案子就寫什麼 因為平時就很喜歡自己DIY 不管是 裝修 ....5
[請益] Line API如何建立聊天機器人?目前在玩PHP做Line的聊天機器人 但在一開始就卡關了 官方的文件說明要先建立一個bot的物件 我也照做了 中間加了error_log來檢查有沒有執行到這行![[請益] Line API如何建立聊天機器人? [請益] Line API如何建立聊天機器人?](https://i.imgur.com/fDyaIR4b.jpg)
2
Re: [討論] 工作上寫單元測試的比例因為大家的討論都很基於心法 實作上相對很模糊 利用這個機會也跟大家請教實作上的方式 因為最近工作被指派要針對公司產品的程式做整理,其實運作都還好 只是大家功能是一層疊一層,一堆巢狀邏輯,跟依賴中的依賴![Re: [討論] 工作上寫單元測試的比例 Re: [討論] 工作上寫單元測試的比例](https://tdd.best/wp-content/uploads/2021/01/play-for-fun-scaled.jpeg)
1
Re: [討論] 大家目前寫程式會使用的AI工具重新排序了一下 個人用對程式語言的掌握能力來排序 指的是有無學過 有無專案開發經驗 之類的 ChatGPT Free 適合從無到有,無經驗者或無開發經驗或者專案建置經驗抓大方向