前后端分离投票小系统(2)

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

同一份信息,大家的理解如何保持一致?

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

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

1、创建投票

2、显示投票

3、参与投票

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

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

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

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

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

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

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

你说啥,外面天黑了?!

来晚了来晚了

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

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

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

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

路在何方,下期再会

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180611G200OG00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券

玩转腾讯云 有奖征文活动