拿到需求该干什么

2.1 需求目标#

首先要明确，这次需求到底要解决什么问题，以及做完之后要达到什么效果。

重点确认：

• 这次需求要解决什么问题
• 这次需求的目标是什么
• 做完之后，预期效果是什么
• 这个需求的优先级和紧急程度如何

2.2 需求类型#

拿到需求后，要先判断这次需求属于哪一类。 因为不同类型的需求，后续分析方式和影响范围往往不一样。

常见情况包括：

• 全新需求：和之前业务基本没有关系，需要新增一套功能
• 关联型新需求：属于新需求，但和现有功能、现有模块存在关联
• 优化型需求：在原有功能基础上做调整或增强，例如新增字段、增加筛选条件、优化流程等
• 修复型需求：修复现有功能中的问题或异常

先判断需求类型，有助于你更快判断：

• 应该从哪里入手
• 可能会影响哪些地方
• 是新增为主，还是修改为主

2.3 影响范围#

在明确需求类型之后，要进一步分析这次需求会影响哪些内容。

重点可以从下面几个方面去看：

2.4 验收标准#

需要明确：

• 做到什么程度才算完成
• 页面上最终要展示什么
• 接口最终要返回什么
• 筛选条件要支持哪些值
• 异常情况下如何提示
• 是否需要兼容历史数据
• 是否需要支持导出、详情页、报表等联动场景

验收标准不清楚，后面做完了也不一定算完成

2.5 边界条件#

除了主流程，还要重点确认边界情况，例如：

• 空值怎么处理
• 历史数据没有这个字段怎么办
• 非法参数如何提示
• 没权限时怎么处理
• 数据异常时怎么展示
• 同一功能在不同角色下是否有差异
• 极端情况下是否会影响已有功能

主流程大家通常都会想到，真正容易出问题的，往往是边界情况

2.6 依赖关系#

理解需求时，还要判断这次需求是否依赖其他角色或系统配合，例如：

• 是否需要前端同步修改
• 是否需要测试提前准备场景和数据
• 是否需要 DBA 执行脚本
• 是否依赖其他系统提供数据或接口支持
• 是否需要产品进一步确认某些边界

有些需求不是你会写代码就能按时完成，关键在于你有没有提前发现依赖。

2.1 先分析业务对象之间的关系#

在表设计之前，先要搞清楚业务对象之间是什么关系，常见关系包括：

• 一对一
• 一对多
• 多对多

例如：

• 一个用户可以有多个订单，这通常是一对多
• 一个订单可以包含多个商品，一个商品也可以出现在多个订单中，这通常是多对多

对于多对多关系，通常需要增加一张中间关系表来维护两边的关联关系。

2.2 表与表之间通过关联字段建立关系#

在设计表结构时，如果一张表需要关联另一张表，通常通过：

• 主键
• 业务唯一标识字段

来建立关系。

一般情况下，一张表中只需要保存另一张表的关联字段，而不需要重复存储另一张表的所有信息。 需要使用对方信息时，可以通过关联字段进行查询。

这样设计的好处是：

• 避免数据冗余
• 减少数据不一致问题
• 后续维护更方便

当然，如果某些场景对查询性能要求较高，或者出于业务快照的考虑，也可能会适当做冗余字段设计，这要结合具体业务判断。

2.3 表设计时需要重点注意的内容#

（1）优先遵循公司已有的建表规范

在正式设计表之前，首先要了解公司内部是否有统一的建表规范。 如果有，就必须优先按照公司规范来设计表名、字段名、注释、公共字段等内容。

例如，有些公司会要求每张表都必须包含公共字段：

• cr_time
• cr_id
• up_time
• up_id
• rm_time
• rm_id
• removed

属于建表时最基础的规范，必须掌握：

• 每张表必须有主键
• 主键放在第一列
• 表名和字段名使用小写字母
• 多个英文单词之间使用下划线分隔

（2）字段不要无节制堆积

一张表的字段不宜过多。 如果字段过多，通常说明：

• 表职责可能不够单一
• 数据结构可能拆分得不合理
• 后续维护成本会变高

如果确实字段很多，可以结合业务场景考虑是否拆成：

• 主表 + 扩展表
• 主表 + 明细表

但是否拆表，也不能只看字段数量，还要结合查询方式、更新频率和业务职责一起判断。

（3）字段类型要选择合适

字段类型设计要尽量合理，不要随意选择。

例如：

• 能用整型表示的，通常不要直接用字符串
• 能明确长度的字段，尽量设置合理长度
• 金额类字段要考虑精度
• 时间类字段要统一规范

不过也要注意： 如果某个字段的数据类型在当前阶段不够稳定，或者后续扩展可能较大，可以在合理范围内选择兼容性更强的类型，但不要为了“省事”全部都用字符串。

（4）表注释和字段注释尽量补齐

建表时，最好同时补上：

• 表注释
• 字段注释

因为后续无论是你自己看表，还是别人接手项目，注释都能明显降低理解成本。 尤其是状态字段、业务标识字段、枚举值字段，如果没有注释，后面维护起来会非常痛苦。

（5） 索引要结合查询场景来设计

建表时，不建议一上来就给很多字段随意加索引，但也不能完全不考虑索引。

更合理的做法是：

• 先结合业务查询场景分析哪些字段会被高频查询
• 再考虑是否需要建立单列索引或联合索引
• 数据量较小、查询场景不明确时，可以先不急着加很多索引
• 数据量上来后，再结合实际 SQL 和执行情况优化索引

也就是说：

索引不是越多越好，而是要根据实际查询场景来设计。

2.4 表设计的核心目标#

表设计最终要达到的目标，不只是“能存数据”，还要尽量做到：

• 结构清晰
• 命名规范
• 关系合理
• 方便查询
• 方便扩展
• 方便维护

表设计不是简单地把需求字段堆到数据库里，而是要先理清业务对象、对象关系和数据存储方式，再结合公司规范、字段类型、注释和索引等因素，设计出合理、可维护的表结构。

（1）需求本身复杂度#

先判断这个需求本身复杂不复杂，例如：

• 是简单字段新增
• 还是涉及多个接口和多个表
• 是只改一个模块
• 还是会影响多个模块和上下游系统

需求越复杂，工时自然越长。

（2）改动范围#

要看这次需求具体会改哪些地方，例如：

• 改几个接口
• 改几张表
• 改多少业务逻辑
• 是否影响导出、报表、详情页、缓存、定时任务等联动功能

改动范围越大，评估时间时越要保守一些。

（3）自己对项目的熟悉程度#

同样一个需求，不同人做，时间可能差很多。

比如：

• 对项目很熟的人，定位代码和改动点会很快
• 刚接手项目的人，可能花很多时间在找代码、看表、理解流程上

所以评估工时时，也要客观考虑自己当前对项目的熟悉程度，不要按照“理想状态”去估。

（4）是否依赖其他人配合#

有些需求，不是你一个人把代码写完就结束了，还可能依赖：

• 前端联调
• 测试准备数据
• 产品确认边界
• 其他系统同步改动
• 调用其他系统接口

如果有这些依赖，就要考虑进去，不然很容易出现： 代码写完了，但整体推进不了。

（5）是否存在风险点#

如果需求里存在这些情况，评估时间时就要适当留余量：

• 历史数据处理不确定
• 老逻辑兼容复杂
• 影响范围还没完全确认
• 接口联动较多
• 可能有性能问题
• 可能牵扯缓存、MQ、第三方系统

有风险点的需求，不适合估得太满。