如何了解一个软件的设计？

news2024/10/6 6:40:17

刚入职，接手新项目，面对一个全新项目，怎么快速研究它？

很多人直接看源码，一头扎入代码，很快就迷失其中，最初那股子探索精神，也会逐渐被迷茫所替。有多少次你满怀激情打开一个开源项目，结果多半坚持不了就放弃。问题出在哪？迷茫是因为缺少对软件整体了解，如同不带地图指南针就闯入热带雨林，迷路只是早晚。阅读源码是必经一步，却不是第一步。应先从了解软件设计开始。

1 模型、接口和实现

好比你看代码：

模型
先看有哪些类及之间关系
接口
然后打开一个具体类，看提供哪些方法
实现
最后，再打开一个具体方法，看怎么写的

1.1 模型

一个软件的核心部分，也称之为抽象。设计最关键的就是构建出模型。而理解一个设计中的模型，可助我们建立对这个软件整体的认知。

如：

编写分布式计算代码，需考虑怎样在不同节点上调度计算
使用MapReduce，只要考虑如何把计算分开（Map），最后汇总（Reduce）
到了Spark，注意力就集中在要做怎样的计算

它们在解决同样问题，只是抽象层次逐步提高，越来越接近要解决的问题，越来越少考虑计算在不同的机器如何执行，大大降低理解门槛。知道模型的重要性，目光甚至可不局限在某一软件。若把同一个领域不同阶段的多个模型联系起来，还能看到软件发展趋势。

1.2 接口

决定软件通过怎样方式，暴露模型提供的能力。
是我们与这个软件交互的入口。

一个程序库的接口就是它的API，但对同样模型，每个人会设计出不同API，而不同API有不同表达能力。比如：Guava对JDK的一些API重新封装，就为简化开发，而很多优秀的做法后来又被JDK学了回去
一个工具软件一般会提供命令行接口，比如Unix命令行工具就是典型的命令行接口
一个业务系统的接口，就是对外暴露的各种接口，比如，它提供的各种REST API，也可能是提供了RPC给其它系统的调用。
……

想深入源码，了解一个软件，可从一个接口进入到软件，看它怎样完成各种基本功能。

1.3 实现

软件提供的模型和接口在内部如何实现，这是软件能力得以发挥的根基。

一个业务系统收到一个请求之后，是把信息写到DB，还是转发给其它系统
一个算法实现，是选择调用已有程序库，还是自己实现
一个系统中的功能，哪些应该做成分布式，哪些应该由一个中央节点统一处理
一段业务处理，是应该做成单线程，还是多线程
当资源有竞争，是每个节点自己处理，还是交由一个中间件统一处理
不同系统之间的连接，该采用哪种协议，是自己实现，还是找个中间件
……

所以，做每一个技术决策都应该结合自己所开发应用的特点，并不存在一个通用的解决方案。实际工作中，许多人以为的设计其实是这里的实现。“实现”很重要，须建立在模型和接口的基础上。一个系统的设计，模型最核心。若模型变了，这个软件便不再是这个软件，而接口通常反映的就是模型。所以，模型和接口的稳定度都要比实现高，实现则随软件发展而不断调整。

模型：需求
接口：可以提供哪些功能
实现：实现模型和接口的办法，语言，框架等技术

在使用类似springboot+mybatis开发的时候，mybatis-generator生产的mapper，service，service imp，在配合controller，就可以对数据库的数据进行增删改查，然后就可以实现一些CMS啊电商之类的业务需求，似乎都不需要自己定义新的接口和抽象，请问这是因为业务过于简单的原因吗？
不，这是因为你把业务逻辑混在增删改查里。

2 案例

2.1 Redis

随使用Redis增多，对Redis有进一步的需求。所以，从6.0开始，它开始支持多线程版本，以便于更好地满足需求。但即便Redis改成多线程，它还是那个Redis，它的模型和接口还是稳定不变，只是实现变了。

2.2 CRM

模型，通常包含两类要素：

基本元素
CRM的基本元素就包括项目、客户、合同和回款
这些元素之间的关系
相互之间的主要关系通常是客户报备，进入立项环节（评估投入产出），再签约，最后进入回款

这是基本模型。这个模型（系统）的接口，就是要为BD提供从客户报备到签约、回款的整个流程管理。

实现就是要考虑如何用消息在这些模块之间传递数据，状态控制、数据查重锁定等。

3 设计三步走

严格区分模型、接口和实现，是因为这三者关注点不同，而很多人讨论所谓“设计”，经常把它们混为一谈。

你们团队开会是不是经常有种很混乱感觉？问题就在于你们把不同层面内容混在一起，一起吃做大锅饭，最后那是人吃的吗？

正确做法是在讨论设计时，遵循顺序：先模型，再接口，最后实现。了解一个设计亦如此。

模型没弄清楚，就讨论细节，难分清哪些东西核心，须保留，哪些东西可替换。
若清楚模型，就知道哪些内容在系统中广泛适用，哪些内容须隔离。即分清模型会帮助你限制实现的使用范围。

如下是一个简化后架构图，订单服务完成处理后，通过MQ把消息发给支付服务，支付处理后，再通过MQ把消息发给物流：

这张图问题在哪？把模型和实现混淆。图中的订单、支付和物流，说的都是模型层，但RabbitMQ就把实现层拉进来。RabbitMQ只是实现这个功能时的一个技术选型，即若随业务发展，它不能很好扮演角色，就可替换掉，而整个设计不变。
所以，实现这段代码时，须封装MQ相关代码，不能在系统各处随意调用，因为它属于实现，可能随时被替换。

了解设计时，要按层次去了解，因为设计是分层的。每打开一个层次，需要了解它的内部时，还要按模型、接口和实现顺序研究。
如RocketMQ设计模型https://github.com/apache/rocketmq/blob/master/docs/cn/concept.md。

如os，了解它的内部，就知道它有内存管理、进程调度、文件系统等模块。可按照模型、接口和实现去理解每个模块，如进程管理：