曾经的表格，数据如风； 变更无迹，查找成空。 现今的系统，日志加持； 模块清晰，管理轻松。

🤖 背景介绍

在机器人硬件设计上，模块化已经是标配了。这样可以让机器人具备更强的适应性，随时更换或升级不同的功能部件。

想象一下：你手头有一堆机器人，硬件设计得可漂亮了，全是模块化拼接，像搭乐高似的，通信模块、电源模块、传感器模块……听起来是不是很酷？

但在管理层面，一直以来都是个麻烦事。

之前，我们团队主要通过 飞书表格 记录机器人使用的模块，比如某个机器人换了新的通信模块，大家就在表格里手动更新。但问题来了：

• 无法追溯 🔍：换过几次？用过哪些版本？全靠翻表格，难查！
• 多人编辑，易出错 📝：手误或者遗漏，导致数据不准确。
• 管理效率低 🕑：想查询某个机器人当前的模块状态？要翻很多历史记录。

于是，我们决定开发一个后台管理系统来解决这个问题，确保机器人模块信息 实时可查，可追溯，可管理。

---

🛠️ 方案构思

我们的目标很明确：

1. 实时查看 机器人当前使用的模块。
2. 追踪模块更换历史，做到可回溯。
3. 模块管理，支持更细粒度的模块记录，而不仅仅是完整模块。
4. 全局设计，考虑未来扩展性，避免后期改动成本过高。

🏗️ 最初的构思

最早，我们想直接 关联机器人和模块表，在数据库里记录：

Robot A -> 通信模块V1
Robot A -> 运动控制模块V2

但很快发现这个设计 太简单，没法满足需求，比如：

• 模块有层级关系（比如通信模块里还有子模块）。
• 无法追踪模块变化历史。
• 未来可能有多个机器人共享某些模块。

🚀 迭代优化

于是，我们调整了设计，采用了 三层结构：

1. 机器人表（robots）：存储机器人基本信息。
2. 模块表（modules）：记录所有模块，支持子模块。
3. 机器人-模块关系表（robot_module_log）：
   • 记录机器人和模块的绑定关系。
   • 记录变更时间，实现可追溯。

🎨 数据结构示意图

Robots
  |
  ├── Robot A
  |      ├── 通信模块 V1
  |      |      ├── 4G 模块
  |      |      ├── WiFi 模块
  |      |
  |      ├── 运动控制模块 V2
  |
  ├── Robot B
         ├── 通信模块 V2
         ├── 运动控制模块 V3

这样，我们不仅能查 当前使用的模块，还能回溯历史，比如：

SELECT * FROM robot_module_log WHERE robot_id = 'A' ORDER BY change_time DESC;

就能看到 Robot A 过去使用过哪些模块，以及更换时间。🎯

🤯 遇到的难题 & 解决方案

1️⃣ 模块拆分粒度如何确定？

一开始，我们纠结 模块的粒度。比如，通信模块里有 4G、WiFi，应该拆开记录吗？

💡 解决方案：

• 采用 树状结构，让模块支持子模块。
• 既能查询 完整模块，又能查询 具体某个子模块。

2️⃣ 模块编号咋办？

一开始我想直接用序列号，比如“COMM-001”代表通信模块，但发现有些小模块是通用的，装在不同大模块里，编号重复了咋办？

💡 解决方案：

• 加了个“上下文前缀”，比如“COMM-001@SENSOR-003”，表示这个通信模块属于某个传感器模块。麻烦是麻烦了点，但至少不乱了。

3️⃣ 追溯的时候，历史数据咋展示？

光知道模块换了没用，得知道为啥换、谁换的。

💡 解决方案：

• 给每次模块变更加个“日志”，记录操作人、时间、原因。后台加了个筛选功能，能按时间轴查历史，贼方便。

4️⃣ 如何高效查询机器人当前模块？

由于历史变更数据很多，查询最新模块状态可能会很慢。

💡 解决方案：

• 采用 状态表缓存最新模块信息，避免每次查询都扫描整个变更日志。
• 变更时自动更新状态表，加快查询速度。

5️⃣ 如何保证数据变更的正确性？

多人操作时，可能会发生 数据覆盖、误删 的情况。

💡 解决方案：

• 采用 事务 确保数据一致性。
• 变更日志 不可删除，只能追加，保证追溯能力。

---

🎯 总结 & 感悟

从最初的表格管理，到结构化的数据库存储，再到考虑数据追溯、查询优化、事务管理，我们经历了一次完整的方案演进。

📌 核心经验：

• 设计时 考虑全局，避免后期大改。
• 数据结构比代码更重要，先想清楚再动手。
• 模块化不仅是硬件的事，管理同样需要模块化思维！

愿每一个代码变更，都是为了更好的未来！ 🚀