前后端分离投票小系统（2）

我们想在产品规划停留更久一点

同一份信息，大家的理解如何保持一致？

我们的需求就如上图所示，另外开发人员已兼职产品规划师，这种组合潜藏角色复用风险，我们放在后面说。

在开始启动实现原型之前，再次对系统首要功能进行描述：

1、创建投票

2、显示投票

3、参与投票

我们选择3.参与投票为切入点，有人会认为要"先有鸡才有蛋"，但是不能开始投票，这个系统将会失去意义。因此我们选择直接拥有一个投票页面。后端返回JSON数据，前端小伙伴选择小程序为界面载体，于是界面:

在以上选项中，多了一个图片占位元素，这应该是前端小伙伴觉得纯文本选项单调，增加的。可如果要按照这个来，JSON中就需要返回图片地址URL字段，另外很容易想到新建投票选项，也会有富文本存储的改动。你看如果不作约定，就这一个小细节，需求瞬间可变，数据的结构也因此牵连，关系数据库的设计人员该有多么头疼

在项目量级小的情况下，我们可以随时推倒数据库表结构重建，反复验证修正。来吧，让我们展示一下数据表结构设计。

我们把每一个投票当做一个大的项目，每个投票项目对应多个选项，每个投票选项可以被接受多个投票。构建三个实体，投票项目、投票选项、一张投票。表之间关系如下：

为了保持表的字段干净，我们没有粗暴的在Vote中增加项目ID，这会导致在统计整个项目投票会不方便。所以我们增加一个Vote的视图viewVote，补充投票项目project_id。

数据间表是否符合范式需要权衡，保持极小的粒度往往不会有大问题。

有了这个视图viewVote，对数据库的操作将受益于此

你说啥，外面天黑了？！

来晚了来晚了

所以你看，当一个系统开发项目没有产品经理，开发人员兼职去规划设计，会出现怎样的情况。大部分公司喜欢把产品设计交给给开发人员，开发人员都投入到了不擅长的事，而擅长的事又缺少时间，所以风暴之眼后的黑夜会很快降临。

要想理清产品的思路，把思路写进文档，就几乎没有时间去编码，而匆忙去编码可能让项目在后期爆炸，好难做的

开发人员的特质是不打代码会缺乏安全感，万不得已当产品规划，请一定要稳住内心，做系统项目更像是解答数学题，目标是最终拿到满分，0分或者辛苦分都是不太成功。

争取下的时间，投入在产品上的每一分考虑，都是——值得

路在何方，下期再会