这不是在搞技术，而是在玩心态~
正文
大家好，我是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
