程序员到架构师，该学习如何说话

---

前言

通常，程序员可以根据自己对问题的理解来编写代码。只要他们定义了清晰的输入和输出接口，并且能够通过预设的测试数据使程序顺利运行，开发工作就可以说是完成了一大部分。然而，在与产品经理或用户沟通时，我们经常发现，基于编程的术语和概念对于非技术人员来说是很难理解的，特别是当涉及到代码循环、数据库结构等专业词汇时。

因此，在软件开发过程中，如何有效地将项目成员的心智模型转化为业务领域的深层术语和关系，从而确保业务模型与开发活动之间更紧密的整合，是对程序员在其职业生涯中需要达到的一个更高的水平。这不仅有助于提高沟通效率，还能确保最终产品更好地满足业务需求。

---

一、举一个例子

以下例子来自于《领域驱动设计》一书，内容非常经典。
用户提了一个货物更改通关航道的需求，在开发过程中，开发人员需要和用户基于该需求进行业务确认：

第一种沟通方式：

用户: 那么，当更改 通关 地点时，需要重新制定整个路线计划啰。
开发人员: 是的。我们将从货运表 (shipmenttable) 中删除所有与该货物id相关联的行，然后将出发地、目的地和新的通关 地点传递给RoutigService，它会重新填充货运表。Cargo中必须设立一个布尔值，用于指示货运表中是否有数据。
用户: 删除行?好，就按你说的做。但是，如果先前根本没有指定 通关 地点，也需要这么做吗?
开发人员: 是的，无论何时更改了出发地、目的地或清关地点(或是第一次输入)，都将检查是否已经有货运数据，如果有，则删除它们，然后由RoutingService重新生成数据。
用户: 当然，如果原有的通关 数据碰巧是正确的，我们就不需要这样做了。
开发人员: 哦，没问题。但让RoutingService每次重新加载或却载数据会更容易些。
用户: 是的，但为新航线制定所有支持计划的工作量很大，因此，除非非改不可，我们一般不想更改航线。
开发人员: 哦，好的，当第一次输入通关地点时，我们需要查询表格，找到以前的通关 地点,然后与新的通关 地点进行比较，从而判断是否需要重做。
用户: 这个处理不必考虑出发地和目的地，因为航线在此总要变更。
开发人员: 好的，我明白了。

第二种沟通方式：

用户: 那么，当更改通关 地点时，需要重新制定整个路线计划啰。
开发人员: 是的。当更改RouteSpecification(路线说明)的任意属性时，都将删除原有的Itinerary(航线)，并要求Routing Service(路线服务)基于新的Route Specification生成一个新的Itinerary.
用户: 如果先前根本没有指定通关 地点，也需要这么做吗?
开发人员: 是的，无论何时更改了RouteSpec的任何属性，都将重新生成Itinerary。这也包括第一次输入某些属性。
用户: 当然，如果原有的通关 数据碰巧是正确的，我们就不需要这样做了.
开发人员 :哦，没问题。但让RoutingService每次重新生成一个Itinerary会更容易些。
用户: 是的，但为新航线制定所有支持计划的工作量很大，因此，除非非改不可，我们一般不想更改路线。
开发人员: 哦。那么需要在RouteSpecification添加一些功能。这样，当更改RouteSpecification中的属性时，查看Itinerary是否仍满足Specifcation。如果不满足，则需要由Routing Service重新生成Itinerary。
用户: 这一点不必考虑出发地和目的地，因为Itimerary在此总是要变更的。
开发人员: 好的，但每次只做比较就简单多了。只有当不满足RouteSpecification时，才重新生成Itinerary。

在比较两段对话时，我们可以观察到尽管双方在沟通的内容和目的上有着共同点，在第一段对话中，参与者不得不频繁地针对应用程序的具体特性以及那些含糊不清的表达进行澄清和解释。而第二段话采用了贴近业务模型的术语，这使得讨论过程更为流畅和直接。这种基于业务领域模型导向的语言不仅减少了对技术细节的依赖，也使得非技术背景的参与者能够更容易理解和参与进来，从而提升了整体沟通的效率和效果。

二、程序员如何学习说话

在程序员与产品经理、用户等非技术角色进行交流时，他们往往不会直接采用领域模型的专业语言，而是使用一种混合了描述性和功能性术语的语言，有时甚至夹杂着从对方那里学来的业务术语。这就像是一门独特的混合语，只有参与者才能理解。

如何将这种混合语，抽象成大家都能理解的团队语言，一个比较好的方法就是多听，多说，多想。即通过对话来进行探索，尝试从谈话中捕捉并比较提及的模型变化和结构。这就像是一场侦探游戏，参与者通过对话来寻找线索，逐渐揭示出业务模型的真相。

想象一下，我们有三种不同层次的描述：

• 技术性描述：“如果我们向Routing Service提供出发地、目的地和到达时间，就可以查询货物的停靠地点，然后将这些信息存储到数据库中。”
• 具体但冗长的描述：“我们需要将出发地和目的地等信息输入到Routing Service中，然后我们会得到一个行程（Itinerary），其中包含了我们需要的所有信息。”
• 简洁的描述：“Routing Service根据路线规范（Route Specification）查找满足条件的行程（Itinerary）。”

在程序员向架构师的进阶之路上，“说话”的艺术是一个关键的里程碑。这不仅涉及到技术知识的深度和广度，更是一种思维方式和沟通能力的升华，这涉及到如何将这些知识以一种清晰、准确且易于理解的方式传达给他人。在这个过程中，抽象思维的培养是至关重要的。

• 低层次的描述：在最初阶段，程序员往往专注于代码的细节和实现，他们的描述充满了具体的技术术语和细节。这种描述对于机器和具体实现是友好的，但对于非技术人员或高层次的决策者来说，可能难以理解。

• 中等层次的描述：随着经验的积累，程序员开始学会从更高的层次来看待问题。他们能够将复杂的系统分解为简单的模块，并使用更通用的术语来描述这些模块的功能和交互。这种描述更适合与团队成员和非技术人员沟通。

• 高层次的描述：当程序员达到架构师的层次时，他们能够从更高的视角来看待整个系统。通过找到一个平衡点，既能抽象到足够的高度，又不丢失关键的细节。这需要深厚的技术背景，以及对业务和用户需求的深入理解。通过使用比喻、模型和图表等工具，架构师可以将复杂的系统简化为几个关键的概念，从而更容易地传达给不同的听众。

---

总结

在程序员向架构师的转型过程中，学习“说话”即学习沟通和表达，是一个不可或缺的环节。有效的沟通不仅能够确保项目的顺利进行，还能够提升团队的协作效率：

1. 理解业务模型：在软件开发中，模型是现实的抽象，它帮助我们理解和设计复杂的系统。模型之间的关系定义了系统中各个组件如何相互作用，这些关系构成了所有语言共有的组合规则。词汇和短语的含义则直接反映了模型的语义，它们是我们描述系统的关键。

2. 使用基于模型的语言：作为开发人员，我们应该使用基于模型的语言来描述系统中的构件、任务和功能。这种语言应该包含足够的细节，以便清晰地传达设计意图和业务需求。例如，使用UML图来描述类之间的关系，或者使用领域特定语言（DSL）来表达业务逻辑。

3. 共同语言的建立：这个模型不应该仅仅是开发人员的私有语言，而应该成为开发人员和产品经理、用户之间交流的共同语言。这样可以确保所有人对项目的理解都在同一频道上。

4. 广泛使用促进理解：这种基于模型的语言的使用越广泛，团队成员之间的理解和沟通就会越顺畅。这不仅减少了误解和混淆的可能性，还提高了决策的效率和准确性。

5. 持续学习和实践：作为程序员，除了跟项目组成员沟通之外，还可以通过参加沙龙、研讨会，阅读相关书籍等方式来持续学习和实践。