开发时是否要对不确定的需求进行细致的完整开发

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2163 天前的主题，其中的信息可能已经有所发展或是发生改变。

这两天运营要加圣诞活动，也就是大转盘之类的东西。需求是圣诞当天所有的线路（线路下包含车辆）都可参与活动，并且活动随时上线下线。

我个人的想法是活动奖品之类的东西直接页面写死，配置表里增加一条参数控制活动上下线。等这种活动有更多需求后再进行优化

另外一个同事的想法：以防运营在上线后可能还会改变需求，想要将奖品内容建表维护，对每一个线路，甚至是车辆级的奖品进行可配置化，同时控制车辆级的活动上下线

我觉得他的想法是没啥问题，不过在这种活动本来就不一定常用，甚至有可能用过这次就不会再用，在这种情况下进行这么细的业务设计真的有必要吗

第 1 条附言 · 2018-12-04 14:33:21 +08:00

看了大家的回复，基本都是选择在时间充裕的情况下选择更加细致的开发。
哎，我也知道我那个搞法是偷懒了点，主要是觉得运营这次活动大概率又是用完就不会再用的样子，特地建表维护，配置化，总有种大费周章的感觉。所以才想如果真的有再次使用才进行后续优化，果然还是有点偷懒了啊。
感谢大家的回复，我也尽量改正提高一下自己

活动

下线

奖品

线路

18 条回复 • 2018-12-04 21:17:28 +08:00

iFlicker

2018-12-04 10:13:29 +08:00

有必要

terry0314

2018-12-04 10:17:44 +08:00

我比较赞同先拿出能跑的代码，等需求真的变了再优化

a54552239

2018-12-04 10:19:54 +08:00

先按最简单的方式实现

nekoyaki

2018-12-04 10:22:20 +08:00

我觉得这取决于你们产品经理是不是隔三差五加需求……

ritaswc

2018-12-04 10:22:59 +08:00

看你时间够不够，够的话写成配置式的

ghostwind

2018-12-04 10:23:36 +08:00

可以把奖品写在配置里，把读配置还是读 db 方法封装下。

Antihank

2018-12-04 10:30:35 +08:00

时间紧迫，换我肯定是用最快速的方法实现，写的过程中注意一下可拓展性就可以了。

gaobh

2018-12-04 10:40:44 +08:00 via iPhone

看活动是不是可通用，可通用的通常写通用配置，不通用时间紧先出一版能用再说

also24

2018-12-04 10:51:46 +08:00

两种方案，分别给出预期开发时长，和能够实现的功能列表，丢给项目负责人决定。

后期如果出现需求变更，那是项目负责人对项目需求把握的问题。

如果没有项目负责人，就丢给需求方。

visonme

2018-12-04 10:52:36 +08:00

1. 先保证产品能按正常的时间节点完美上线
2. 在上线前，时间充裕情况下，我也推荐走你同事建议的路线。毕竟只要有百分之一的可能性，都需要做好预防工作

zidian9

2018-12-04 10:53:26 +08:00

有必要，具有高级的抽象能力是工程师的进阶之路。来个需求就搞个需求，不考虑后续的演化是外包做的事情。

zidian9

2018-12-04 10:59:26 +08:00

另外你做得好的话，他们以后也会用到。抽奖是运营的基本手法。如果你做的很抽象，比如支持自定义配置奖品和中奖概率，以及增加抽奖机会的条件自定义。运营人员简单配一下，就能使用，简单好用。那可以做到的事情有很多，比如只配置一个奖品（比如 VIP ），然后设定满足什么样条件（比如注册时间晚于多少，认为是新用户）的用户能参与抽奖。然后中奖几率 100%。等等可以做的事情很多，看工程师的抽象能力。如果做得好，运营们会实用的。工程师也应该具有技术推动产品、运营的能力。