这不是在搞技术,而是在玩心态~

文摘   2024-07-09 22:22   广东  


正文


大家好,我是bug菌~
如今为制造业提供大型设备的研发型公司大多数都是做系统集成,一部分有技术实力的公司会把核心部分自研,其他相对比较通用的周边设备由其他公司产品来集成;也有一部分公司只是做做方案和资源整合,几乎没什么自研部分,相对技术实力薄弱一点,但手头有人脉有资源,照样混得风生水起。
系统集成的好处就是做技术整合、缩短研发周期、加快产品上市周期,从而满足客户复杂的定制化需求;坏处便是技术的更新与维护不同步,多人家的产品技术存在一定的依赖性,迭代升级困难。所以为进一步平衡系统集成的优劣,大部分研发型公司还是会采用核心部分自研,周边替代性强且通用的部分由外部公司研发。
这样就产生了不同公司的工程师共同调试开发的过程,由于不同的供应商技术水平、人员素养、工作风格文化都参差不齐,这对技术对接的工程师带来了诸多挑战。

假如一天设备出现通信异常!!

A工程师谨遵公司研发文化,碰到问题先从自身进行排查,主导把通信异常的报文抓取、分析并提交给B工程师;然后就来到了沟通的环节,不知道是不是因为B工程师报文看不太懂,却总是拿着协议内容反复跟A说:"你看xx协议,只要你按照协议这么走的肯定没有问题"。

A工程师反复的强调:“你看看报文,报文是跟着协议走的,不过为啥你的回复跟协议对不上呢?”,B工程师说:"不会呀,我这边是按照协议走的"。

A工程师内心万马奔腾,感觉这哥们很不实在,尽量控制自己的情绪,心里默认他就是一个技术小白,教教他,"报文是你们回应的,我们没法把控的,我跟你分析一下报文哈:xxxxxx”。B工程师回复到:"不对呀,不可能,用其他第三方工具发一下报文,不要接你们的设备。"

A工程师回答道:"这个报文就是用XX第三方工具抓取的呀,我们设备发送的报文都正常监控到了,不会有问题的,你用其他工具发送也是一样的结果~"B工程师说:“我在家里都发送报文测试过,不会有问题的~"。

A工程师有点小暴躁了:"家里测试过不能说明现场就没问题呀,现在报文摆在这里,为啥你们就是不认呢?行,用你的方式抓一下",于是B工程师屁颠屁颠的拿出自己的工具和软件进行模拟发送,最终结果可想而知。

B工程师又开始说胡话了:"我们使用的是XX厂家的组件,我自己的程序看了没问题呀。"

A工程师说:“你都自己验证出有问题了,你还在说没问题。那你联系一下供应你们组件的厂家分析讨论这个问题咯?”

B工程师还站在自信的制高点夸夸而谈:"我们出了很多货了,都是用的这个组件,一直都没问题~"

A工程师叹了口气,说:"搞技术不能这么感性的排查问题呀,不然这套系统交给客户,每天有得大家受的,你们团队能不能内部讨论一下看有没有什么解决方案?"

B工程师打几个电话,估计跟他的团队讨论着这个事情。

一会过去,B工程师回来说到:"你们这块回复能不能处理下,我们的设备一旦故障会自动停机的"。

A工程师回答道:"这可不行,跟其他供应商处理都是一样的,单独为你们这样适配,以后代码不好维护,而且这么通用的操作都有问题,很难保障其他解析会不会出问题,你们还是要务实一点,把问题定位到。"

B工程师反对道:"不会有问题呀,你告诉我会出什么问题吗?"

A工程师直接背着电脑跑了~


最后

      好了,今天就跟大家分享这么多了,如果你觉得有所收获,一定记得点个~

bug菌唯一、永久、免费分享嵌入式技术知识平台~

推荐专辑  点击蓝色字体即可跳转

☞  MCU进阶专辑 

☞  嵌入式C语言进阶专辑 

☞  “bug说”专辑 

☞ 专辑|Linux应用程序编程大全

☞ 专辑|学点网络知识

☞ 专辑|手撕C语言

☞ 专辑|手撕C++语言

☞ 专辑|经验分享

☞ 专辑|电能控制技术

☞ 专辑 | 从单片机到Linux

最后一个bug
一个嵌入式技术进阶公众号,定期分享C语言,C++、MCU(如stm32等)、DSP、ARM、嵌入式Linux等“独门”软件设计技巧和知识归纳总结,同时分享应用程序设计、物联网、滤波及控制算法推导和仿真设计等嵌入式硬核知识技巧!欢迎大家关注!
 最新文章