Question

在此前的讨论中，除了对基本的事实与真相的识别之外，大概涉及三种思维方法：设定、试探和归纳。而本质上来说，这三种思维的过程也是模型与概念抽取的过程。由此所得的，是一个可以用来作为基础并进一步讨论的现实系统的映像：软件系统的架构。

但这个映像不是解，而是讨论解的一个工具。

我们讨论过“路人甲过河”的问题 16 。我们说，在路人甲过河之后留下了“船”，如果能复制“船和行船的方法”这些知识，那么我们可以用相同的方法过河。

但是，有一些问题被这一过程给掩盖了。其一，甲如何造船？其二，甲在面临问题时，是如何得到“造船”这个解的？第一个问题中所包含的知识可能已经佚失了——当我们已然面临“一艘船”这个事物时，这是相当有可能的；而第二个问题中的知识则是不可复制的。

大多数情况下，我们并不去追究这两个问题。这是因为当有一艘船在我们面前时，这两个问题就显得与“过河”无关了。而这也是典型的程序员思维 17 ：关注工具之用。

架构师所面临的往往是“河”这个事实，以及“过河”这个问题。架构师的思维应当是基于对事实与问题的思考，而非基于可能既有的、已得的“船” 18 的应用与设问。

有了船，我们的衣服不会再湿；但如果我们愿意湿掉衣服，我们仍然可以过得河去。

河其实未必很深。

知道“河其实未必很深”，是大智慧。

1. 这里用“概念”一词包含抽象、观点、判断、认识等多种主观认知结果。 ↩
2. 从语言严谨性上来说：第一点事实是正确的，而第二点事实并不完整，是对第一点事实的补充。 ↩
3. UML 中的用例图（use case diagram）是这种一般过程的形式化方法。但是，用例图是从用户视角来阐述与表达的，因此通常它将这一过程体现为（亦即是用例图表达的含义）：办公室成员使用日常功能。 ↩
4. 在现实的情况中，客户可能是盲目的。客户有自己的语境、目的与表达方式，因此将客户需求或叙述直接作为“事实”是相当可怖的。 ↩
5. 如果真有这样的情况发生，那么应该看看架构师是否同时承担了战略决策者或顾问的角色。我事实上乐观地认为（系统的、整体的、面向全局的）架构师应当参与战略过程，但在这里只能谨慎地摒弃这些因素的影响。 ↩
6. 如果用户整体的电子化程度相当高，则可能提供有限的、功能性的、面向内部系统的开放接口。 ↩
7. 我们要尽可能避免望文生义地去理解这些概念。基本上来说，方向与战略并没有非此即彼的边界。事实上在一些讨论中，方向也是战略的一部分，例如将战略表达为战略方向、战略方案、战略决策等的统一。同理，架构师与决策者也并不具有那么明显的分别，很多时候架构师也是决策团队的成员，甚至是 CEO/CTO 本人。问题是，如果我们非得要分离出一个“架构师角色”来，那么我愿意将架构师作为战略的分析、细化和推进者，对决策过程只作辅助，而认为战略的制定者另有其人。 ↩
8. 我们这里假设了一种情况，即在某个系统的建设中，架构师将“使用统一的、通用的账户”作为架构意图。而我们的讨论要点在于：是哪些因素决定了架构师应当（或不应当）作出该判断。 ↩
9. 领域产品、客户项目、通用应用与自用系统，这些都因涉及的系统对象（及其用户、用户的认识）的不同，而导致对它们的架构过程不同。在这里讨论的主要是：当我们需要去提供一些领域产品，而对该领域又并不十分清晰的情况下，我们可以依赖哪些“信息”来构建事实并进一步地提出架构意图。这其实也可以应用于当前系统与现实系统由于高速发展而暂时性地失去方向的情况——它们都处于一种类似“三岔口”的局面中，需要重新的选择与定位。 ↩
10. 就是这样日复一日，行走得如同一具木偶？木偶总是在“一如既往”地满足着需求，但它并不清楚这究竟是带来了提线人的快乐，亦或是观众的快乐，或者他们是否真的快乐。然而，这就是“行进于一个过程，而忽视目标”的工程活动的本相。 ↩
11. 由 W.W.Royce 在 1970 年于论文《管理大型软件系统开发》中提出的、从需求开始的、基于“瀑布模型”的软件工程活动，他事实上是提供了软件开发的基本框架。 ↩
12. 正确的问题是：要一个苹果的“原因”是什么。而“是因为饥饿吗”则是对该问题求解的一个设问。 ↩
13. 这是在《程序原本》“第 18 章 系统”中构想的一个思维问题。 ↩
14. 参考 Harold D. Lasswell 在论文《社会传播的结构与功能》中提出的 5W 传播模式，以及基于此提出的 5W1H 思维方法，即原因（Why）、对象（What）、地点（Where）、时间（When）、人员（Who），以及方法（How）。 ↩
15. 参考温伯格《你的灯亮着吗？》。 ↩
16. 这是在《程序原本》“第 8 章 执行体与它在执行过程中的环境”中提出的问题。 ↩
17. 在《大道至简》中我将之称为“工匠思维”，那是更为确切和形象的。 ↩
18. 仅以架构的实作而论，我们是有许多这样的船的，如三层架构、COM 架构、数据流架构等。 ↩