接口和表设计不能自己闷头写的

1. 一开始我以为，后台就是把功能补齐就行

刚接这个后台的时候，我脑子里的想法其实挺朴素的。

我会觉得，这不就是把运营要用的几个功能做出来吗？

比如：

• 素材新增、修改、上下架
• 活动配置
• 素材和活动之间的关联
• 一些基础状态控制

只看功能点，好像也确实就是这些。

但真做进去以后，我很快发现，后台这类项目最容易踩的坑，不是少写一个接口，也不是某个按钮点不通，而是：

• 你这边理解的业务动作，和前台主流程是不是一回事
• 你设计的字段、状态、关联关系，和主力开发那边要接的东西能不能对上
• 运营现在说的“要能配”，到底是简单改几个字段，还是背后真有一套状态流转

后台不是孤立存在的。

它虽然给运营用，但最后服务的还是整个业务链。

这一点如果一开始没想清楚，后面代码写得越快，返工也会越快。

2. 这次最先让我紧张的，不是写代码，而是“我要怎么和主力开发对齐”

前面自己学 .NET、学分层的时候，更多还是和代码打交道。

但这次开始接后台以后，我第一次很明显地感觉到，单纯把代码写出来还不够。

因为主力开发在前台业务那边已经顶了一段时间，他脑子里对业务链、状态、页面动作、接口节奏，其实已经有一套相对成熟的理解了。

而我这边如果只从“后台需要一个管理页面”出发，很容易写出一套看起来合理、实际却接不上的东西。

所以我这次最早碰到的真正问题其实是：

我要怎么把我这边准备写的后台接口，和主力开发那边已有的业务理解对齐。

这个问题对我来说挺关键。

因为它意味着，后端不是自己在本地把接口跑通就算结束，而是你得先确认：

• 这个动作在业务里到底叫什么
• 前台那边是怎么理解这件事的
• 后台改了之后，会影响哪一段流程
• 哪些字段是核心字段，哪些只是页面显示字段

这个阶段如果不主动问，后面一定会出问题。

3. 我后来慢慢发现，对齐接口这件事，本质上是在对齐“动作”和“状态”

一开始我对接口的理解还比较表面。

我会更容易盯着这些东西：

• 路由怎么命名
• 参数怎么传
• 返回值长什么样

这些当然重要，但真正开始沟通以后，我发现更重要的是另外两件事：

第一，对齐动作

比如运营说“调整活动素材”，这句话落到代码里，到底对应的是：

• 新增一条关联
• 修改排序
• 切换启用状态
• 替换素材
• 还是整组配置重排

如果这一步不问清楚，后面接口名字再规范也没用。因为你写出来的动作，可能和业务想要的根本不是一回事。

第二，对齐状态

这部分更容易出坑。

比如某个活动：

• 是草稿
• 是待发布
• 是进行中
• 是已结束

不同状态下，后台能做的事可能完全不一样。

再比如素材：

• 是否启用
• 是否删除
• 是否已绑定活动
• 是否还能复用

这些状态如果一开始只按“页面要显示什么”来设计，后面很容易不够用。因为业务真正关心的是：

当前这个对象处于什么状态时，允许做什么动作。

所以我后来对接口这件事的理解，慢慢从“参数和返回值”变成了：

先把动作和状态讲清楚，再决定接口长什么样。

4. 那段时间我和主力开发沟通，问得最多的与其说是“这个接口怎么写”，不如说是“这件事在业务里到底算什么”

这应该算我那段时间一个挺大的变化。

以前刚开始做东西的时候，更容易问：

• 这个字段叫什么
• 这个接口用 GET 还是 POST
• 这个地方查哪张表

后来慢慢发现，这些问题虽然要问，但问太早反而容易把自己锁死。

因为很多技术问题，背后其实是业务问题没问透。

所以我那时候开始逼自己换一种问法。

比如不先问“这个接口收什么参数”，而是先问：

• 运营改这个配置的目的是什么
• 这一改，会影响前台哪段展示
• 这个活动配置是一次性的，还是会反复编辑
• 如果素材已经上线了，还能不能被活动替换
• 状态切换有没有先后顺序

我后来发现，这种问法虽然一开始显得笨一点，但特别值。

因为只要这些问题问清楚了，后面的接口设计、字段设计、状态设计，都会顺很多。

反过来，如果这些问题不问，后面接口很可能写得很完整，但业务一变就推倒重来。

5. 表设计这件事，我也经历了一个从“按页面想”到“按关系想”的过程

数据库设计这块，我一开始其实很容易被页面带着走。

页面上要展示什么，我就会本能地去想表里该加什么字段。

这种做法的问题是，页面是会改的，但关系一旦设计歪了，后面会很难收。

尤其是我现在这个后台，核心不是单张表本身，而是几类对象之间的关系：

• 活动和素材是什么关系
• 一个素材能不能挂多个活动
• 一个活动下的素材有没有顺序
• 活动配置改动之后，要不要保留历史
• 启用 / 停用影响的是素材本身，还是某次活动下的配置关系

这些问题如果不先理，表设计就很容易变成“哪里不够补哪里”。

而这种补法，短期很快，后面很痛。

所以那段时间我和主力开发沟通数据库时，我慢慢开始不再只盯字段，而是先确认：

业务对象之间到底是什么关系。

这个转变对我挺重要。

因为它让我第一次感觉到，数据库设计不是“字段命名题”，而更像是在给业务关系找一个能落地的结构。

6. 我后来对表设计的一个阶段性理解是：先定主对象，再定关系，再补状态

这不是标准方法，就是我当时自己摸出来的一种顺序。

我现在回头看，至少对当时的我很有帮助。

第一步：先定主对象

先确认系统里核心要管的是什么。

对这个后台来说，比较核心的几个对象就是：

• 活动
• 素材
• 运营配置

先把这些主对象想清楚，比一上来加很多零散字段更重要。

第二步：再定关系

比如：

• 活动和素材是一对多，还是多对多
• 顺序是挂在素材上，还是挂在活动-素材关系上
• 某些配置是属于活动本身，还是属于某次关联关系

这一步如果不稳，后面很多接口都会跟着抖。

第三步：最后补状态

我现在越来越觉得，状态字段不能乱补。

因为状态不是“方便页面显示”的东西，它本质上是在描述：

• 当前对象处于什么阶段
• 系统现在允许它做什么
• 后续动作会不会受限制

所以状态设计如果跟业务动作脱节，后面接口逻辑一定会很拧巴。

7. 这次项目里，我第一次比较明确地感觉到：接口设计和表设计其实是一体的

以前我会下意识把它们拆开。

好像接口是接口的事，数据库是数据库的事。

但这次做后台以后，我越来越觉得，至少在业务项目里，它们根本分不开。

因为接口最后要承接的，就是具体业务动作；而这些动作能不能落下去，很大程度又取决于底下的关系和状态是不是设计得住。

比如：

• 如果活动和素材关系没想清楚，接口就会反复改
• 如果状态定义不清楚，接口里到处都是 if else
• 如果前台和后台对“启用”这个词理解不一样，表里就会多出很多模糊字段

接口设计是在表达业务动作，表设计是在承接业务动作。

这两边只要有一边没对齐，后面代码就会越来越别扭。

8. 这次做后台，让我第一次真正意识到“协作式开发”和“自己练手”不是一回事

如果只是自己写点小项目，很多事情可以先跑起来再说。

但一旦进了这种真实业务场景，尤其是和主力开发并行推进的时候，很多东西不能只看“我自己能不能写出来”。

还得看：

• 我写的接口别人能不能接
• 我理解的状态别人是不是也这么理解
• 我设计的表，后面别人维护起来是不是会骂人
• 这个后台上线以后，运营改配置会不会把前台逻辑顶歪

这时候我才开始慢慢理解，所谓协作开发，很多时候不是大家一起写代码这么简单。

更重要的是：

大家对业务动作、状态定义、数据关系的理解，要尽量一致。

这个一致性如果没有，代码层面再整齐也会出问题。

9. 回头看，这个阶段我真正补上的，不只是接口怎么写，而是怎么跟业务和人对齐

如果只从技术动作看，这段时间我当然也补了不少东西：

• 控制器、DTO、服务层怎么拆
• 接口怎么收参数、怎么返回结果
• 表关系怎么落
• 状态怎么组织

但如果只这样总结，又会把这段经历说窄了。

因为我现在回头看，真正对我影响比较大的，其实是另一层东西：

我开始知道，很多后端问题表面上是代码问题，实际上先是对齐问题。

• 对齐主力开发的业务理解
• 对齐前后台的动作定义
• 对齐数据库里对象关系到底怎么落
• 对齐运营需求说出来的话，后端到底该怎么翻译

这一步以前我是没什么概念的。

现在至少开始有了。

10. 这篇先记一个阶段结论

这次这个内部后台项目做到中期，我现在先给自己记几个比较明确的结论：

1. 后台不是独立功能堆，它本质上是在给主业务链补控制面板
2. 接口设计不能只盯参数和返回值，先要对齐动作和状态
3. 表设计不能只按页面字段来想，要先想对象关系
4. 和主力开发沟通时，越早把业务动作问清楚，后面返工越少
5. 协作开发里，代码能力很重要，但“对齐能力”同样重要

这篇就先收在这里。

总之到这一步，我已经不太会把后台开发理解成“补几个接口和页面”了。它更像是在业务已经跑起来之后，再补一层能被运营稳定使用的控制能力。而这层能力能不能做好，很多时候就看前期接口和表有没有对齐。