前言：我们其实一直在使用“无名的思想”

很多软件工程师认为自己是实践主义者，靠经验、逻辑和动手能力解决问题。我们习惯在需求、代码、架构和调试中穿梭，而对“哲学”“思维模型”这些看似玄学的词保持距离。

但如果你把目光从工具移向结构，从术层走向思维本质，你会发现：

我们早已在不自知中，使用着一套套经典的思维模型，只是它们换了名字，藏在了工程实践里。

在软件工程中，这些模型没有被刻意提及，也没有出现在文档中，但它们是我们解决复杂问题的隐性支撑。

本篇文章将带你从软件工程中常见的实践出发，追溯它们背后的“思维原型”。你会惊讶地发现：你已经是一个哲学的践行者了，只是你用的是代码语言。

一、MECE 原则：模块化设计与职责边界

MECE（Mutually Exclusive, Collectively Exhaustive）是咨询行业的分析圣经，但在软件工程中，它以另一种语言活跃着：

  • 函数单一职责原则（SRP）
  • 模块高内聚、低耦合
  • 微服务架构中的“限界上下文”

这些原则的目标，正是实现“职责互斥”（或理解为模块独立）与“穷尽覆盖”——每个模块只做一件事，所有模块加起来正好覆盖系统全貌。

MECE 是结构划界的思想，而模块设计正是“结构边界”建模的行为。

二、黄金圈模型：架构设计的三层抽象

Simon Sinek 提出的黄金圈模型强调从 Why 出发，再到 How，最后是 What。

这正是很多高级开发者、架构师常用的思维路径：

  • 为什么要做这个功能？（Why）
  • 如何以最合适的技术路径实现它？（How）
  • 最终表现为用户看到的接口或功能点（What）

比如你在做微服务拆分时，不是从数据库字段开始，而是从“业务目的”倒推服务边界。

架构的本质，是结构背后的意图映射，而黄金圈则是意图建模的路径。

三、系统思维模型：从模块到流程，从静态到动态

很多开发者一开始把系统当作模块堆砌——有点像搭积木。但经验越深，越意识到：

模块不是静态堆叠，而是动态联系；系统不是组合，而是结构张力。

这时我们开始关注：

  • 数据流转路径
  • 状态同步机制
  • 故障传播链
  • 高频请求下的系统瓶颈点与资源拥堵节点

这些都属于“系统思维”的范畴。软件架构图，实际上是一张结构模型图，而 DevOps、事件驱动架构、观察者模式，都是“系统张力设计”的体现。

四、费曼学习法：代码评审与文档写作

费曼学习法的核心是：“如果你不能教会别人，那你可能还没真正理解。”

在工程中最具体现的地方就是：

  • 写注释
  • 写设计文档
  • 写 Wiki
  • 做代码评审

这些行为的共同点是：

用“可理解的语言”对结构进行通俗化表达。

当你能把一个复杂模块写成别人看得懂的文档时，你已经践行了费曼的灵魂。

五、四象限时间管理：任务优先级与 Sprint 排期

我们经常做这样的取舍：

  • 紧急但不重要的需求，做不做？
  • 不紧急但重要的架构升级，排在哪个 Sprint？

这些决策逻辑，正是时间管理“四象限法”的变体：

紧急 不紧急
重要 A B
不重要 C D
  • A 区域是“当下必须做”
  • B 区域是“关键长期积累”，很多架构演进属于此

敏捷开发的 Sprint 排期，其实就是一个不断移动任务象限位置的博弈过程。

六、逆向思维：调试与架构重构

调试时我们常常做的事：

  • 结果是错的 → 从结果反推可能路径 → 打断点、写日志

重构时我们常常问的事：

  • 现在的结构有哪些“副作用”？
  • 如果我们“不要这个功能”，系统是否更简洁？

这些都是逆向思维的实践：

从非目标路径、非主流程中寻找系统的“结构裂缝”与“可优化点”。

七、PDCA 与敏捷开发：结构性迭代机制

PDCA（Plan-Do-Check-Act）循环是质量管理的经典模型。

它在软件工程中的体现非常清晰：

  • Sprint 计划 = Plan
  • 开发测试交付 = Do
  • Review + Retrospective = Check
  • Backlog 优化 + 下一轮调整 = Act

敏捷不是快，而是“结构性反馈机制的短周期化”——就是 PDCA。

八、结语：开发者是无名哲学的实践者

我们常常觉得自己不是哲学家。

但其实，我们已经在实践哲学。

  • 我们思考结构 → 用代码定义边界与关系
  • 我们追求反馈 → 用测试与日志来返照系统
  • 我们探索张力 → 用重构与解耦来释放耦合能量

软件工程早已不只是“写代码”，它是思维模型最真实、最精确的实践地。

我们不再只是使用模型，我们成为了模型的构建者。

而这，正是工程之术通向结构之道的开始。