软件硬件工程师其实有非常多的相同的特质，尤其作为有着工程师这个标签的人，共同点还是相当多的。这里就从这些共同点里面挑挑刺儿，看看这两种类型的工程师里面有着什么样的思维不同点，尽量不带褒贬色彩。
软件工程师：我今天要完成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的情况。因此硬件工程师需要保持对这些微小差异的敏感度，去解释这个混沌的世界。
软件工程师：再安排一次检视，想想看还有没有什么场景可能导致问题
硬件工程师：再多做几个模块，确保方案的可靠性
测试不管对软件和硬件来说都是有效的可靠性保障，但测试的理念还是有不一样的地方。硬件测试对重复要求较高，很多器件可能跑着跑着自己就悲剧了，比如电解电容在高温环境下一段时间后电解液减小的较多。因此对同一个模块的反复测试，或者同一种场景的反复测试是很常见的，极端情况就是所谓“高温高湿”实验，加速器件的老化。
而软件系统由于其运行的一致性，更多是考虑测试覆盖度，尽量去覆盖每一种场景，甚至每一行代码。测试覆盖不到的，就使用人海战术，通过人每一行代码的检视，去发现可能的问题。
结语：不管SWE和HWE有多少差异，他们都在通过自己努力在一点一点改变着这个世界。也希望自己能在若干年之后，还能自豪的称自己为程序员，一个略懂硬件的码农。
来源：https://blog.csdn.net/gd1984812/article/details/100885966