惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

The GitHub Blog
The GitHub Blog
雷峰网
雷峰网
小众软件
小众软件
博客园 - 【当耐特】
J
Java Code Geeks
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Hugging Face - Blog
Hugging Face - Blog
腾讯CDC
Engineering at Meta
Engineering at Meta
aimingoo的专栏
aimingoo的专栏
A
About on SuperTechFans
H
Help Net Security
博客园_首页
P
Proofpoint News Feed
GbyAI
GbyAI
大猫的无限游戏
大猫的无限游戏
N
Netflix TechBlog - Medium
爱范儿
爱范儿
MyScale Blog
MyScale Blog
Blog — PlanetScale
Blog — PlanetScale
The Cloudflare Blog
MongoDB | Blog
MongoDB | Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
Google DeepMind News
Google DeepMind News

少数派

派早报:Google 发布 Fitbit Air 等 - 少数派 「新人报到」確認需求,再開始 - 少数派 从 SOLO 独立开发者社区,我看到了越来越多开发者开始做自己的产品 - 少数派 我怎么管理那些"不常做,但总会忘"的生活事项 - 少数派 人形机器人量产元年,数据才是具身智能的“生死线” - 少数派 BuhoLaunchpad 高度还原 Mac 启动台:开发历程与思考 - 少数派 五年陪伴依然不舍,DIY 换壳后让罗技 MX Master 3 继续服役 - 少数派 新玩意 240|少数派的编辑们最近买了啥? - 少数派 一日一技|为什么你应该关闭 iOS 的键盘声音 - 少数派 我做了个插件和 Skills,一键提取任何网站的设计规范 Design.md - 少数派 住在三四线城市的你,该开始录播客了 - 少数派 甘南秘境,大白高国 - 少数派 AI的审美:谁让把我变成川内倫子 - 少数派 返工怎能不烦恼,打工人片单总有一部是你的「嘴替」 - 少数派 为了让「上厕所」更健康,我做了一个小工具 - 少数派 AI + Skill,能够让生成的文章去除 AI 味吗? - 少数派 新玩意|韶音OpenDots ONE 耳夹式耳机 - 少数派 《美满》| 在每一个春天的晚上相爱(362) - 少数派 新玩意|优篮子 PS01 MagSnap 磁吸支架 - 少数派 自我整合手记 | 我开始早睡了:用稳定规则,为自由托底 - 少数派 用龙虾(OpenClaw)两个多月,我最深的12个体会 - 少数派 听歌时间到,12 张你可能错过的 2025 华语乐坛好专辑 - 少数派 承诺能追吗 - 少数派 macOS 26启动台没了? 我做了个不一样的App启动器 - Keboard - 少数派 《四海为家的人》| INTJ对话INTJ(361) - 少数派 你发过的那些黑历史,是时候一次清干净了 - 少数派 新玩意:安安静静玩,越玩越专注:计客密码机 - 少数派 iPad 用户首次体验 Android 平板:vivo Pad6 Pro - 少数派 数据逻辑强 - 少数派 极北行+ | 一路向北,探访日本至北之地 | 001 - 少数派
什么是工程师思维? - 少数派
2025-08-04 · via 少数派

家庭琐事

最近发生了一个家庭琐事,让我深刻感受到自己和父母在思维方式上的差异。

事情的起因是,我爸在客厅招待客人时,家里的空气开关突然跳闸,我爸判断,这是由于客厅使用的插排存在问题。他说,最近几次在客厅使用烧水壶时,都会跳闸,更换插排后问题就没有再出现,于是他认定是插排的故障所致。

起初,我也认为问题可能出现在插排上。因为家里的一些插排都是杂牌产品,在高功率设备(如烧水壶)运行时可能会发生跳闸的问题。但后来,我看了一眼“问题插排”,发现它竟然是公牛品牌的——在插排里算是质量过硬的产品。这时,我开始怀疑当初的判断是否太过草率。

为了验证,我把问题插排拿到我的房间测试,先后接上电风扇和热水壶反复试用,都没有出现跳闸问题,这让我对“插排是元凶”的结论产生了动摇,我的推断变成了:

1、有可能是插排的某个插孔损坏了,我测试时没有用到有问题的插孔;

2、跳闸的根本原因可能并不在插排,而是客厅烧水壶本身或者电路系统的其他问题。

我把我的推测告诉我爸,但他仍坚持认为是插排的原因——在更换插排后没有跳闸,不就是插排的问题嘛。

事情到这里并没有争执,只是让我意识到:我们之间并不在于谁对谁错,而是思维路径的不同,一个是“工程师思维”,一个是“经验主义思维”。

什么是工程师思维?

“工程师思维”(Engineer Thinking)是一种系统性、理性、以解决问题为导向的思维方式。它强调逻辑推理、证据支持、过程控制和可复现性,广泛应用于工程、编程、科研、产品设计等需要高可靠性和严密结构的领域。

在这一家庭琐事中,我的思维方式是在没有明确证据之前,不可以轻易下结论,倾向于复现问题、寻找因果链条,并考虑多个可能性,避免以后类似问题再次发生。对我而言,“换了就好了”不能自动等于“原因就是它”。

我爸的判断方式,则更接近于“经验主义思维”,遇到问题后,凭经验迅速做出结论和解决方案,如果更换插排问题得到解决,就认为插排是问题“根源”。这种思维在日常生活中很实用,不讲究逻辑严密,只要接受这个解释,不再深究。

处理BUG的经历

这个“工程师思维”,也是在我学习开发以及处理BUG时,逐渐形成的。

例如,我曾经遇到过在SwiftUI中引入requestReview请求评分功能,如果在视图中点击NavigationLink,应用就会卡死。

如果隐藏requestReview,就不会出现卡死的问题。

通过“经验主义思维”,可以认为问题在于requestReview,那么寻求其他的请求评分方法就可以解决问题。

但我遇到这一问题时,想的是,除了更换请求评分方法,还有没有其他的解决方案,或者问题可能不在于requestReview?

1、确认requestReview和NavigationLinks冲突问题。

我需要确认问题是requestReview和NavigationLinks冲突导致的,而不是其他原因(Sheet)导致的。

我在视图中,创建一个简单的NavigationLink进行测试:

点击简单的NavigationLink,发现仍然存在CPU过高,应用卡死的问题。

这时,我才确认是requestReview和NavigationLinks冲突导致的问题。

2、从网络寻求类似的回答/贴文

当开发过程中,发现问题时,网络上也会有人遇到类似的问题,并共同寻求解决方案。我在《request App Review causing strange crash》讨论文章中,发现有人也遇到过类似的问题。

遗憾的是,文章中并没有解决方案,有一个人提到可以使用NavigationPath替代NavigationLink。

3、寻求其他的解决方案

因为requestReview与NavigationLink存在冲突,我尝试将requestReview评分方法封装到一个评分视图中。

在主视图中,显示这个评分视图,而评分视图就会调用requestReview显示评分。

封装requestReview代码,测试发现仍然会出现卡死的问题。

4、解决方案(替换方案)

最后使用SKStoreReviewController评分方法替代requestReview方法,问题得到解决。

在处理这个BUG的过程中,当我遇到问题并判断问题时,是通过问题的复现来判定的,只有在多个环境都被复现的问题,才能认为这个问题是问题根源。否则,可能是其他因素影响导致,不能凭借经验来判定。

谁对谁错?

回到家庭琐事的问题上,谁对谁错?其他都是对的,只是角度不同。

“经验主义思维”适用于日常生活的“高效处理”,而“工程师思维”则适用于需要“高度可靠性”的领域,比如开发、科研、工程设计。

我的这种思考问题的解决,也是编程带给人的一种深层影响,它不仅改变了我写代码的方式,也潜移默化的改变着我看世界、处理问题的方式。

这也可能导致处理问题上“过于理性”。

最后,借我的一个朋友说的话,“你的理性让我觉得,你只是在完成你的任务”。

感谢各位的阅读。 :)