"河与船"的隐喻：架构师应关注问题，而非既有方案

作者用”路人甲过河”的场景收束本章：甲过河后留下了船，如果我们能复制”船与行船的方法”这些知识，就能用同样的方法过河——但这个过程掩盖了两个关键问题：甲当初是怎么造出船的？甲面临过河难题时，又是如何想到”造船”这个解法的？前一个问题所涉及的知识很可能已经随着船的存在而佚失了——反正船已经在我们面前，没人会去追问它的来历；后一个问题所涉及的知识则根本不可复制——那是甲当时具体处境下的具体思考过程，无法照搬到别的场景。作者指出，大多数人不会去追究这两个问题，因为一旦有船在眼前，这两个问题看起来就”与过河无关了”——但这恰恰是典型的程序员思维：只关注工具之用，不关心工具因何而来、为何而生。作者主张架构师面临的应当是”河”这个事实、以及”过河”这个问题本身，架构师的思维应当基于对事实与问题的思考，而不是基于已经现成的、别人造好的”船”（对应到架构领域，就是三层架构、COM架构、数据流架构这类既有方案）来直接套用和设问。收尾的几句话点出了这个隐喻的深意：有船在手，衣服不会湿，但如果你愿意湿掉衣服，仍然可以蹚水过河；而河其实未必很深——知道”河其实未必很深”，才是真正的大智慧。可迁移启发：面对一个技术难题时，习惯性地先去找”有没有现成的成熟方案（船）”是程序员式的本能反应，但架构师更应该做的是先回到”河有多深、为什么非要过河不可”这个问题本身——很多时候一旦看清楚问题的真实形状，会发现船（复杂的既有解决方案）根本不是必需品，问题比想象中简单得多，代价（湿一点衣服）也远比套用一整套重型方案要小。