做软件不容易
2026-02-03 周二 11:46
2026-02-03 14:40
职场 ： 随笔
昨天刷到一个推送新闻，各种在工业设备检修中发现故障隐患，避免了后期严重事故的发生，然后都是表彰，发奖金。这么一个故事合集的新闻稿。
对比一下，搞软件的，如果日常只是巡检项目中的各种风险点，提前修补优化，基本都会被视为不务正业，没有为业务发展提供有效贡献，价值不大。
为什么同样是做技术的，软件和硬件的差别就这么大呢？
当初上学学软件工程这门课的时候，就讲到软件系统和传统机械类硬件系统的一个巨大的特性差别，就是硬件是会有磨损寿命的，其物理结构是会缓慢但持续的劣化，直到失效。而软件只是一套逻辑结构，没有磨损这种情况，似然没有机械硬件的老化问题，只有慢慢变得不再适应使用场景的问题。
曾经和既做过软件又做过硬件的工程师聊天，问及软件硬件哪个更难？得到的回答是还是软件更难，至于其中原因，我觉得很大一条是硬件上很多问题是能够通过观察看出来的，而软件这东西基本没有可直视观察的可能，纵然是个非常简单的函数，也不可能一瞥就看明白，必须要逐行阅读分析。
对应到上面那个对比情况，硬件上的老化隐患，通常都是磨损、开裂、变形之类，只要认真仔细，把所有犄角旮旯都看到，大概率是能发现到问题的。发现问题上报，拉着领导同事，把问题点指一下，大家都能看出来这里是有问题的。
而一个软件系统，如果已经稳定运行，本身就说明没什么问题，所谓提前发现事故隐患，是不可能简单到处看看就能看出来的，换句话说，对于软件系统，是没有巡检这个概念的，其中的问题通常都是在业务变更，导致软件迭代开发时暴露的，而修复问题的过程也就自然地算入功能迭代的成本中去了，并不一定会被单独拎出来讲。
而一个工程师如果日常跑去翻旧代码，找问题，本身就说明他的工作时间是没有用在其“正当”的工作上的。即便发现了问题，把问题解释清楚说明白，让领导相信这是一个问题，也不是瞥一眼就行的过程，扣除发现问题位置的成本，一线读懂问题来源所需的认知理解成本，跟他的领导搞明白这件事的成本是差不多的，而领导如果没心思、没精力搞懂这个问题，又怎么敢确信那是一个问题隐患呢？多少大系统都是靠着bug们互相支撑来维持运行的。
866 字