刚刚看到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/cn.aspx?n=bbs/Military/M.1753160962.A.612.html