登录 搜索
首页 >> RF头条 >> 感悟

软件/硬件工程师的思维不同点,说中你了吗?

软件工程师:我今天要完成xx行代码的重构
硬件工程师:这几个器件能不改就不改,实在不行用独家供货
 
 
软件的灵活性很高,可以根据需要进行修改,即使是微不足道的修改,只要能让代码看起来比较“爽”,都可以随时进行调整。况且现在代码的版本控制工具比较成熟,实在不行可以用时光机返回所有的修改。
 
硬件不一样,有时候动一根线,或者layout的时候动了一点位置,都可能导致信号产生比较大的噪声或者异常。每一个器件的修改也是慎之又慎,需要一系列替代测试和可靠性测试,即使是在风险可控的条件下,也要考虑投入产出比。
 
 
软件工程师:有一个新的需求,我们要考虑一下实现方案
硬件工程师:有一个新的需求,我们看能不能在原来的方案上改一改
 

软件行业日新月异,有各种各样的语言、框架和实现方式,程序员的经验可以让他们更快的学习,但因为时常要面对新的东西,随着年龄的增长会显得力不从心,于是就有了程序员吃青春饭的说法。同时,由于软件的灵活性,需求往往是变化多端的,即使是在同样的框架下,面对各种各样的需求也有可能遇到很多坑。
 
相对软件行业,硬件的变化算是比较小的,虽然性能可能在不断提高,但更新的速度和更新的范围往往是较小的。经常是用着100年前的原理,加上20年前的技术,改一改实现新的需求。因此有了硬件人员的经验论,当他对需要的一些器件了如指掌的时候,制定方案或者定位问题都是完全可控的,而这些器件在他有生之年可能都不会有突飞猛进的变革了,依靠之前积累的经验就可以让他游刃有余。
 
 
软件工程师:It works!! 好吧,就这样搞定吧。
硬件工程师:换了一个电容就可以了,不科学啊,我得找下是什么原因
 


遇到问题的时候,硬件工程师比较倾向于“根因分析”,所有现象必须要有个解释,这样的话可以减小问题重犯的概率。如果问题不彻底解决,往往代价是很高的。软件工程师往往觉得问题解决了就是OK的,后面还有一堆的需求和变化需要处理,有时间再去分析一下。这里不一定是责任心的问题,一个原因是因为再次遇到问题的代价不一样,另外有时候是因为需要管理的复杂度。
 
硬件面对的复杂度从某种程度上说是有限的,也就这么几个器件,遇到问题顺藤摸瓜就行了,大不了还有定位的必杀技——“替代法”,每个器件换一遍,大概就能找到问题所在了。软件面对的复杂度相对较大,如果涉及到操作系统甚至还需要hack操作系统,如果几个模块是由多个工程师开发的,模块之间的耦合度又较高,定位问题显得心有余而力不足。
 
 
软件工程师:我的代码是一颗树,我要每天去耕耘
硬件工程师:我的方案是一个平台,以后的需求就在这个平台上面改一下就好了
 

“平台化”对双方来说看起来都是非常不错的,面对新的需求只要在上面修改一下就好了,领导尤其喜欢这种理想状态,可以作为管理绩效的体现。根据上面说明的复杂度和需求变化的程度而言,软件的平台化往往只是个开始,就像是栽下了一颗树苗,后面的路还很长。这其中发挥比较重要作用的往往是软件工程师本身,而不是硬盘里面的那些可能不成熟的代码。
 
 
软件工程师:项目节点要到了,实在不行我先发布一个beta版本

硬件工程师:项目节点要到了,实在不行只能延期了,争取后面不再修改
 
iPhone 每一个机型的升级需要一两年的时间,而iOS却似乎每个月都在更新。对于互联网行业的软件尤其如此,似乎每时每刻都在升级,像google的很多产品一直处在beta的版本,有的甚至生命周期都结束了,都还挂着beta的标签。升级成本和开发周期的不一样,使得双方面对项目时间点的态度会有所不同。
 
 
软件工程师:在我那边还好好的,怎么到你这边就不行了
硬件工程师:这个现象也是可以解释的,可能是米勒电容/寄生电感/xxx的影响
 
程序运行起来之后一般都是很老实的(不老实会被狗咬死),CPU 忠实的运行着每一条指令,虽然在它的世界里面只有0和1,但绝不会出现1+1不等于2的情况。虽然很有可能是程序员自己没有考虑到的场景,但他常常会找运行环境或者操作方面的“借口”。
 
硬件系统不一样,一样的布局布线,也有可能因为器件之间的微小差异导致运行的问题,而器件本身不是完全理想的,经常会出现1+1=2.1的情况。因此硬件工程师需要保持对这些微小差异的敏感度,去解释这个混沌的世界。
 
 
软件工程师:再安排一次检视,想想看还有没有什么场景可能导致问题
硬件工程师:再多做几个模块,确保方案的可靠性
测试不管对软件和硬件来说都是有效的可靠性保障,但测试的理念还是有不一样的地方。硬件测试对重复要求较高,很多器件可能跑着跑着自己就悲剧了,比如电解电容在高温环境下一段时间后电解液减小的较多。因此对同一个模块的反复测试,或者同一种场景的反复测试是很常见的,极端情况就是所谓“高温高湿”实验,加速器件的老化。
 
而软件系统由于其运行的一致性,更多是考虑测试覆盖度,尽量去覆盖每一种场景,甚至每一行代码。测试覆盖不到的,就使用人海战术,通过人每一行代码的检视,去发现可能的问题。
 
结 语
不管软件工程师和硬件工程师有多少差异,他们都在通过自己努力在一点一点改变着这个世界。也希望自己能在若干年之后,还能自豪的称自己为程序员,一个略懂硬件的码农。
您可能感兴趣的文章
再不了解就OUT了!读懂5G要了解这些:大规模天线...
中兴再向美提供电信设备,安全威胁?理性看待中美竞争关系
当初怎么掉进射频这个坑?还记得嘛!
5G对智能联网汽车的意义和激光雷达专利的竞争
99.99% 的射频工程师“ 六一” 节这么过.....
中兴被指藉第三方向美安全部门提供产品;高通购恩智浦存变
参与讨论
后参与评论
扫码加入
官方微信群
合作伙伴 / 生态圈:
Copyright © 2015 - 2017 深圳市创客智趣通信技术有限公司 粤ICP备15070425号