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

[hayanami]

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

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

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

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

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

[iFlicker]

有必要

[terry0314]

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

[a54552239]

先按最简单的方式实现

[nekoyaki]

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

[ritaswc]

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

[ghostwind]

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

[Antihank]

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

[gaobh]

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

[also24]

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

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

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

[visonme]

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

[zidian9]

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

[zidian9]

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

[janus77]

看场景，这个是活动，一般是短期的，所以你的看法是比较合适的。

[reus]

先做一版能用的，然后看时间是否充裕，逐步重构成可以配置的
本来就是无聊的系统，你自己还没点技术追求，等着被淘汰吧

[ooo3o]

时间够就先做.
等到下次再要修改时不就可以闲一次工作的时间了嘛, 但时间照样要争取到手, 不能说早做好了, 到最后时刻再轻轻捅进代码库.

[phpcxy]

我赞成你楼主的做法。目前做法能满足需求，注意可扩展就好了

[akira]

看给了几天时间

[alcarl]

如果做这种活动是常态，时间也充裕，就应该多实现一些通用的功能，为后面复用搭建些框架，积累代码和经验。如果就是一次性工作时间也紧张，那就先实现基本功能吧，毕竟按时可用是第一位的。这事情没有绝对的，在两个极端中选取最有效率的平衡才是正确的选择